Threat Modeling: What, Why, and How?
Threat modeling is essential to becoming proactive and strategic in your operational and application security. Modern threat modeling is agile and integrative, building collaboration between security and other teams. That's security and development, security and operations, security and all sorts of others. Threat modeling is also essential in moving away from "gut feel" to a disciplined approach to problems.
There's a lot of confusion out there around threat modeling, and that's ok. In this paper, you'll learn what threat modeling is, how it relates to threat intelligence, and how and why to start.
What Is Threat Modeling?
If you think about security problems in the abstract, threat modeling is a fancy name for something you already know how to do. If I asked you to help me threat model my house, you could jump right in. You can do that even though you haven't been to my house, but you've been to enough houses that you have a mental model: houses have doors, locks, and windows.
Threat modeling is about building models, and using those models to help you think about what's going to go wrong. There are models implicit in most things. For example, in threat intelligence, you often receive IP addresses, email addresses, and similar "indicators." Implicit is that you'll plug those IPs into your firewall or IDS, or block or detect those emails at your mail server. There are also important details rarely discussed: Is your firewall from Palo Alto or Fortinet? Each has a different user interface, but each has a way to block an IP address.
Threat Modeling Versus Threat Intelligence
If your business goal is to find today's attackers, then threat intelligence can help you focus your attention on the precise actions they might be taking today. But if all you ever do is look for attackers and would-be attackers, you might feel your life is a lot like Groundhog Day, without the learning and improvement.
If your goal is to reduce your attack surface and focus your investments in a proactive way, then threat modeling can help you do that. Threat modeling is unlikely to provide the quick hit that threat intelligence can, but it can help you drive a more strategic program.
Why Threat Model?
Many security leaders find themselves trapped in the moment—the moment of a news cycle, the moment of an incident. Being strategic requires that you move from seeing the leaves on a tree, through to seeing the whole forest, to communicating about the forest. Threat modeling gives you the way of seeing the forest, and a frame for communicating about the work that you (and your team) are doing and why you're doing it.
More concretely, threat modeling involves developing a shared understanding of a product or service architecture and the problems that could happen. This understanding allows you to be proactive and to either move ahead of security issues or at least prioritize them. Additionally, because you're starting at the architectural level, you can focus your work on the systems that are most important, rather than responding to "random" issues from penetration testing or compliance.
Because threat modeling uses models, you can apply the same overall approach across software development and operations, leading to more effective communication and collaboration.
How To Threat Model
The simplest approach to threat modeling works through answers to four fundamental questions:
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?
What Are We Working On?
We start from the question, "what are we working on," because we ought to be able to answer it. That sounds obvious, perhaps even eyebrow raising, but there are other approaches to threat modeling whose starting points (attackers, assumptions) may be harder to enumerate or differentiate.
The way you answer "what are we working on" can be flexible, but I like to start by gathering a set of people together near a whiteboard. The set of people should include an architect on the system, a tester, a security person, and if you do one of the forms of agile that includes a customer advocate, bring them too. You can bring in more than one of each type of person. I like getting every architect in the room and letting them argue about what they're working on. It's not truly security, but driving alignment delivers speed and efficient development, and as they argue, everyone else is learning how the system actually works.
You might end up with a diagram like this: 
The above is a typical whiteboard diagram (except I drew it in PowerPoint because no one should have to see my handwriting). And I drew in a trust boundary for "our app." A trust boundary, usually represented as a dotted line, is the boundary of what's under your direct control. It's your code, your database, your data center. Many times, diagrams will have more than one boundary, which is fine. For example, a three-tier app might have a presentation layer walled off from the business logic, which is separate from data storage, and there are boundaries enforced between them for reliability reasons.
What Can Go Wrong?
Given a simple diagram like the one above, we can start thinking about what can go wrong. How does the web app know which customer is which? (And how picky do we need to be about the answer? For instance, I care more about what can go wrong when the app is for payroll than a web comic.) What about the content creation process? How does it collect data? And the database?
If you spend a much time in security, you might realize that I'm talking about authentication. Failures of authentication are often called "spoofing," and spoofing is the first element of a handy mnemonic, STRIDE:
Spoofing
Tampering
Repudiation (denial of the truth or validity of something)
Information Disclosure
Denial of Service
Elevation of Privilege
You can use STRIDE, walking through each part of the diagram (including the data flows!) and asking, "How could someone spoof this? How could someone tamper with this..." You can also look at each element of the diagram, and walk through each STRIDE threat: "How could someone spoof the database? How could someone tamper with it..."
Especially as you're starting, this process can feel intimidating, and so I created a game called Elevation of Privilege to help. The deck can be downloaded for free, or you can buy nicely printed copies.
As you go through the question of what can go wrong, write things down. Later on, file bugs, work items, or something similar to track them with the rest of the project. Also, you'll find yourself saying, "I assume" a lot. Write down those assumptions and see if you're right after you've finished.
Once you're done, take a minute to realize what you've accomplished. It might have been difficult, but you've created a list of things that can go wrong in a system you haven't built yet. Kudos to you! This is usually the very hardest part.
What Are We Going To Do About It?
When I work with organizations, 80-90% of the issues they find with threat modeling are reasonably straightforward to fix. The organization can apply an understood sort of mitigation to the issue, adding features or code to protect against the attack. Some examples include:
| Threat | Property | Mitigation approach (software development) |
|---|---|---|
| Spoofing | Authentication | Passwords, multi-factor authN Digital signatures |
| Tampering | Integrity | Permissions/ACLs Digital signatures |
| Repudiation | Non-Repudiation | Secure logging and auditing Digital Signatures |
| Information Disclosure | Confidentiality | Encryption Permissions/ACLS |
| Denial of Service | Availability | Permissions/ACLs Filtering Quotas |
| Elevation of privilege | Authorization | Permissions/ACLs Input validation |
For other issues, it's more complex, and for this short white paper, I'll refer you to my book, Threat Modeling: Designing for Security.
Did We Do a Good Job?
There's an easy part and a hard part to assessing how we did. The easy part is checking over your work:
- Look at the diagram. Does it represent the system well?
- Look at your list of threats. Did you find at least 5 threats per thing in the diagram, including data flows that connect systems?
- Did you file a bug per threat?
If you've missed any of those, you have not done a good job. Even if you have covered all those items, you still have the hard part: judgment. Did you do a good job at each? If this was your first time, then you did. I can say that because I'm an expert, and I know that you did infinitely better than not doing any threat modeling work at all!
Next Steps
Now that you know that threat modeling is important and you have an outline of how to start threat modeling, you should. There's nothing like building a new skill and bringing it to bear on a real problem. The first time you do anything, including threat modeling, you'll find yourself hesitant. When you do, fall back to the four questions:
- What are we working on?
- What could go wrong?
- What are we going to do about it?
- Have we done a good job?
Let those questions be your guide as you work through these things, and be careful with advice you find on the internet. It's of (ahem) varying quality, and often treats threat modeling as a single task or skill (which is like saying programming is one task; there's lots of tasks in both crafts).
In the next article in this series, we'll go beyond the individual skills, and speak to what's involved in managing a threat modeling program from the security leader perspective.