A simple mental model for Threat Modeling
Threat Modeling is a security activity that’s made more complicated than it should be. Presenting a simple mental model to approach threat modeling.
👋 Dear reader, hope you’re healthy and happy. In this post we will cover:
What is threat modeling, and why you should care
Why is it unique and complex
How to do threat modeling, and a simple mental model for it.
Buckle up!
Threat modeling, in cybersecurity, is a process of identifying, and mitigating potential threats to a system.
It is one of the many security activities, like SAST (Static Application Security Testing) aka secure code reviews; and DAST (Dynamic Application Security Testing) aka penetration tests. There are also techniques like runtime analysis or dependency checks, more relevant for microservices. And bug bounties, and IR gamedays among a few others. Among all these, threat modeling holds its place firmly.
Why do we need threat modeling? It’s all about money, baby. Also security. The primary objective of threat modeling is to identify potential security weaknesses early and address them before they become too expensive to fix. It also helps identify issues that cannot be found by other security activities by looking at design of a system. Like this ingenious #crappydesign below. No pentest or code review will find an equivalent issue, threat modeling will.
Not just that, the Open Web Application Security Project (OWASP), a non-profit security organization, produces a list of top 10 most critical security risks to web applications. The list is produced every 3-4 years and is widely used in cybersecurity. In its latest edition, “A04:2021 – Insecure Design” is a new entry at #4.
A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to "move left" as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.
(Source: OWASP / emphasis in bold mine)
So we understand why Threat Modeling is important. However, of all the security activities, it’s the wierdest: unique and complex.
Threat Modeling is unique because
It cannot be fully automated (yet), as it requires an analysis pedigree of humans.
It is simple to learn, but difficult to master. Just like learning how to drive or swim. (But unlike chess, which is also simple to learn, but very difficult to master)
It’s a human-centric security activity.
There are many, many techniques available for it. All are cumbersome.
Threat Modeling is complex because there are a bazillion ways to do it. Few popular threat modeling methodologies are Attack Trees (Schneir, 1998/99) which is an attacker centric visualization of threats; STRIDE (Microsoft, 1999) which is a developer centric mnemonic to cover basic security categories; ATT&CK framework (MITRE, 2013) is an intrusion centric knowledge base of tactics and techniques; and PASTA (Versprite, 2015), which is a risk centric threat modeling process popularly used at Gitlab. There are at least 10 others that I have come across, plus tens of their custom variations. Moral of the story is that there is no one size fits all. Probably some lead security architect in your organization preferred one approach over the other and introduced it - and now you’re stuck with it.
In all of these techniques though, the goal of the threat modeling is common:
To wear an attacker’s hat, and list out threats, rank them, and create practical mitigations.
A simple mental model
Over the years, I have developed a mental model that can be applied agnostic to the various techniques above. Obviously, this is what has worked for me and I am simply sharing it, not to introduce yet another technique, rather to share my learnings in a condensed format. First, follow these steps to build a threat model.
🗺 Step 0: Architecture - Find what to threat model.
Understand the system through whatever-the-hell you can find about it: business docs, technical docs, diagrams, demos, etc. Anything but code, as it will be distracting. Then identify scope and list assumptions. As you do these steps, try to see forest among the trees.
💰 Step 1: Assets - Find what to protect.
Identify “Assets” in the system. An asset is a data or functionality or component that needs to be protected. Examples:
A01 - Credentials
A02 - Credit Card Numbers
A03 - Transient data stored in memory for processing
A04 - Business Logic/Functionality. And so on..
🎭 Step 2: Threat Actors - Find who to protect from.
Identify “Threat Actors”, these are the internal or external malicious actors trying to compromise the system. Examples:
TA01 - Malicious insider, application admin
TA02 - Novice insider with access, user from another department
TA02 - Malicious outsider, script kiddie
TA03 - Malicious outsider, nation state. And so on..
🚦 Step 3: Controls - Learn about protections.
Identify “Controls” that are planned or are in place. Examples:
C01 - Single Sign On authentication
C02 - RBAC authorization
C03 - Encryption
C04 - Key management. And so on..
✍️ Step 4: Draw a threat model diagram
This can be a new simple architecture diagram, or an overlay on top of an existing diagram by marking trust boundaries (a trust boundary could be a network boundary, a compute unit or a data store, etc.), assets, threat actors, and controls. Here’s a good sample (source).
💥 Step 5: Enumerate threats
Now that you’ve understood the system → listed assets → listed threat actors → listed controls → drawn a threat model diagram with trust zones; you can start writing threats.
How do you write the threats? Do you refer to a threat library (like the one provided by the ATTACK framework) and select the ones relevant for you, but then what’s the point of all this hoopla? Do you just write what comes to mind (“what could go wrong”), but then will it be exhaustive, and is it a structured approach?
This is where most threat modeling techniques leave you in the dark. And this is where the mental model comes into play.
🧠 If a “threat actor” can acquire an “asset” by abusing/bypassing a “control”, you’ve a “threat”.
So, review the threat model you’ve in front of you section by section (or asset by asset), and see if a threat actor can compromise/steal an asset due to a missing or weak security control across a trust zone, if yes, there’s your threat. Yes, you’d need some security experience or training to do so. Yes, a threat library will help. No, it cannot be fully automated. And yes, you can do it. Let’s illustrate this with a few examples.
In the diagram above, locate TA01 (malicious user) and TA04 (compromised wordpress blog). TA01 is able to steal A04 (blog admin credentials) because there is no security control at the wordpress blog and also because it is compromised due to TA04. (This is a general example, so there are many assumptions here, for e.g., TA04 could be due to an unpatched wordpress engine). So our threat becomes:
Threat: A malicious user steals wordpress credentials from the wordpress blog admin console
Mitigation: 1) Patch Wordpress to latest version. 2) Require any user to authenticate using strong credentials and MFA before accessing the compromised.
Let’s take another example:
Threat: Launch Distributed-Denial-of-Service (DDoS) attack to XYZ application at the frontend.
Mitigation: Follows the recommendations of AWS Best Practices for DDoS Resiliency whitepaper: Filter out bad requests (CloudFront and API Gateway endpoint only accepts well-formed HTTP requests), managed services can automatically scale to absorb attack (and the user can also apply throttling limits in API Gateway or restrict access using AWS GeoIP block).
👷♂️ Step 6: Put threats to action
Once you’ve created threats and written some practical mitigations to remove or reduce the risk, you need to convert the threats to something actionable like a developer user story and corresponding tasks. Here’s a sample for it.
Wrapping it up
The thing with mental models is that you form them on your own accord through: processing information → identifying key concepts → deliberate practice → testing your understanding → and → experience. My goal here is to give you a reference pointer on how my mental model looks when it comes to threat modeling, and inspire you (doesn’t matter if you’re a security SME or a software dev) to take on threat modeling.
In future related posts, I will share some end to end threat models of public systems; and how to scale threat modeling at the speed of your business. If you’ve ideas, requests or suggestions, let me know.
📕 Security Wale is a blog about cloud, cybersecurity, and in between - written by Aditya Patel (more here). To support this effort, consider subscribing (it’s free) and spreading the word.