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.
Engineering 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.