STRIDE Threat Modeling Framework

STRIDE is a mnemonic for six threat categories, each violating a security property: spoofing violates authentication, tampering violates integrity, repudiation violates non-repudiation, information disclosure violates confidentiality, denial of service violates availability, and elevation of privilege violates authorization. Applied to a data flow diagram, it turns a vague question ("is this secure?") into a finite checklist.

Run sessions with a mix of developers, a tester, and someone who understands operations. Diverse perspectives surface assumptions, such as which service accounts are shared or which queues accept unauthenticated messages, that a single reviewer would not question.

How it works

Start with a diagram of external entities, processes, data stores, and data flows, then draw trust boundaries where privilege or ownership changes. Each element type is susceptible to specific categories: external entities to spoofing and repudiation, processes to all six, data stores to tampering, disclosure, and denial of service, and data flows to tampering, disclosure, and denial of service. Walk each element and ask how an attacker could cause each applicable threat.

Implementation steps

1. Scope the model to one feature or service, and gather the people who built it.
2. Build the diagram on a whiteboard, then store it as code or an exported image next to the repository.
3. Enumerate threats per element and boundary crossing, writing each as a sentence: who, what, impact.
4. Rate each threat with a consistent scale such as likelihood times impact.
5. Assign mitigations (for example mutual TLS for spoofing, signed payloads for tampering, audit logging for repudiation).
6. Create tracked tickets and link them to the model document.
7. Revisit the model during design review of any change that adds a boundary.

Common pitfalls

• Modeling at too high a level, so every threat reads "attacker compromises the server".
• Skipping data flows between internal services because they are "trusted".
• Treating the output as a one-time deliverable rather than a living document.
• Listing threats without owners or deadlines.

Metrics to watch

Track the percentage of new services with a current model, the number of threats open by severity, the mean time to close a high-severity mitigation, and the proportion of production security issues that the model had already predicted.

Review the numbers monthly with engineering leadership, and compare modeled threats against penetration test and bug bounty findings. Every finding that was not in the model is evidence of a gap in the diagram or in the team's technique.

Example threat register

element: payments-api -> orders-db
boundary: service-to-datastore
threats:
  - id: T-014
    category: Tampering
    description: Compromised service account alters order totals
    likelihood: medium
    impact: high
    mitigation: Row-level audit triggers and least-privilege DB role
    owner: payments-team
    status: in-progress
  - id: T-015
    category: Repudiation
    description: Refund issued with no actor recorded
    mitigation: Immutable audit log with caller identity
    status: open

Key takeaways

• Model the design, not the code, and keep the diagram honest.
• Apply all six categories to every boundary crossing.
• Every threat needs a rating, an owner, and a tracked mitigation.
• Update the model when trust boundaries change, not on a calendar alone.