Threat modelling is a structured way to work out how an attacker could go after a system, and what you will do about it, before anything is built or buried in production. You draw the system, list what could go wrong, decide on a response for each risk, and then check your own work. That is the short version. The rest of this guide explains how it works in practice for a UK business.
Table of Contents
What is threat modelling in plain terms?
OWASP describes it as a structured way to identify, communicate and understand threats to something valuable, along with the mitigations for them. The result is usually a prioritised list of security improvements.
Think of threat modelling as a design review run from the attacker’s chair. Instead of asking whether the system works, you ask how someone could make it misbehave. A payment form, a customer portal and a cloud storage bucket all look different when you ask that question.
It is also known as threat modeling (the US spelling), and some teams call the output a threat model or an attack model. They all mean the same activity.
What are the four questions behind a threat model?
Most methods trace back to a simple framework from security author Adam Shostack. OWASP uses the same four questions as its starting point:
- What are we working on? Define the scope. It can be one new feature or a whole platform.
- What can go wrong? Brainstorm threats, ideally with a structured method such as STRIDE.
- What are we going to do about it? Mitigate, accept, transfer or eliminate each risk.
- Did we do a good job? Check that the model covers the system and that the fixes are tested.
None of this needs special software. Because the method is so light, a whiteboard and an hour with the right people will get you most of the value.
How does the STRIDE method work?
STRIDE is a memory aid for six kinds of threat. Microsoft uses it to categorise problems and to make security conversations simpler. Each letter points to a security property that an attacker is trying to break.
| Threat | What it means | Property it attacks |
|---|---|---|
| Spoofing | Using someone else’s credentials or identity | Authentication |
| Tampering | Changing data in storage or in transit | Integrity |
| Repudiation | Doing something that cannot be traced back to you | Non-repudiation |
| Information disclosure | Reading data you should not see | Confidentiality |
| Denial of service | Making a service unusable for real users | Availability |
| Elevation of privilege | Gaining access beyond what you were given | Authorisation |
You walk through each part of your diagram and ask which of the six could apply. A login page invites spoofing. A database invites tampering and disclosure. An admin panel invites privilege escalation.
How do you build a threat model step by step?
OWASP’s process runs in four steps. Here is how that looks for a small team.
1. Map the system
Draw a data flow diagram. Show where data enters, where it is stored, who can reach it, and where trust changes (for example, between the internet and your internal network). List the assets worth protecting, such as customer records, payment data or admin accounts.
2. Identify the threats
Take each element and each trust boundary and ask what could go wrong. STRIDE works well here. Attack trees and kill chains are other options. Aim for breadth first, and rank later.
3. Decide what to do
For each threat you can reduce it, remove it, accept it or pass it to someone else, such as an insurer or a supplier. Be honest about the last one. OWASP’s guidance warns that transferring risk does not lower the chance or impact of an attack, so the leftover risk still needs recording.
4. Check the work
Confirm that you have a diagram, a threat list and a list of controls. Then decide how each control will be tested. A mitigation nobody has verified is a hope, not a control.
When should you do threat modelling?
Early, and then repeatedly. OWASP advises starting with a high-level model during planning and refining it as the design firms up. Revisit it after a new feature ships, after a security incident, and after major changes to architecture or infrastructure.
Fixing a design flaw on paper costs very little, but fixing it after launch can mean rewriting how a system handles data. That gap is the main reason to do the work early.
Who should be in the room?
The whole delivery team, not only security staff. OWASP’s cheat sheet says less technical people can contribute through brainstorming, and that the final model should be reviewed by every stakeholder. Developers know how the system really behaves. Security specialists know how attackers think. You need both.
Shostack’s guide lists developers, testers, architects, operations teams, project managers, penetration testers and business managers among those who can use the technique.
How is threat modelling different from a penetration test?
They answer different questions at different times. A threat model works on the design and asks what could be attacked. A security test works on the real thing and shows what an attacker can actually do today.
The two feed each other. A model tells testers where to look hardest, and test results show whether your assumptions held. If you are weighing up which to buy first, our plain guide to whether you need a penetration test is a good place to start.
It also differs from a risk assessment. Shostack’s guide frames threat modelling as finding the attacks that could hit a system, while risk management decides how to respond to the problems found. Our article on the cyber security risk assessment covers that second half.
What are the common mistakes?
OWASP’s cheat sheet lists several traps that apply to any size of business:
- Treating it as a one-off. A model that is never updated drifts away from the system it describes.
- Relying on shaky scores. Likelihood times impact is hard to estimate and ignores how much effort a fix takes.
- Piling on techniques. Adding methods to look thorough, without a reason for each, wastes time.
- Skipping verification. If nobody defines how mitigations will be tested, you never learn whether they work.
- Weak security knowledge. Developers can miss or misjudge threats without some training or a security specialist alongside.
What does a small business need to start?
So pick one system that matters, such as your customer portal or your payment flow. Book 90 minutes with a developer, someone from operations and someone who owns the business process. Draw it, run STRIDE over it, and write down the top five actions. That is a real threat model, and it will beat a perfect one that never happens. Then repeat it for the next system.
If you would rather have an outside view, Aardwolf Security can scope a penetration test around the threats you identify, or you can get in touch to talk it through. The model stands on its own either way.
Frequently asked questions
Is threat modelling only for software developers?
No. It applies to any system with valuable assets, including networks, cloud setups and business processes. Software teams use it most, but the questions work anywhere.
How long does it take?
A focused session on one feature can take an hour or two. A model for a large platform takes longer, so build it up over several sessions. Start small and expand.
Do we need special tools?
Not to begin with. Microsoft offers a free Threat Modeling Tool built around STRIDE and designed for non-security experts, but a whiteboard works fine.
How often should we update a threat model?
Whenever the system changes in a meaningful way: a new feature, a new supplier, a move to the cloud, or after an incident.
Does a threat model replace testing?
No. It shows where the risks sit, and testing shows whether the defences hold. You want both.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
