Threat Modeling

Threat modeling is a design-time review that hunts security flaws in a system’s architecture before code hardens around them. Hernan, Lambert, Ostwald, and Shostack gave the working description in MSDN Magazine (November 2006): decompose the system with a data flow diagram (DFD), enumerate threats against each element with STRIDE, mitigate them, and repeat until the residual threats are tolerable. The method became a required design activity in Microsoft’s Security Development Lifecycle, and the article’s own claim is modest — the exercise rarely proves a design secure, but it reliably turns up design issues that would otherwise surface much later. ¹

Diagrams: data flows and trust boundaries

A threat-model DFD uses four standard symbols plus one addition: data flows (arrows), data stores (parallel lines), processes (circles), interactors (rectangles for endpoints outside the system’s scope), and trust boundaries (dotted lines). Trust boundaries carry the analysis — they mark where trust changes, and the far side is by definition not trusted. The article’s sanity rules for a DFD: no data store without a represented reader and writer, no data movement without a process moving it, similar elements inside one trust boundary collapsed into one element, and one side of a trust boundary modeled at a time (context diagram plus breakouts). A component can also be drawn as external on one side of the boundary while its internals get their own diagram. ²

STRIDE

STRIDE names six threat categories and maps each to the security property it breaks:

Threat	Property broken
Spoofing	Authentication
Tampering	Integrity
Repudiation	Non-repudiation
Information disclosure	Confidentiality
Denial of service	Availability
Elevation of privilege	Authorization

Each DFD element type carries a different subset of the six: processes face all six, data flows and data stores face tampering, information disclosure, and denial of service, interactors face spoofing and repudiation. Walking the diagram element by element against the applicable categories is the enumeration step, and the mapping also tells you which mitigation class applies — authentication answers spoofing, integrity mechanisms answer tampering, and so on. ³

Two honesty notes from the sources. First, per-element immunity does not compose: the article concedes that combining individually modeled subsystems regularly produces new threats at the seams, because composition violates assumptions each subsystem made. Second, STRIDE’s categories cross-correlate — LeBlanc pointed out that elevation of privilege tends to imply spoofing and loss of non-repudiation, and can drag in the rest — so the taxonomy guides discussion rather than partitioning the threat space cleanly. ⁴

Finding manifestations: threat trees and attack patterns

Enumerating categories finds threat types; finding actual attacks needs technology knowledge. The article’s two aids: prebuilt threat trees whose leaf nodes are leading questions (e.g. “is the data flow protected against replay with timestamps or counters?” — a question that exposes a replay attack a brainstorm skips), and attack patterns, the technology-specific ways a threat gets realized (a strcpy overflow as an elevation-of-privilege path). Maintained threat trees act as institutional memory as new attacks are added. ⁵

Prioritizing findings: DREAD and its discontents

DREAD scores threats on five factors — Damage, Reliability, Exploitability, Affected users, Discoverability — and the original Writing Secure Code recipe averaged the five 1–10 ratings. LeBlanc, a co-author of that recipe, later documented why the averaging fails: a damage-1 nuisance with everything else at 10 and a discoverability-1 catastrophe with everything else at 10 land on the same score, and nobody can meaningfully distinguish a 6 from a 7 on any factor anyway. His replacement drops to three levels per factor, splits the five into two groups (severity from Damage, Reliability, Affected users; priority boosts from Exploitability and Discoverability), and maps the result to nine fix-by buckets — “won’t fix” through “high priority bulletin”. His caveats travel with the scheme: it was not Microsoft’s internal standard (“This is NOT how MSRC does things”), and no scoring system should be applied without thinking about the specific case. ⁶

The averaging failure here is the same ordinal-scoring pathology that risk-matrices documents at larger scale, and DREAD’s descendants largely lost the triage role to calculate-cvss-scores.

Related

• iec-62443 — zone-and-conduit security risk assessment (part 3-2) puts threat analysis at the center of IACS design
• risk-matrices — the prioritization-scoring problems LeBlanc flags, in grid form
• calculate-cvss-scores — the scoring scheme that took over vulnerability triage
• moscow-rules — threat-modeling-adjacent OPSEC judgment for physical work

Sources

• Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack 2006 — Uncover Security Design Flaws Using The STRIDE Approach
• David LeBlanc 2007 — DREADful

Footnotes

1. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack 2006 — Uncover Security Design Flaws Using The STRIDE Approach ↩

2. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack 2006 — Uncover Security Design Flaws Using The STRIDE Approach ↩

3. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack 2006 — Uncover Security Design Flaws Using The STRIDE Approach ↩

4. David LeBlanc 2007 — DREADful ↩

5. Shawn Hernan, Scott Lambert, Tomasz Ostwald, Adam Shostack 2006 — Uncover Security Design Flaws Using The STRIDE Approach ↩

6. David LeBlanc 2007 — DREADful ↩