Threat Modeling
Published on
A threat model is a shared explanation of how a system can be misused or compromised and what the design does about it. It should change architecture and tests, not end as a diagram stored for an audit.
Work through the model
- Define the system, critical user journeys, sensitive assets, and unacceptable outcomes.
- Draw processes, data stores, external entities, data flows, administrative paths, and trust boundaries.
- Identify actors and threats. STRIDE can prompt questions about spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
- Connect each material threat to prevention, detection, response, and recovery.
- Record assumptions, residual risk, an accountable owner, and a review trigger.
Questions that expose design risk
- Which identity can cross each boundary, and where is authorization evaluated?
- Can untrusted input reach an interpreter, query, template, deserializer, or command?
- Which control planes can modify production, credentials, policy, or evidence?
- What happens when a dependency lies, times out, becomes compromised, or returns stale data?
- Can an attacker make the system fail open, exhaust a shared resource, or erase audit history?
- How are tenants separated, and which shared components create correlated risk?
Risk scoring can help prioritize, but a numeric score does not replace a clear scenario and impact statement. Revisit the model when data use, trust boundaries, dependencies, deployment authority, or recovery design changes.
The OWASP Threat Modeling Cheat Sheet provides a practical reference.
Last updated on