Threat Modelling: How to Think Like an Attacker

Early in my career I watched a team spend three months hardening a web application against SQL injection, cross-site scripting and every item on the OWASP list they could find. Good work, genuinely. Then the company lost its customer database because a salesperson exported it to a spreadsheet, put the spreadsheet in a personal cloud drive to work from home, and used a password that had been in a public breach for two years.

Nothing on the OWASP list would have stopped that. The team had defended the front door beautifully while the data walked out of a window nobody had looked at. That's not a failure of skill. It's a failure of modelling: nobody had sat down and asked who wanted the data, what they'd do to get it, and which paths were actually open.

Threat modelling is the discipline of asking those questions on purpose. It's the second foundation of information security, sitting directly on top of the CIA triad, and it is the single highest-leverage activity I know of.

Part 2 of 10 · Foundations of Infosec. Previous: The CIA Triad. Next: Risk Management.

Key takeaways

Threat modelling (threat modeling, in US spelling) answers four questions: what are we working on, what can go wrong, what will we do, did we do a good job.
Draw the system and its trust boundaries first — most findings appear while drawing.
STRIDE finds weaknesses per component; attack trees show which ones chain into real attacks.
Every threat gets one of four responses: mitigate, eliminate, transfer or accept — written down.

Threat modelling in four questions

Adam Shostack, who spent years running threat modelling at Microsoft and wrote the standard book on the subject, boils it down to four questions:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

That's it. Every framework, diagram and acronym in this field is a technique for answering one of those four questions more rigorously. If you keep them in your head you can threat model anything — a web app, a warehouse, a wedding — in an afternoon.

Question 1: What are we working on?

You cannot model what you haven't described. The first step is to draw the system: the pieces, the data that moves between them, and — this is the important part — the trust boundaries, the lines where the level of trust changes.

A data flow diagram is the classic tool. Boxes for processes, lines for data flows, cylinders for data stores, and dashed lines for trust boundaries. A browser talking to your API crosses a trust boundary. Your API talking to your own database usually doesn't (though in a zero-trust design it might). An employee's laptop on the office network is inside one boundary; the same laptop in a café is outside it.

Most teams skip this step because "everyone knows how the system works". In my experience, no two people in the room have the same picture, and the act of drawing it out produces the first three findings before you've even started looking for threats. The salesperson's spreadsheet in my story? It would have appeared on the diagram as a data flow leaving the trust boundary with nothing protecting it.

Keep the diagram at the right altitude. You're not documenting every function call. You're capturing where data lives, where it moves, and where it changes hands.

Question 2: What can go wrong?

This is the creative part, and the part people find intimidating. "How am I supposed to know what attackers will do?" You don't need to be an attacker. You need a structured way of prompting your imagination. Two techniques cover most needs.

STRIDE

STRIDE was developed at Microsoft in 1999 by Loren Kohnfelder and Praerit Garg and remains the most widely used mnemonic. For each element of your diagram — especially each data flow crossing a trust boundary — you ask whether it's vulnerable to:

Spoofing — pretending to be someone or something else. Can a request claim to come from a user who didn't send it?
Tampering — modifying data or code. Can the data on this flow be altered in transit or at rest?
Repudiation — denying having done something. If a user disputes an action, can we prove it?
Information disclosure — exposing data to the wrong party. What leaks here, including in error messages and logs?
Denial of service — making the system unavailable. What happens if this component is flooded or crashes?
Elevation of privilege — doing more than you're allowed. Can an ordinary user reach an admin function?

You'll notice STRIDE maps neatly onto the CIA triad plus authentication, non-repudiation and authorisation. That's not a coincidence; it was designed as a checklist of ways the security properties fail.

The magic of STRIDE isn't that it's clever. It's that it forces you to consider every category for every element. The threats you'd never have thought of unprompted — "what if someone tampers with the log file?" — get asked because the process makes you ask.

Attack trees

Bruce Schneier popularised attack trees in 1999. You write the attacker's goal at the root — "read customer credit card numbers" — and branch downward into the ways of achieving it, and the ways of achieving each of those, until you reach concrete steps. Each leaf can be annotated with cost, difficulty, or required access.

Attack trees are goal-oriented where STRIDE is component-oriented, and the two complement each other. STRIDE finds weaknesses; attack trees show which weaknesses actually chain together into something an adversary would bother doing. Very often you'll discover that a "critical" vulnerability is a leaf on a branch that also requires physical access to a server room, while a "low" issue is the first step on the shortest path to the crown jewels.

Know your adversaries

Whichever technique you use, ground it in real adversaries. Not "hackers" — specific types of people with specific motives and resources:

Opportunistic criminals running automated scans for known vulnerabilities and reused passwords. They don't target you; they target whoever is easiest. This is the vast majority of what hits a small business.
Financially motivated groups running ransomware or business email compromise. They will spend days inside your environment if the payout justifies it.
Insiders — malicious or, much more often, careless. The Verizon DBIR has for years found that the majority of breaches involve a human element, whether error, misuse or falling for social engineering.
Competitors and state actors, for a small number of organisations. If you're not one of them, don't design as if you are; you'll spend the budget in the wrong places.

The public catalogue of real attacker behaviour is MITRE ATT&CK, which documents the tactics and techniques observed in actual intrusions. When you're wondering whether a threat is realistic, ATT&CK will tell you whether anyone actually does it.

Question 3: What are we going to do about it?

For each threat you've identified, you have exactly four options:

Mitigate — add a control that reduces likelihood or impact. This is the default assumption, but it's not always the right one.
Eliminate — remove the feature or the data so the threat no longer applies. Often the cheapest and most reliable option. Do you actually need to store the card number, or just the last four digits and a token?
Transfer — make it someone else's problem, contractually or via insurance. Using a payment processor transfers most card-handling risk to a company whose whole business is handling it.
Accept — decide the risk is tolerable and document that decision. Legitimate, as long as it's a decision and not an oversight.

Write down which you chose and why. A threat model with no recorded decisions is a list of worries; a threat model with decisions is a plan.

Prioritisation matters. You will find more threats than you can address. Rank by the combination of how likely the threat is and how bad the outcome would be — the same likelihood-times-impact reasoning that underpins all risk management — and be honest that "likely" for an opportunistic attack on an internet-facing login form means "certain, continuously".

Question 4: Did we do a good job?

A threat model is a living document. It should be revisited when the system changes materially, when a new class of attack appears in the wild, and after any incident. The last one is the most valuable: every incident is a threat that your model either missed or under-weighted, and the retrospective should update the model, not just fix the bug.

Check the model against reality, too. If your model says the API can't be reached from the internet and a penetration tester reaches it in ten minutes, the model was wrong, and being wrong is the thing to fix.

Threat modelling outside software

I want to be explicit that none of this is limited to code. The salesperson's spreadsheet was a business process problem. The four questions apply just as well:

What are we working on? A quarterly sales review, with data exported from the CRM to be discussed offsite.
What can go wrong? The export is emailed (information disclosure), edited on a personal device (tampering, disclosure), left in a cloud drive indefinitely (disclosure), and the process depends on one person (availability).
What do we do? Present from within the CRM instead of exporting (eliminate). If export is unavoidable, use a company-managed shared location with expiry (mitigate). Add "delete export after review" to the checklist (mitigate).
Did we do a good job? Ask next quarter whether the export still exists.

I run this exact exercise with founders on their onboarding and offboarding processes, their supplier payment process and their customer support access. It finds more real risk than any scanner.

A first threat model this week

If you have never done this, here's a way to start that takes about ninety minutes.

Pick one system that matters. Draw it on a whiteboard with your team: components, data flows, trust boundaries. Then, for each flow crossing a boundary, walk through the six STRIDE letters out loud and write down every threat anyone raises, without arguing about whether it's realistic yet. You'll have twenty to forty items.

Now rank them. For the top five, decide: mitigate, eliminate, transfer or accept. Write the decisions down with a name and a date next to each.

That document, however rough, puts you ahead of most organisations. More importantly, the people in the room will never look at the system the same way again. They'll have started thinking like the person attacking them — which is the only reliable way to stay ahead of one.

Further reading

Adam Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
Loren Kohnfelder and Praerit Garg, "The threats to our products" (Microsoft, 1999) — the origin of STRIDE
Bruce Schneier, "Attack Trees", Dr. Dobb's Journal (December 1999)
MITRE ATT&CK — attack.mitre.org
OWASP Threat Modeling Cheat Sheet
Threat Modeling Manifesto — threatmodelingmanifesto.org

This series