Threat modeling is the structural upstream of security work: a brief, scheduled session that asks “what could go wrong, who could make it go wrong, and what controls close each path?” Done once at project start, it produces a document nobody reads. Done iteratively, tied to design changes, it produces the security equivalent of a test suite’s red→green loop — gaps found and closed before code ships.

This topic is the practiced craft, not the doctrine.

Why Once Is Wasted

Threat models decay. A model produced at design time describes the system the team intended to build; the system that reaches production has three new features, two changed data flows, and a dependency nobody called out. The threat model that doesn’t get revisited when the design changes misses every new attack surface.

The discipline of threat modeling is the cadence, not the document:

• At design start — every meaningful new feature begins with a 30-minute whiteboard.
• At design milestone — a 60-minute review before the design is approved.
• At ship readiness — a 90-minute review against the as-built system.
• At architectural change — every meaningful design change re-opens the model.

The output is not a 30-page slide deck; it is a maintained list of threats with mitigations on a per-element data-flow diagram, updated as the design evolves.

The Four-Step Method

Adam Shostack’s method, the industry default:

1. Model the system — diagram the data flow. Assets, trust boundaries, processes, and data stores are explicit.
2. Find threats — apply a checklist framework (STRIDE) against every element of the diagram.
3. Rank threats — pick which to address first (DREAD, or risk-reward judgement).
4. Mitigate — design controls closing each threat; verify controls are implemented.

Each step is short — the goal is to do them on a whiteboard, not in a slide deck. The conversation matters more than the document.

Step 1: Model the System — The Data-Flow Diagram

The threat surface is the data-flow diagram (DFD). A DFD has four primitives:

Trust boundaries — drawn as dotted lines around groups of processes that share a trust level — are the most important element of the diagram. Every arrow that crosses a trust boundary is an attack surface; arrows that stay inside a trusted zone are not.

The DFD usually fits on one whiteboard. If yours doesn’t, your threat model is too big and must be decomposed.

Step 2: STRIDE — Finding Threats per Element

STRIDE is an acronym of six threat classes, applied per element of the DFD. Each class maps onto a security property it violates:

The matrix of element × STRIDE class produces a structural enumeration of threats. The point is not creativity — it is completeness. Enumerating every cell of the matrix catches the threats that creative brainstorming misses.

The matrix turns “find the threats” into “ask six questions per process”. A small DFD with five processes, two stores, and three external entities yields ~40 enumerated threat candidates in a structured half-hour.

Step 3: DREAD — Ranking Threats

Once threats are enumerated, they must be ranked — there are always more threats than the team can address at once. DREAD is the classic ranking score, summed across five 1–10 dimensions:

The score is the average — a 1–10 integer per threat. Two truths:

1. The score is a conversation tool, not a measurement. What matters is the dialogue that produces the score: “is this a 6 or a 7 in exploitability?” forces the team to articulate the threat clearly.
2. The threshold is editorial: typically, score ≥ 7 is “fix now”; 4–6 is “fix within the next quarter”; < 4 is “track but don’t address”.

DREAD has been criticised as subjective and is sometimes replaced by CVSS (the industry-standard vulnerability scoring system) — but its strength is its simplicity in a design-review conversation. Both work; the discipline is consistency.

Step 4: Attack Trees — Reasoning Like the Adversary

STRIDE finds the threats the system exposes. Attack trees find the threats the adversary will pursue. The shape is a tree rooted in an attacker goal, with each child node a sub-goal the attacker must achieve, with cost estimates per node.

Goal: Steal customer PII
 ├── Compromise DB (cost: $50k of staff time)
 │    ├── SQL injection (cost: 2 weeks of recon)
 │    └── Phish DBA (cost: 1 spear-phish + 0-day)
 ├── Compromise backup (cost: rare but high value)
 │    ├── Insider with backup access (cost: recruitment budget)
 │    └── Public bucket misconfigured (cost: free scan)
 └── Bypass access control at API gateway (cost: 1 week code review)
      └── Find an IDOR (cost: 1 day of fuzzing)

The cheapest path to the root is the path the rational adversary takes. Mitigation that raises the cost of that path (e.g., adding KYC on database admin accounts raises the phishing recruitment cost) is the highest-leverage work.

A mature threat model uses both — STRIDE for completeness, attack trees for prioritisation.

Practice Trajectory

1. Draw a one-page data-flow diagram for a service you operate. Mark every trust boundary. Apply STRIDE on every process; enumerate ~10 threats.
2. Rank the top threats by DREAD. Pick the top two and write a one-sentence mitigation for each.
3. Pick one critical asset in your system. Build an attack tree rooted in “compromise the asset”; give each branch a rough cost estimate. Identify the cheapest path and the mitigation that doubles its cost.
4. Audit a recent security incident against the original threat model: was it a STRIDE miss, an attacker-strategy miss, or a mitigation gap?
5. Schedule a recurring threat-model review tied to design-milestone check-offs. Make it 30 minutes, every meaningful change.

When It’s the Right Tool