Overview
Based on Threat Modeling: Designing for Security (Adam Shostack). Threat modeling is structured adversarial thinking applied before code ships. Shostack's standard: the goal is not to find every bug - it's to find the worst things that can happen to your system and decide what to do about each one. A threat model is not a security audit; it is a design artifact.
STRIDE framework (Shostack):
- Spoofing - impersonating a user or system
- Tampering - modifying data or code
- Repudiation - denying an action occurred
- Information disclosure - exposing data to unauthorized parties
- Denial of service - degrading or blocking availability
- Elevation of privilege - gaining access beyond what's authorized
Workflow
Step 1: Define scope
System: [name of the system or feature being modeled]
Scope: [what is in scope - specific components, APIs, data flows]
Out of scope: [what is explicitly excluded]
Assumptions: [what we assume is already secured, e.g. OS-level security, network perimeter]
Assets: [what we're protecting]
- [asset 1, e.g. user PII]
- [asset 2, e.g. payment data]
- [asset 3, e.g. service availability]
Step 2: Draw the data flow diagram (DFD)
Describe or draw a simple DFD with:
- External entities (users, third-party systems)
- Processes (services, functions)
- Data stores (databases, caches, queues)
- Data flows (connections between components)
- Trust boundaries (lines where authorization is required)
External entity: [Browser / Mobile client]
→ [API Gateway] (trust boundary crossed - auth required)
→ [Service A] (internal trust)
→ [Database] (internal trust)
→ [External Payment API] (trust boundary - third party)
Every trust boundary crossing is a threat surface.
Step 3: Apply STRIDE per component
For each component and data flow, enumerate threats systematically:
Component: [API Gateway]
Spoofing:
T1: Attacker sends requests with forged JWT tokens
Mitigation: Validate token signature with public key. Check expiry and issuer claim.
Status: Mitigated
Tampering:
T2: Attacker modifies request body in transit
Mitigation: TLS 1.2+ enforced. Request signing for critical operations.
Status: Mitigated
Repudiation:
T3: Authenticated user denies making a request
Mitigation: Structured access logs with user_id, IP, timestamp, action. Logs are immutable (append-only S3).
Status: Mitigated
Information Disclosure:
T4: Error responses leak internal stack traces or DB queries
Mitigation: Generic error messages in production. Internal details logged server-side only.
Status: Mitigated
Denial of Service:
T5: Request flooding exhausts API capacity
Mitigation: Rate limiting per user_id and IP at gateway. [Rate limits: X req/min]
Status: Partial - no burst protection for authenticated users
Elevation of Privilege:
T6: User A accesses User B's resources via IDOR
Mitigation: Authorization check on every resource endpoint verifies ownership.
Status: Mitigated
Repeat for each component and trust boundary crossing.
Step 4: Rate and prioritize threats
Use DREAD or simplified risk scoring for unmitigated/partial threats:
| Threat ID | Description | Likelihood | Impact | Priority | Owner |
|---|
| T5 | Burst flooding for auth users | Medium | High | P1 | [team] |
| T8 | Secrets in environment logs | Low | Critical | P1 | [team] |
| T12 | Stale session tokens after password reset | Medium | Medium | P2 | [team] |
Likelihood: Low / Medium / High
Impact: Low / Medium / High / Critical
Step 5: Document mitigations and residual risk
For each threat rated P1 or P2:
Threat: [T5 - Burst flooding for authenticated users]
Current state: Rate limit is per-minute but no burst throttle
Proposed mitigation: Token bucket algorithm at gateway, limit 10 concurrent requests per user
Owner: [team]
Target resolution: [sprint or date]
Residual risk if not fixed: Authenticated users can amplify load during peak, causing latency SLA breach
Accepted residual risk: [yes/no and by whom if yes]
Step 6: Out-of-scope and assumptions
Document what is explicitly not covered and why:
Not modeled:
- Physical security of data centers (assumed: cloud provider responsibility)
- Insider threat from admins with DB access (assumed: handled by HR and access review processes)
- DDoS at network layer (assumed: CDN/WAF handles this)
These assumptions should be reviewed annually or when the architecture changes.
Anti-Patterns
1. Threat model as checkbox exercise
Bad: "We did a threat model." (5-bullet doc, never revisited)
Good: Threat model lives with the design doc, is updated when architecture changes, and P1/P2 threats have owners and dates.
2. No trust boundary analysis
Bad: Threat model lists threats but doesn't identify where trust changes hands.
Good: Every external entity, third-party integration, and auth boundary is explicitly called out as a threat surface.
3. Mitigations without validation
Bad: "Mitigation: use TLS." (without verifying it's actually enforced)
Good: "TLS 1.2+ enforced at load balancer. Certificate pinning on mobile clients. Verified via [test or config reference]."
4. STRIDE applied globally instead of per component
Bad: "Spoofing threats: attackers could impersonate users."
Good: STRIDE applied to each component individually so threats are specific and actionable.
Quality Checklist