A Structured Approach to Threat Modelling
Now with real-world examples!
The standard definition of threat modelling might be something along the lines of: a structured process with the objective of identifying, quantifying, prioritising, and mitigating security vulnerabilities. In this article, we will explore how this is too narrow of a definition. Threat modelling is a mindset, similar to the art of war or evolution theory. These may seem like out of place comparisons, but we will see how these concepts are applicable with the use of real-world examples. In essence, threat modelling is a mindset and should be treated as such, either you have it or you don’t.
Regardless of the size of your organisation, there is an element of vulnerability to outside and inside threats that can cause disruption to your operations. These threats can originate from a variety of actors, such as state actors, rogue agents, criminal organisations, etc. This is a pretty broad definition because threat modelling is a broad exercise. We can try to pinpoint some use cases but this article will not cover all the possibilities.
Same same, but different
Given that now we know some actors can be a threat to your organisation, what can we do to mitigate that? Well, the first thing anyone would do is a Google search for threat modelling, which will lead to many acronyms such as STRIDE, PASTA, and other overplayed methodologies dating back to the 90s. Let’s take STRIDE for example. It stands for Spoofing, Tampering, Repudiation, Info Disclosure, DOS & Elevation of Privilege. There’s nothing wrong with outlining what can go wrong using an acronym, but in my opinion it’s a gross simplification of real-world threats. It is, however, a good starting point to your threat modelling journey. In a real-world scenario, a security architect worth their salt would not only know what can go wrong but more importantly they would start with what can go wrong first when designing a threat modelling plan.
A better starting point for your threat modelling journey is to look at the OWASP top threats across industries at the moment, something that is more pertinent and actual, as that list is updated on a regular basis. If we look at a new category added in 2021 to the OWASP top 10, insecure design, it becomes apparent that having a threat modelling approach will help mitigate bad design. In a later point we will cover the approach in more detail, but if you identify bad design as a top priority, your initial thinking should be to cover not only all possible components in a system but also how they interact with each other. For example, if you have a data pipeline that migrates data from an on-prem database to a cloud environment and you have secured the data at rest, encrypted it in S3 where you store it, created proper access control, and applied least privilege to who can access that data, you’re probably 90% of the way done with creating a secure environment. To get to 100% secure, you notice that data in transit to your cloud environment is not encrypted, so you decide to encrypt using a CMK. Now you’re safe right? Probably not, maybe your CMK is stored in an insecure vault that an inside actor has access to and you’re susceptible to inside threats. Should you have picked an AWS managed key instead? Are you paranoid yet? If the answers are yes, then we are now starting to understand threat modelling. Remember, the greatest victory is that which requires no battle.
You might be asking at this point WHO should be worried? Should your product owner or your scrum master lose some nights’ sleep over the latest threats and potential bad guys around every digital corner? The answer is probably yes. Threat modelling is a company-wide mindset not an individual mindset only. The bad actor will not care if it’s your credentials or your bosses’ credentials that get compromised as long as they provide a way in. An attacker will be looking to spot any weak points and easy targets (attackers are usually lazy humans as well). If you think like an attacker then you’re already halfway there, so your threat modelling plan should include on-going ideation sessions on each individual component of your architecture, the relationships between components and how an attacker might look at the same component from a malicious perspective. This should start by mapping all the processes in your architecture and drawing sequence/flow diagrams of the system. Make sure you involve the people that know the nitty-gritty of what’s built or about to be built. Drawing trust-boundaries helps to set the separation of privileges between systems or humans that need to communicate with each other.
The simplified example above shows the use of trust boundaries to establish which components need to communicate and how. For example, the user needs to authenticate to the machine which can use something as MFA or fingerprint in order to use a client to send a request to the application. However the request will need to be allowed by the WAF which will determine which traffic is trustworthy. Once the request is within AWS, the control plane will decide which cluster to send the request to. Clusters do not trust each other but they have trust with the control plane which needs to coordinate them into a service mesh. Cluster 1 needs to egress to a 3rd party API which establishes trust via a JWT. Developers need to be able to access Cluster 2 and that is done via IAM for example.
Secure everything
What about DevSecOps, is that threat modelling? Yes! Any consideration to security in any business process, whether it’s writing code or taking down customer details with pen and paper and putting them in a locked drawer is a way of preventing bad actors from messing with your business. The Security part in DevSecOps is not just a bunch of security architects that design a long-worded document like this one, but rather a combination of engineers and architects working together to draw out, design, implement, and test a secure system. In one project, my team was building K8s clusters on EKS and had very little data in any of our AWS accounts. In this case, we began our threat modelling journey by prioritising intra- and inter-cluster communication and started designing a system that allows clusters to be managed, yet not able tocommunicate with each other. Multiple solutions were discussed in the context of business need versus security and practicality concerns. While security architects are expected to uphold best practices, the real power and responsibility is with the platform engineers implementing the solutions and the developers using the clusters on a daily basis. The solution decided on was one that allowed enough flexibility to manage the clusters via a control plane, mitigated the intra-cluster communication, maintaining mTLS within the clusters, and reduced the attack surface. It also mitigated the possibility that if any future clusters hooked up to the control plane have sensitive data, the other clusters can’t access it as there is no communication allowed between clusters that don’t need to communicate with each other.
A good threat model should involve as many people as possible, but yet remain agile enough to be responsive to new threats. For example, just like nature evolves in order to survive, so do DDoS attacks by changing their attack vectors. The intention behind DDoS attacks (preventing the normal operations of an organisation) remains the same, regardless of the industry they happen in. However, the attacks adapt to new conditions and that’s because after each attack, companies implement new security measures to prevent a repeat. These evolutionary tactics mean that it is not sufficient only to prevent. To be truly one step ahead of the bad actors, an organisation needs to also minimise the impact of such an attack. Imagine the surprise for an attacker when your infrastructure remains resilient in the face of an unprecedented attack. You don’t have to operate at a large scale in order to implement threat modelling. Each organisation has its own particularities, and for better or worse, these make it unique. Bad actors will observe those unique traits and want to exploit them.
I fought the law and the law won
Organisations should also be aware of the specific legislation applicable to them as a minimum requirement. For example, GDPR in the EU mentions specifically data encryption as a technical measure to secure data. However, we did see above that data encryption is a small piece of a very complex system and if you’re a company with big ambitions, you’re most likely going to have to deal with complexity sooner rather than later. Whereas you should focus on the topics of the day, the latest and greatest tech and preventive measures, you should make sure you don’t become the topic of the day. If you feel you have exhausted all options or if you believe you are 99.9999% secure against any threats, it will be the 0.0001% that will get you. Don’t be afraid to use outside help from companies such as Slalom or others that have a track record of implementing large, complex, and secure platforms. Also remember that any cloud implementation comes with a shared responsibility model, so your cloud provider of choice will bear the grunt of securing the bare metal at least.
If by the end of this article you’re ready to start your threat modelling plan or if you found all of this to be old news, then you should be in a great position already to prevent threats from disrupting your day-to-day. Just remember not to repeat the tactics that have gained you victory before.
Many thanks to Jeff Schumacher for help with editing the article.
