Using your SOC to help threat model your Applications
When we think of application security, we mainly think of the attacks that we all hear about, XSS, SQli and the like. We may also think about code reviews (SAST & DAST), the SDLC, automation and Penetration Testing. These are all good and valid points but I want to leave these ideas for now.
One of the fundamental (and first aspects) of an Application Security program is strategy. What is it that the business cares about? Where should energy be focused? Unfortunately, an overlooked exercise when it comes to an Application Security Program.
Start with the high level first
- What compliance and regulatory requirements does the business have to adhere to?
- What penalties could non-compliance bring to the business?
- Does the business have 3rd party security requirements written into contracts?
- What impact would a data breach have, short term, long term
- IS privacy and security a core service offering for the business?
- Could a breach lead to unwanted exposure
Then move on to the likely adversary risks the business might come up against – This is where you will want to utilise your SOC & Threat Intel, Sec engineers etc
- What types of threat actors are likely to target the organisation
- Could we attract nation-state interest? Government, CNI etc
- Will cybercriminal gangs have interest? PPI etc
- Is industrial espionage likely? Would stolen data/trade secrets enhance competitive advantage?
Bring on Threat Modelling.
Threat Modelling is an extremely valuable resource if implemented properly. There are high costs associated with the reviewing and fixing of production code when a significant finding is found, more often than not issues are not fixed due to the complexity or because of a risk assessment that outweighs the benefits. Ie too costly to fix. Regardless of justification though, it would make more sense if these issues were not introduced in the first place.
A well established and mature Application Security Program will be adopting an SDLC and hopefully some sort of threat modelling within the design phase in the development process. The goal is to embed actionable and repeatable processes in the design phase to prevent vulnerabilities from being introduced whether that be in the code or architecture.
I will most likely go through this phase in more detail as there several tools which can help capture the right requirements.
The issues with a badly developed Application Security Program
A new Application Security Program is much more straightforward to implement, you can build in the right processes and requirements from the very start. An existing Application Security Program though is a much different beast. Legacy applications, outdated technologies, no budgets, lack of documentation, the list is endless, are just some of the issues that need to be contended with. And as such these issues present very high risks for any business. Application attacks are some of the most devasting attacks on businesses, stealing customer data and damaging brand reputation. However, there is hope, and again we are going to utilise threat modelling to beef up Application Security.
We hear of the word compensating controls all the time, in the Application Security scene this is most often than not some sort of WAF technology. Now I am not saying this is a bad technology, what I am saying is this is a lazy approach and you have put all your eggs in one basket. You are counting on the WAF to be right every time.
Most organisations these days have some form of monitoring or SOC, along with security experts in different domains. These security experts need to be utilised, a SOC typically comprises experts in numerous areas, log collection, Forensics, Threat Intelligence, Infrastructure and Web experts for example.
What is important though is having the experience and understanding of how applications can and are being attacked. You should utilise your SOC for the threat modelling to threat model your existing applications
With that in mind, we can now set about understanding existing applications and threat modelling them appropriately. There are some points for thoughts to get you going below. Answering these questions means your SOC can potentially build alarms around specific applications, giving your business that crucially important indication that something isn’t right.
- Application Name and intended use.
- Where is the application presented?
- What data is collected?
- Who uses the application, Consumer, Business, Supplier, 3rd party etc Developers, QA etc
- What levels of access are there?
- Who creates/deletes accounts?
- Is data masked?
- Are there any API’s What calls are made?
- Where does the application link to?
- What technologies are in use?
- What is the current state of the SDLC?
- How are changes managed?
- What application logging is there?
- How is the application used?
- What does the application connect to?
Wrapping things up
It is always nice when you have a blank canvas, creating a new Application Security Program is very rewarding but most often you are likely to take on an existing program of work that needs a fair bit of attention. As previously mentioned most forget to strategize appropriately, aligning your Application Security Program with the bigger business risks ensures you can plan effectively, but also communicate why you need/or are going to embed certain processes/activities. I can’t stress enough how important it is to understand the business, the applications, how they are developed and used.
Utilising the SOC and other security functions can quickly help you get a handle on the applications that have already been developed and deployed into production.
With the existing applications taken care of, you can now start to build out the Application Security Program properly, starting with the strategic questions first.