Architecture/Fundamentals/threat-modeling-stride

Threat Modeling with STRIDE

Concept

STRIDE is a threat-modeling methodology developed at Microsoft (Loren Kohnfelder and Praerit Garg, 1999) that classifies threats into six categories, each mapped to the security property it violates:

Threat	Violates
Spoofing	Authentication
Tampering	Integrity
Repudiation	Non-repudiation
Information Disclosure	Confidentiality
Denial of Service	Availability
Elevation of Privilege	Authorization

The process is architecture-first, not code-first: draw a data-flow diagram (DFD) of the system showing processes, data stores, external entities, and — critically — trust boundaries (points where data crosses from a less-trusted zone into a more-trusted one, e.g. public internet into an internal API, or a low-privilege service into an admin plane). Then walk every element that touches a trust boundary against all six STRIDE categories and ask "could this threat happen here, and what mitigates it if so."

Tradeoffs

Approach	Depth	Speed	Best fit
STRIDE (per-element checklist)	Broad category coverage, shallow on likelihood/impact	Fast — a structured checklist against a DFD	Design-time review of a new system or a new trust boundary
Attack trees	Deep on a specific goal ("compromise the payment flow")	Slower, narrower scope per tree	High-value single targets once STRIDE has flagged them
PASTA (Process for Attack Simulation and Threat Analysis)	Deep, business-risk-weighted	Slow — multi-stage, requires business-impact input	Regulated/high-stakes systems needing risk-quantified output

STRIDE trades depth for coverage and speed: it's a checklist that reliably surfaces categories of threat at every trust boundary, but it doesn't rank them by likelihood or business impact on its own — that ranking is a separate step (often DREAD or a simple risk matrix) layered on top of whatever STRIDE finds.

When to use / when not to

Use at design time for any new system, and again whenever a trust boundary changes — a new third-party integration, a new admin-only endpoint, a new data flow that starts crossing from public to internal.
Especially valuable in an architecture review setting, since walking a DFD against six fixed categories gives reviewers a shared, repeatable vocabulary instead of an unstructured "what could go wrong" discussion that depends entirely on who's in the room.
Overkill for trivial internal tooling with no external trust boundary and no sensitive data — the ceremony of a full DFD-plus-STRIDE pass costs more than the risk it would surface.
Not a substitute for runtime security testing (fuzzing, penetration testing) — STRIDE finds design-level gaps; it won't catch an implementation bug in otherwise-sound architecture.

Common pitfall

Running STRIDE once at initial design and never again. Threat models rot exactly like architecture diagrams do: a new third-party webhook, a new internal admin backdoor added under deadline pressure, or a quietly expanded IAM role all introduce new trust-boundary crossings that nobody re-evaluates. The system's actual attack surface drifts away from the one-time diagram, and the next real incident lands squarely in the gap nobody re-checked.

Principal Engineer Lens

STRIDE's real value at Principal scope isn't the checklist itself — it's the shared vocabulary it gives an architecture review. Being able to point at a specific trust boundary on a diagram and say "here's the tampering risk on this data flow, here's why we're relying on message signing rather than transport encryption alone" is a fundamentally stronger signal than a general claim to having "considered security." It also scales the security conversation beyond a dedicated security team — any engineer walking a DFD against six fixed categories can surface real gaps without needing a security specialist in the room for every design review.

Reel Script

Setup: Ask: when someone says a design has "been through security review," what did that actually mean — a vague gut check, or something with an actual repeatable method behind it?

Concept walkthrough: Introduce the six STRIDE categories and what each one violates — Spoofing breaks authentication, Tampering breaks integrity, Repudiation breaks accountability, Information Disclosure breaks confidentiality, Denial of Service breaks availability, Elevation of Privilege breaks authorization. Explain the mechanic: draw the data-flow diagram, mark the trust boundaries, and walk every boundary-crossing element against all six.

Real example tie-in: Walk a concrete trust boundary: a public API gateway sitting in front of an internal payments service. Show how each STRIDE category maps to a real question there — can a caller spoof another user's identity at that boundary? Can a request be tampered with in transit? Is every state-changing call logged in a way that prevents repudiation later?

Tradeoffs & alternatives: Contrast STRIDE's speed and breadth against attack trees (deep on one specific goal) and PASTA (business-risk-weighted, much slower). Name that STRIDE surfaces categories of threat, not a prioritized list — that ranking is a separate step.

Principal Engineer takeaway: The strong review answer isn't "we did a security pass" — it's naming the specific trust boundary, which STRIDE category applied, and what concretely mitigates it. That's what turns "we thought about security" into something a reviewer can actually verify.

Sources: