Threat Modeling Cheat Sheet
Covers structured threat modeling methodologies like STRIDE and DREAD, data flow diagrams, and practical steps for identifying design-level risks.
STRIDE Threat Categories
Microsoft's STRIDE model for classifying threats by violated security property.
- Spoofing- Impersonating another user, process, or system (violates authentication)
- Tampering- Unauthorized modification of data or code (violates integrity)
- Repudiation- Denying an action was performed, without traceability (violates non-repudiation)
- Information disclosure- Exposing information to unauthorized parties (violates confidentiality)
- Denial of service- Degrading or denying service availability to legitimate users
- Elevation of privilege- Gaining capabilities beyond what was authorized (violates authorization)
Threat Modeling Process (4 Questions)
The standard four-question framework for a threat modeling session.
- 1. What are we building?- Create a data flow diagram showing components, data stores, and trust boundaries
- 2. What can go wrong?- Enumerate threats per component/flow using STRIDE or attack trees
- 3. What are we going to do about it?- Decide to mitigate, accept, transfer, or eliminate each identified risk
- 4. Did we do a good job?- Validate the model and mitigations, and repeat as the system evolves
Data Flow Diagram (Mermaid)
A simple DFD showing a trust boundary between the internet and internal network.
flowchart LR User((User)) -->|HTTPS request| WebApp[Web Application] subgraph Trust Boundary: DMZ WebApp -->|SQL query| DB[(Database)] end WebApp -->|API call| Auth[Auth Service] Auth -->|token| WebApp %% Trust boundary crosses between User and WebApp (untrusted -> trusted)
DREAD Risk Scoring
A model for scoring severity of identified threats (each factor 1-10, summed or averaged).
- Damage- How severe would the impact be if the threat were exploited?
- Reproducibility- How easily can the attack be reproduced reliably?
- Exploitability- How much skill or resources are needed to exploit it?
- Affected users- How many users or systems would be impacted?
- Discoverability- How easy is it for an attacker to find the vulnerability?
Simple Attack Tree
Text representation of an attack tree for account takeover.
goal: "Compromise user account"children: - "Phish credentials" - "Credential stuffing (reused passwords)" - "Exploit password reset flow" children: - "Guess security question" - "Intercept reset email (no TLS/DNS hijack)" - "Session hijacking via XSS"
Alternative Threat Modeling Methodologies
Frameworks used beyond STRIDE for different scopes and audiences.
- PASTA- Process for Attack Simulation and Threat Analysis; 7-stage risk-centric methodology that ties threats to business impact
- LINDDUN- Privacy-focused model: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance
- VAST- Visual, Agile, and Simple Threat modeling; designed to scale across many teams via automated, application/operational threat models
- Trike- Risk-based model that generates threats from a requirements model using actor-asset-action matrices
- OCTAVE- Operationally Critical Threat, Asset, and Vulnerability Evaluation; organization-wide risk assessment rather than single-system focus
Threat Model as Code (pytm)
Defining a system's boundaries, elements, and data flows in Python so threats can be generated automatically in CI.
from pytm import TM, Server, Datastore, Dataflow, Boundary, Actortm = TM("Checkout Service")tm.description = "Threat model for the checkout microservice"internet = Boundary("Internet")internal = Boundary("Internal Network")user = Actor("Customer")user.inBoundary = internetweb = Server("Web App")web.inBoundary = internalweb.isEncrypted = Truedb = Datastore("Orders DB")db.inBoundary = internaldb.isEncrypted = Truedb.storesPII = Truerequest = Dataflow(user, web, "HTTPS checkout request")request.protocol = "HTTPS"request.dstPort = 443query = Dataflow(web, db, "Write order record")query.protocol = "TLS"tm.process() # generates a report with applicable STRIDE threats per element
STRIDE-per-Element Mapping
Which STRIDE categories typically apply to each type of DFD element — narrows the threat enumeration workload.
- External entity- Spoofing, Repudiation (entities outside your trust boundary can be impersonated or deny actions)
- Process- Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege (all six apply)
- Data store- Tampering, Information disclosure, Denial of service, and Repudiation if the store lacks access logging
- Data flow- Tampering, Information disclosure, Denial of service (interception or modification in transit)
Advanced Attack Tree Notation
Refinements beyond a flat list, used when quantifying attacker effort and combining sub-goals.
- AND node- All child conditions must be satisfied together for the parent goal to succeed (e.g., steal key AND bypass MFA)
- OR node- Any single child path is sufficient to reach the parent goal
- Cost annotation- Estimated attacker effort/resources per leaf node, used to rank realistic paths over theoretical ones
- Probability annotation- Likelihood of success per leaf, propagated up the tree to prioritize mitigations
- Countermeasure node- Attached to a leaf to show which control neutralizes that specific path, making coverage gaps visible
Run threat modeling at design time, before code is written — retrofitting it after implementation turns every finding into an expensive architecture change instead of a cheap diagram edit.