What is Threat Modelingand What Are the Methods to Do It?
Introduction
Imagine you are building a new house. You lock the doors, install security cameras, and put bars on the windows. But what if someone breaks in through the garage? Or climbs in through a second-floor window you forgot to close? Or pretends to be a delivery person to get inside?
That is exactly what threat modeling does. Nowadays, it should be done for software, apps, websites, and now AI systems. It is a structured way of asking: "What could go wrong here, and how do we stop it from happening?"
A threat is simply anything that can go wrong and harm a system, whether it is a hacker trying to steal data, an employee accidentally deleting important files, or a user doing something they are not supposed to. Threat modeling helps you catch these problems early, when they are cheap and easy to fix, rather than after a breach, when it is too late.
According to OWASP (Open Web Application Security Project), "threat modeling works to identify, communicate, and understand threats and mitigations within context." A threat model represents all information affecting application security through a security lens.
Another perspective frames this as "structured foresight": identifying what you are building, potential failures, and prevention strategies. Microsoft specifically designed threat modeling approaches to be accessible to all developers, not exclusively security specialists.
Why Should You Care About Threat Modeling?
Many people think: "We will just fix security problems after we build the system. Why spend time planning now?"
Here is the problem: fixing a security flaw after your system is live is like trying to add a fire escape after the building is already on fire. It is expensive, messy, and often too late.
By doing threat modeling early, you can:
- Shape your design before it is too late: Influence architecture decisions based on security considerations rather than adding security as an afterthought.
- Meet your security goals: Ensure your application meets your organization's security requirements and compliance obligations.
- Reduce risk systematically: Identify and address threats during design instead of discovering them in production.
- Focus on what matters most: Prioritize security efforts on the most significant threats rather than trying to address everything at once.
- Communicate clearly across teams: Provide a common language that developers, security teams, and business leaders can all understand.
The Four Simple Questions
You do not need a PhD in cybersecurity to start threat modeling. Adam Shostack, one of the leading experts in threat modeling, suggests starting with just four simple questions to organize your thinking.
| Question | Meaning | Example |
|---|---|---|
| What are we building? | Understand the system | Online store with credit card payments |
| What can go wrong? | Identify threats | Credit card theft |
| What are we going to do about it? | Add protections | Encrypt card data |
| Did we do a good job? | Verify security | Test encryption |
These four questions form the backbone of any threat modeling exercise. The rest is just about learning better techniques to answer each question.
When Should You Do Threat Modeling?
Threat modeling is not a one-time task. It should happen throughout the software development lifecycle.
- Early in planning: Start with a high-level threat model in the concept phase. Ask the four questions above at a broad level.
- During design: As you add more details to the architecture, update your threat model to check for new risks.
- When things change: Update the threat model every time you add a new feature, change infrastructure, or experience a security incident.
For example, when you decide to use a specific technology, like a particular database or programming language, you take on new security responsibilities. New technologies bring new threats, and your threat model needs to account for them.
Popular Threat Modeling Methods (Frameworks)
Different situations call for different approaches. Here are the most widely used threat modeling methods.
STRIDE: The Systematic Checklist
Developed by Microsoft, STRIDE is the most popular threat modeling method. It gives you a simple checklist of six threat categories to consider.
| STRIDE Letter | Threat Type | What It Means | Real-World Example |
|---|---|---|---|
| S | Spoofing | Someone pretending to be someone else | A hacker steals a user's password and logs into their account |
| T | Tampering | Someone modifying data they should not be able to change | An employee changes their salary amount in the database |
| R | Repudiation | Someone denying they did something because there is no proof | A user sends a fraudulent message and deletes the logs to hide it |
| I | Information Disclosure | Data being exposed to the wrong people | A customer's credit card number is accidentally shown in a webpage |
| D | Denial of Service | Making the system unavailable | Attackers flood the website with so many requests that real users cannot access it |
| E | Elevation of Privilege | Someone gaining higher access than allowed | A normal user finds a way to get administrator privileges |
Why use STRIDE? It is simple, easy to remember, and covers a broad range of threats. It is great for beginners and for conducting a quick security sweep of any system. However, STRIDE was not designed for modern AI systems because it struggles with AI-specific risks like prompt injection or model poisoning.
DREAD: Prioritizing What Matters Most
STRIDE helps you find threats, but it does not tell you which threats are the most dangerous. That is where DREAD comes in. DREAD is a scoring system that helps you rank threats so you know what to fix first.
Each threat gets a score from 1 to 5 in five categories:
| DREAD Letter | Category | 1 (Low Risk) | 5 (High Risk) |
|---|---|---|---|
| D | Damage Potential | Minor inconvenience | Major data breach or financial loss |
| R | Reproducibility | Hard to replicate | Easy to replicate every time |
| E | Exploitability | Needs specialized skills | Anyone with basic skills can do it |
| A | Affected Users | Only a few users affected | All users affected |
| D | Discoverability | Hard for attackers to find | Easy to discover |
For example, a credit card theft threat might score: Damage (5), Reproducibility (4), Exploitability (4), Affected Users (5), and Discoverability (3), where Total: 21, meaning it needs urgent attention. A minor bug might score only 12, which can wait.
PASTA: The Attacker's Mindset
PASTA (Process for Attack Simulation and Threat Analysis) takes a different approach. Instead of just listing threats, PASTA asks: "How would an actual attacker think and act?" It follows a seven-stage process:
- Define objectives
- Define technical scope
- Decompose the application
- Analyze threats
- Analyze vulnerabilities
- Model attacks
- Analyze risk and impact
PASTA is more complex and takes more time and resources than STRIDE, but it is excellent for understanding the business impact of threats. It helps you prioritize based on what truly matters to your organization.
LINDDUN: Protecting Privacy
LINDDUN focuses specifically on privacy threats rather than general security. It stands for: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of Information, Unawareness, and Non-compliance. If your system handles sensitive personal data or must comply with privacy laws like GDPR, LINDDUN is an excellent choice.
A Simple Comparison
| Framework | Core Focus | Best For | Complexity |
|---|---|---|---|
| STRIDE | General Security & Threats | Quick security check; beginners | Low |
| DREAD | Risk Prioritization | Ranking which threats to fix first | Low |
| PASTA | Risk & Attacker Analysis | Deep analysis; business impact focus | High |
| LINDDUN | Privacy Threats | Systems with personal/private data | Medium |
For most teams, the best approach is to use these frameworks together. Start with STRIDE to find threats, then use DREAD to prioritize them, and consider PASTA for high-risk components.
A Simple Example: Securing an Online Store
Let us work through a basic example to see how threat modeling works in practice.
Step 1: Describe what you are building
An online store where customers create accounts, browse products, add items to a cart, and pay using credit cards. Customer information is stored in a database.
Step 2: Ask what could go wrong (using STRIDE)
| Threat Type | Potential Problem |
|---|---|
| Spoofing | An attacker steals a customer's password and buys products using their credit card |
| Tampering | A hacker changes product prices (e.g., changes a $100 item to $1) |
| Repudiation | A customer orders an expensive product and later claims they never placed the order |
| Information Disclosure | Credit card numbers are exposed because the database was not encrypted |
| Denial of Service | Attackers overwhelm the website so real customers cannot access it |
| Elevation of Privilege | A normal user finds a way to access the admin dashboard and change system settings |
Step 3: Decide what to do about high-priority threats (using DREAD)
A credit card exposure threat has high damage (5), is easy to reproduce (5), does not require special skills (5), affects many users (5), and is moderately discoverable (3), with a total score of 23. This is your top priority.
Mitigations: Encrypt all credit card data, use a secure payment processor, enforce HTTPS for all transactions, and regularly scan for vulnerabilities.
When to Use Which Method
- Small project or learning threat modeling for the first time: Start with STRIDE. It is simple and covers the basics.
- You have a list of threats but do not know which are most dangerous: Use DREAD to prioritize.
- Your system handles sensitive customer data and must comply with privacy regulations: Add LINDDUN to your toolkit.
- You are building a critical system where security failures could cost millions: Invest the extra time in PASTA for deep analysis.
Common Mistakes to Avoid
| Mistake | Why It Is a Problem |
|---|---|
| Doing threat modeling only once at the beginning | Systems evolve; new features and technologies introduce new threats |
| Making it purely a security team responsibility | Developers and business stakeholders need to be involved: they know the system best |
| Trying to fix every threat | Not every threat needs to be fixed. Accept some risks; transfer others (like using insurance) |
| Not documenting your analysis | Without documentation, you cannot verify that mitigations actually work or explain to auditors |
| Overcomplicating the process | Start simple. Even a basic STRIDE analysis is better than no analysis at all |