Most security tactics are controls: least privilege, encryption, input sanitization. Threat modeling answers the prior question: which controls does this system need, at which boundary, against which attacks?

Its durable output is not the workshop diagram but the trace from every ranked threat to an owned disposition and its evidence.

A data-flow model of a browser calling a payment API across an internet trust boundary, feeding a threat-modeling loop: enumerate threats with STRIDE per element or attack trees per attacker goal, rank by risk, choose dispositions, and trace each to its evidence. Design changes flow back into the model.

How It Works

  • Model the system as data flows between actors, processes, and stores; mark every trust boundary where privilege or trustworthiness changes.
  • Enumerate threats per element and interaction with STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — and decompose high-value attacker goals with attack trees.
  • Rank threats by impact and exploitability; give each a disposition: mitigate, remove the flow, transfer, or accept.
  • Record threats, assumptions, and decisions under version control; re-model when assets, actors, privileges, dependencies, exposure, or boundaries change.

Failure Modes

  • The model describes last year’s architecture: new services and flows stay unexamined.
  • Taxonomy-driven sessions find what the taxonomy names; fraud through legitimate features passes every STRIDE category.
  • A listed threat counts as handled: the register grows while mitigations stay unbuilt and untested.
  • One wrong assumption, such as a trusted internal network, silently deflates an entire threat class.

Verification

  • Coverage: a diff between modeled entry points and the deployed system’s routes and listeners yields zero unmodeled endpoints.
  • Traceability: 100% of ranked threats have an owner, disposition, rationale, and review trigger; every mitigation links to an implemented control and security test.
  • Freshness: the model’s last revision postdates the last architecture-changing merge, checked at each release gate.
  • Feedback: every penetration-test finding is classified as modeled or missed; each miss opens a re-modeling task.
  • Attack trees follow one attacker goal in depth; abuse cases capture business-logic misuse that STRIDE-style taxonomies skip.
  • Privacy threat modeling (LINDDUN) targets harms such as linkability and unawareness that occur even when access is authorized.
  • Penetration testing observes a running implementation; threat modeling examines the design first. Zero-trust architecture is one possible response, not the analysis.

Mini Example

One row of a threat register, traced end to end:

Boundary:  internet → payment API (browser checkout)
Threat:    tampering — client manipulates the price field in the order payload
Rank:      high (direct financial impact, trivial to attempt)
Decision:  mitigate — server recomputes the price; the client value is display-only
Test:      integration test posts a manipulated price, expects rejection + alert

References