# Threat modeling Threat modeling walks a system's architecture and enumerates what an attacker could do to it. It records which assets are at risk and which mitigations exist or are missing, and the output is a list of prioritized threats and remediation work. ## What it catches - **Missing authentication and authorization controls.** A service whose threat model lists "internal-only" but whose data flow crosses an untrusted network. - **Tampering and replay risks.** Messages that the design assumes are unmodified but lack signatures or sequence numbers. - **Repudiation gaps.** Actions that should be auditable but leave no trail. - **Information disclosure paths.** Logs, error messages, and cache responses that leak data the system meant to keep private. - **Denial-of-service vectors.** Endpoints whose cost to attack is far below cost to serve. - **Elevation-of-privilege paths.** Trust-boundary crossings where one identity escalates into another's privileges. - **Architectural exposure.** Components the design considered internal that turn out to be reachable from the internet. What threat modeling does **not** catch by itself: implementation bugs (the model assumes the code matches the design), zero-day vulnerabilities in dependencies (the model assumes the dependencies are trusted), and threats the analyst doesn't think of. [Static analysis](https://quality.stereobooster.com/static-analysis.md), [fuzzing](https://quality.stereobooster.com/fuzzing.md), [supply-chain hygiene](https://quality.stereobooster.com/supply-chain-hygiene.md), and [penetration testing](https://quality.stereobooster.com/penetration-testing.md) cover those gaps. ## Frameworks - **[STRIDE](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)** (*Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege*) — Microsoft's per-component enumeration framework. - **PASTA** (*Process for Attack Simulation and Threat Analysis*) — seven-stage business-risk-aligned process; heavier than STRIDE (UcedaVélez and Morana 2015)[^ucedavelez2015]. - **Attack trees** — goal-directed tree of how an attacker could achieve an objective; useful for combining threats rather than enumerating them (Schneier 1999)[^schneier1999]. - **[DREAD](https://owasp.org/www-community/Threat_Modeling_Process)** (*Damage, Reproducibility, Exploitability, Affected users, Discoverability*) — risk scoring, often paired with STRIDE. Microsoft itself deprecated DREAD; community use persists. - **[LINDDUN](https://linddun.org/)** (*Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance*) — privacy-focused variant of STRIDE. - **[MITRE ATT&CK](https://attack.mitre.org/)** — knowledge base of real-world attacker tactics and techniques; useful as a checklist for "what would an actual attacker do?" - **[OWASP Top 10](https://owasp.org/www-project-top-ten/)** — a curated list of the ten most critical web-application security risks, updated periodically by OWASP; useful as a starter checklist for web threat models. ## Tools - **[OWASP Threat Dragon](https://owasp.org/www-project-threat-dragon/)** — open-source threat-modeling editor; draws data-flow diagrams and tags threats inline. - **[Microsoft Threat Modeling Tool](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool)** — Windows-only; STRIDE-driven. - **[pytm](https://github.com/izar/pytm)** (OWASP) — threat models as Python code; useful for CI integration. - **draw.io / Lucidchart / Excalidraw** — generic diagramming for hand-drawn DFDs; the lowest-cost entry point. - **STRIDE-per-element matrices** — a spreadsheet suffices for small systems. ## When to use, when not **Use:** - Any new service crossing a trust boundary. The cheapest model is a one-page DFD plus STRIDE per element. - Significant architecture changes. New region, new identity store, new third-party integration. The change re-opens questions the old model answered. - Security-sensitive features: authentication, authorization, key management, payment, PII handling, audit. - Before penetration testing. The pentester works faster and goes deeper when handed a current threat model. **Don't:** - As a one-time exercise. Threat models decay as architectures change; treat them as documents that ship with the code. - As a substitute for [static analysis](https://quality.stereobooster.com/static-analysis.md), [fuzzing](https://quality.stereobooster.com/fuzzing.md), or [penetration testing](https://quality.stereobooster.com/penetration-testing.md). The model is about design risk; implementation risk needs methods that read or run the code. - Without a remediation budget. A list of threats nobody fixes is worse than no list — it documents the gap. ## Evidence The empirical literature on threat modeling is largely industrial case studies; controlled comparisons of "team with threat model" vs "team without" are rare. Microsoft SDL applied STRIDE to every release, but the volume of post-release security bugs it avoided is not published — feasibility at scale, not a measured effect. The case for the practice therefore rests on its definitional position: a method that tests an implementation takes the design as given; threat modeling examines the design itself for what an attacker could reach. ## Further reading - **Threat modeling, end to end** — STRIDE, DFDs, attack trees, the Microsoft lineage (Shostack 2014)[^shostack2014]. - **A team-scale practical guide** — PASTA and mature integration patterns (Tarandach and Coles 2020)[^tarandach2020]. - **The Threat Modeling Manifesto** — consensus principles from a 15-member practitioner working group, independent of any single vendor or framework (Threat Modeling Manifesto 2020)[^threatmodelingmanifesto2020]. ## Classification - **Quality dimensions:** Security. - **Area:** Security-sensitive design — authentication, authorization, key management, payments, PII handling, audit. ## Referenced by - [Quality dimensions](https://quality.stereobooster.com/quality-dimensions.md) · Quality dimensions - [Agent security testing](https://quality.stereobooster.com/agent-security-testing.md) · Methods - [Checklists](https://quality.stereobooster.com/checklists.md) · Methods - [Example tests](https://quality.stereobooster.com/example-tests.md) · Methods - [Penetration testing](https://quality.stereobooster.com/penetration-testing.md) · Methods - [Safety analysis](https://quality.stereobooster.com/safety-analysis.md) · Methods - [Supply-chain hygiene](https://quality.stereobooster.com/supply-chain-hygiene.md) · Methods - [How AI fits into software quality](https://quality.stereobooster.com/ai.md) · AI ## References [^ucedavelez2015]: UcedaVélez, Tony, and Marco M. Morana. 2015. *Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis*. Wiley. [^schneier1999]: Schneier, Bruce. 1999. *[Attack Trees](https://www.schneier.com/academic/archives/1999/12/attack_trees.html)*. Dr. Dobb's Journal. [https://www.schneier.com/academic/archives/1999/12/attack\\\_trees.html](https://www.schneier.com/academic/archives/1999/12/attack\_trees.html). [^shostack2014]: Shostack, Adam. 2014. *Threat Modeling: Designing for Security*. Wiley. [^tarandach2020]: Tarandach, Izar, and Matthew J. Coles. 2020. *Threat Modeling: A Practical Guide for Development Teams*. O'Reilly. [^threatmodelingmanifesto2020]: Threat Modeling Manifesto. 2020. *[The Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)*. . ## Acronyms - DFD — data-flow diagram - DREAD — Damage, Reproducibility, Exploitability, Affected users, Discoverability - LINDDUN — Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance - PASTA — Process for Attack Simulation and Threat Analysis - PII — personally identifiable information - SDL — Security Development Lifecycle (Microsoft) - STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege