Threat Modeling with Data-Flow Diagrams and STRIDE

TL;DR: A threat model answers four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? Answer the first with a data-flow diagram that marks every trust boundary. Answer the second by walking each element and each boundary-crossing flow through STRIDE. Answer the third with a decision per threat, not a generic control list. The deliverable is a short, specific list that engineers can act on and reviewers can check.

The four questions

Adam Shostack's four-question framework, now the common structure for threat modeling, keeps the exercise honest:

1. What are we working on? A model of the system, usually a data-flow diagram.
2. What can go wrong? Threats, found systematically rather than by inspiration.
3. What are we going to do about it? A decision for each threat.
4. Did we do a good enough job? A check that the model matched reality and the mitigations shipped. (The Threat Modeling Manifesto's wording says "good enough" on purpose: a model is never complete, only sufficient for the decision at hand.)

Teams that skip the first question produce threat lists that could apply to any system. Teams that skip the fourth produce documents nobody reads after the design review.

Drawing the data-flow diagram

A data-flow diagram uses five elements, and the vocabulary matters because STRIDE is applied per element:

Keep the diagram at the level where trust changes. A diagram with forty boxes hides the three boundaries that matter; a diagram with three boxes and no boundaries tells you nothing. The trust boundaries lesson is the prerequisite here: every flow that crosses a boundary is where you will spend most of your time.

STRIDE: six questions for every element

STRIDE was introduced at Microsoft by Loren Kohnfelder and Praerit Garg in 1999. Each letter is a threat category, and each category is the violation of a property from the security properties lesson:

Not every category applies to every element. External entities are mainly spoofed; data stores are tampered with, disclosed and exhausted; processes are vulnerable to all six. This mapping is called STRIDE-per-element, and it keeps the walk-through fast. The table in the 2006 Microsoft article that published it is exact:

Many teams also check repudiation for a data store that holds audit logs, because tampering with the log is how repudiation is achieved.

Worked example: how much work STRIDE-per-element creates

A diagram with 2 interactors, 3 processes, 2 data stores and 6 data flows produces:

46 checks is manageable but not free. If only 3 of the 6 flows cross a trust boundary, starting with those 3 flows (9 checks) and the 2 processes at their ends (12 checks) covers the 21 highest-exposure checks first. The same article put it as effort reflecting exposure: spend it where data crosses boundaries.

Threat trees give the leading questions. Howard and Lipner's The Security Development Lifecycle (2006) included a threat tree per element type, whose leaves are concrete questions. One of them, whether a data flow is defended against replay, is the example the 2006 article uses: asking it surfaced a replay threat the team's brainstorm had missed. The fix in such cases is concrete: a per-request identifier the server refuses to accept twice, tested by submitting the same request twice and expecting a rejection.

STRIDE-per-interaction is the other common variant. Instead of single elements, it walks each (source, destination, flow) tuple that crosses a boundary and asks what each end assumes about the other. It finds composition threats, where two components that are each safe combine badly, which per-element analysis misses.

What a good threat model produces

The output is a list, and its quality is judged by specificity. Compare:

• Weak: "Attackers might access data. Mitigation: use encryption and access control."
• Strong: "A signed-in user can request /files/{id} for another user's file because the API checks authentication, not ownership. Mitigation: the API loads the file's owner and compares it with the session user before returning it. Owner: storage team. Test: an automated case that requests another user's file and expects 403."

Each threat gets one of four decisions: mitigate it, accept it with a named owner and a reason, transfer it (insurance, a contract, a vendor's responsibility), or eliminate the feature that creates it. A threat with no decision is not finished.

The tools around the method

• The Elevation of Privilege card game, created by Adam Shostack at Microsoft in 2010 and released under a Creative Commons licence, deals STRIDE threats as cards so a team discusses one concrete threat at a time. It works well for teams new to threat modelling.
• The Microsoft Threat Modeling Tool generates STRIDE threats from a diagram and remains part of Microsoft's Security Development Lifecycle, whose practices include "perform security design review and threat modeling".
• The Threat Modeling Manifesto (November 2020), written by a working group of practitioners, sets out five values: a culture of finding and fixing design issues over checkbox compliance; people and collaboration over processes and tools; building understanding over time rather than taking a snapshot; doing threat modelling over talking about it; and continuous refinement over a single delivery.

When to do it

Threat model when a design is still cheap to change: at design review, before a new trust boundary is introduced, and whenever an existing boundary changes. Adding a model provider, giving an agent a new tool or opening an API to partners each changes the diagram. The Threat Modeling Manifesto (2020) values "continuous refinement over a single delivery", which in practice means a short model kept current beats a long one written once.

Misconceptions interviewers listen for

• "Apply all six letters to every box." The per-element table exists to stop that.
• "STRIDE is a complete list of threats." It is a prompt for finding them; composition and privacy threats need other passes.
• "The threat model is a document we finish." It is kept current as boundaries change.
• "A list of controls is a threat model." Without threats, decisions, owners and tests, it is a wish list.
• "Repudiation applies to data flows." In the standard table it applies to interactors and processes, plus stores holding audit logs.

How this shows up in interviews

Expect "walk me through how you'd threat-model X" in almost every security loop, and expect the interviewer to care more about your process than your list. Start by asking what the system does and who uses it, sketch the diagram aloud, name the boundaries, then take one boundary through STRIDE in detail rather than skimming all six letters for every box. Finish with decisions and owners. Candidates who recite STRIDE without a diagram score as having memorised an acronym.

Say it in 30 seconds: "I draw a data-flow diagram with external entities, processes, stores, flows and trust boundaries, then walk each element, starting with the flows that cross boundaries, through STRIDE: spoofing, tampering, repudiation, disclosure, denial of service and elevation of privilege. Each threat gets a specific mitigation with an owner and a test, or an explicit acceptance. I redo it whenever a boundary changes, like adding a model provider or giving an agent a new tool."