Threat modelling: STRIDE, attack trees and data-flow diagrams

What threat modelling is

Threat modelling is the activity of examining a design to find what could go wrong with its security, and deciding what to do about it, before attackers or incidents find it for you. It is the main way security principles become concrete decisions, and the most direct answer to the OWASP category of insecure design: flaws that no amount of correct coding can fix because the needed control was never designed in.

Adam Shostack, who led threat modelling work at Microsoft and wrote the standard book on it, reduces the activity to four questions. What are we working on? (a model of the system, usually a diagram). What can go wrong? (threats, found systematically). What are we going to do about it? (mitigate, eliminate, transfer or accept each threat). Did we do a good enough job? (review the model, the threats and the follow-up). Any method that answers the four questions is threat modelling; the rest of this section describes the techniques most teams use to answer them.

In 2020 a group of practitioners, including Shostack, published the Threat Modeling Manifesto, modelled on the Agile Manifesto. It values a culture of finding and fixing design issues over checkbox compliance, people and collaboration over processes and tools, a journey of understanding over a one-off security snapshot, doing threat modelling over talking about it, and continuous refinement over a single delivery. Its point is that threat modelling is a habit of the team that builds the system, not a document produced by outsiders once a year.

Modelling the system: data-flow diagrams and trust boundaries

The first question needs a model of the system that shows where data goes and where trust changes. The traditional choice is a data-flow diagram (DFD) with five kinds of element: external entities (people or systems outside your control, drawn as rectangles), processes (code that you run, drawn as circles or ellipses), data stores (databases, files, queues and caches, drawn between two parallel lines), data flows (arrows showing data moving between the others) and trust boundaries (dashed lines or boxes where the level of trust changes).

DFDs suit threat modelling because attacks follow data: every flow that crosses a trust boundary is a place where an attacker can inject, intercept or replay something. A C4 container diagram from Chapter 4 is a good starting point; add the trust boundaries, make every arrow a data flow with a direction and a label, and include the stores and queues that container diagrams sometimes leave implicit. Keep the diagram at the level where threats are found: one diagram per significant feature or flow is more useful than one huge diagram of everything.

Finding threats with STRIDE

STRIDE was created at Microsoft in 1999 by Loren Kohnfelder and Praerit Garg as a mnemonic to help developers think about threats to their products. Each letter names a category of threat, and each category is the violation of one security property, which is what makes it useful: it is a systematic prompt, not a list of known attacks.

A practical way to apply STRIDE is STRIDE per element: walk through every element of the DFD and ask only the questions that apply to its type. External entities can be spoofed and can repudiate; processes are exposed to all six categories; data stores to tampering, information disclosure and denial of service (and to repudiation when the store is a log); data flows to tampering, information disclosure and denial of service. Spending most attention on flows that cross trust boundaries keeps the exercise focused.

STRIDE finds threats; it does not rank them or choose mitigations. Its categories also overlap in practice (a spoofed identity usually leads to information disclosure or elevation of privilege), which does not matter: the goal is to find the threat, not to classify it perfectly. For privacy threats, such as linking or identifying people from data that looks harmless, the LINDDUN method from KU Leuven plays the role that STRIDE plays for security; it is discussed with privacy by design.

Attack trees

An attack tree, popularised by Bruce Schneier in a 1999 article in Dr. Dobb's Journal, looks at the system from the attacker's side. The root is a goal, such as getting meals without paying; each child is a way of reaching its parent. Children of an OR node are alternatives; all children of an AND node are needed together. Leaves can be annotated with properties such as cost, skill needed, or whether the step is possible at all, and those values propagate up the tree: the cost of an OR node is that of its cheapest child, the cost of an AND node the sum of its children.

Attack trees complement STRIDE well. STRIDE walks the design element by element and is good at coverage; an attack tree follows a motivated attacker and is good at showing which path is cheapest and therefore where a mitigation buys most. In the tree below, paying with a stolen card is relatively costly because it needs two things at once, while changing the price in the client request is trivial if the server trusts it. The cheapest path sets the risk, so recomputing every price on the server is worth more than any amount of card-fraud tuning.

Rating risk

A threat model typically finds more threats than a team can address at once, so each needs a rating. The usual approach is to judge likelihood (how easy, how attractive, how exposed) and impact (what is lost if it happens: money, personal data, availability, reputation, legal exposure) on simple scales such as low, medium and high, and to combine them in a matrix. The value of the rating lies less in the precision of the number than in a written reason that others can challenge. Organisations with mature risk management sometimes use quantitative methods such as FAIR (Factor Analysis of Information Risk) to express risk as a range of expected loss.

Two popular shortcuts are worth knowing because they are often misused. DREAD (damage, reproducibility, exploitability, affected users, discoverability), once used at Microsoft, scored each threat on five factors (often from 1 to 10) and averaged them. It fell out of favour, including at Microsoft, because different people scored the same threat very differently and the averaged number gave a false sense of precision; discoverability in particular rewards obscurity, which contradicts open design. CVSS, the Common Vulnerability Scoring System maintained by FIRST (version 4.0, 2023), is the right tool for a different job: rating the severity of a known vulnerability in a product, such as a flaw in a library. Its base score describes the vulnerability, not the risk of a design threat in your context, so it should not be used to rank the output of a threat model.

Every threat ends in one of four decisions: mitigate (add a control), eliminate (remove the feature or the data, often the best option), transfer (let someone better placed carry it, such as a payment provider holding card data) or accept (record that a person with the authority to do so has accepted the residual risk, and why). Unrecorded acceptance is the most common failure: the threat was found, nobody fixed it, and nobody decided not to.

The answers to the last two questions are as important as the table. Each mitigation becomes a backlog item with an owner; T3 and T4 also become security scenarios with automated tests (a webhook with a bad signature must be rejected; a call to Payments from any identity other than Orders must fail). The two architectural decisions, hosted payment fields and mutual TLS between Orders and Payments, are recorded as ADRs. For the fourth question, the team reviews the model a month later against what was actually built, and the security champion checks that every high-risk item was either mitigated or explicitly accepted.

When and how often to threat-model

Threat modelling pays off most at design time, when changing a decision costs a whiteboard eraser. It should then be repeated whenever something significant changes: a new trust boundary or external integration, a new kind of sensitive data, a change to authentication or authorisation, a new deployment environment, or a move from a monolith to services. A sensible rule is to make "does this change the threat model?" a question in design reviews and in the template for architecture decision records, and to schedule a review of each system's model at least yearly and after every security incident.

The effort should be proportionate, in the spirit of the risk-driven approach in Chapter 1. A new microservice that processes payments deserves a half-day session with a full DFD; adding a field to a public menu needs five minutes and a STRIDE glance at the changed flow. Many teams keep their DFD as code next to the system (OWASP Threat Dragon and Microsoft's Threat Modeling Tool are free diagramming tools, and libraries such as OWASP pytm generate diagrams and candidate threats from code), so that the model is reviewed and updated with the system it describes.