Skip to content

Software Quality

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, fuzzing, supply-chain hygiene, and penetration testing cover those gaps.

Frameworks

  • STRIDE (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)1.
  • Attack trees — goal-directed tree of how an attacker could achieve an objective; useful for combining threats rather than enumerating them (Schneier 1999)2.
  • DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) — risk scoring, often paired with STRIDE. Microsoft itself deprecated DREAD; community use persists.
  • LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance) — privacy-focused variant of STRIDE.
  • MITRE ATT&CK — knowledge base of real-world attacker tactics and techniques; useful as a checklist for "what would an actual attacker do?"
  • OWASP Top 10 — 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 — open-source threat-modeling editor; draws data-flow diagrams and tags threats inline.
  • Microsoft Threat Modeling Tool — Windows-only; STRIDE-driven.
  • 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, fuzzing, or penetration testing. 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)3.
  • A team-scale practical guide — PASTA and mature integration patterns (Tarandach and Coles 2020)4.
  • The Threat Modeling Manifesto — consensus principles from a 15-member practitioner working group, independent of any single vendor or framework (Threat Modeling Manifesto 2020)5.

Classification

  • Quality dimensions: Security.
  • Area: Security-sensitive design — authentication, authorization, key management, payments, PII handling, audit.

Referenced by

References

  1. UcedaVélez, Tony, and Marco M. Morana. 2015. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Wiley. ↩

  2. Schneier, Bruce. 1999. Attack Trees. Dr. Dobb's Journal. https://www.schneier.com/academic/archives/1999/12/attack_trees.html. ↩

  3. Shostack, Adam. 2014. Threat Modeling: Designing for Security. Wiley. ↩

  4. Tarandach, Izar, and Matthew J. Coles. 2020. Threat Modeling: A Practical Guide for Development Teams. O'Reilly. ↩

  5. Threat Modeling Manifesto. 2020. The Threat Modeling Manifesto. https://www.threatmodelingmanifesto.org/. ↩