Threat Modeling
Identify and mitigate security threats during system design.
When to Use This Skill
Use this skill when:
- Designing a new system, service, or feature
- Making significant architectural changes to existing systems
- Onboarding a new third-party integration or dependency
- Preparing for security audits or compliance reviews
- Responding to a security incident to improve defenses
- Reviewing infrastructure changes that affect trust boundaries
Prerequisites
- System architecture documentation or design diagrams
- Access to development and operations teams for context
- Understanding of the system's data classification (PII, PHI, financial, etc.)
- OWASP Threat Dragon or Microsoft Threat Modeling Tool (optional but helpful)
- Whiteboard or diagramming tool for collaborative sessions
STRIDE Methodology
| Threat | Description | Property Violated | Mitigation Examples |
|---|
| Spoofing | Pretending to be another user or system | Authentication | MFA, mTLS, API key validation, certificate pinning |
| Tampering | Modifying data in transit or at rest | Integrity | HMAC, digital signatures, checksums, immutable logs |
| Repudiation | Denying having performed an action | Non-repudiation | Audit logging, digital signatures, tamper-evident logs |
| Information Disclosure | Exposing data to unauthorized parties | Confidentiality | Encryption (TLS, AES), access controls, data masking |
| Denial of Service | Making service unavailable | Availability | Rate limiting, autoscaling, CDN, circuit breakers |
| Elevation of Privilege | Gaining unauthorized higher access | Authorization | RBAC, principle of least privilege, input validation |
STRIDE Worksheet Template
# stride-worksheet.yaml - Fill out one per component/trust boundary crossing
component:
name: "API Gateway"
owner: "Platform Team"
data_classification: "Confidential"
trust_boundary: "External -> Internal"
threats:
- id: T001
category: Spoofing
description: "Attacker forges JWT tokens to impersonate users"
attack_vector: "Stolen signing key or weak algorithm (HS256 with guessable secret)"
likelihood: Medium
impact: Critical
risk_score: 15 # likelihood(3) x impact(5)
existing_controls:
- "JWT validation on every request"
- "RS256 algorithm with rotated keys"
gaps:
- "No token binding to device/IP"
recommended_mitigations:
- "Add token binding claims"
- "Implement short-lived tokens (15 min) with refresh"
- "Monitor for token reuse from different IPs"
status: "Mitigated (partial)"
owner: "Auth Team"
- id: T002
category: Tampering
description: "Man-in-the-middle modifies API requests"
attack_vector: "Compromised network between client and gateway"
likelihood: Low
impact: High
risk_score: 8
existing_controls:
- "TLS 1.3 enforced"
- "HSTS enabled"
gaps: []
recommended_mitigations:
- "Certificate pinning for mobile clients"
status: "Mitigated"
owner: "Platform Team"
- id: T003
category: Information Disclosure
description: "Verbose error messages leak internal details"
attack_vector: "Triggering errors returns stack traces, internal IPs, DB schema"
likelihood: High
impact: Medium
risk_score: 12
existing_controls:
- "Generic error pages in production"
gaps:
- "Some microservices return raw exceptions"
recommended_mitigations:
- "Centralized error handling middleware"
- "Error response schema validation"
status: "Open"
owner: "Backend Team"
- id: T004
category: Denial of Service
description: "API rate limiting bypass through distributed requests"
attack_vector: "Botnet sending requests below per-IP threshold"
likelihood: Medium
impact: High
risk_score: 12
existing_controls:
- "Per-IP rate limiting at WAF"
gaps:
- "No aggregate rate limiting"
- "No bot detection"
recommended_mitigations:
- "Add aggregate rate limiting per endpoint"
- "Deploy bot detection (Cloudflare Bot Management)"
- "Implement circuit breaker pattern"
status: "Open"
owner: "Platform Team"
- id: T005
category: Elevation of Privilege
description: "IDOR allows accessing other users' data"
attack_vector: "Manipulating resource IDs in API calls"
likelihood: Medium
impact: Critical
risk_score: 15
existing_controls:
- "Authentication required"
gaps:
- "Authorization checks inconsistent across endpoints"
recommended_mitigations:
- "Enforce ownership checks on all resource access"
- "Use opaque IDs instead of sequential integers"
- "Add authorization integration tests"
status: "Open"
owner: "Backend Team"
Data Flow Diagram
Text-Based DFD Notation
Trust Boundary: Internet
==========================
|
[External User]
|
HTTPS/443
|
==========================
Trust Boundary: DMZ
==========================
|
(WAF / CDN)
|
[API Gateway]---->[Auth Service]--->[Identity DB]
|
==========================
Trust Boundary: Internal
==========================
|
[App Service]
/ \
/ \
[Cache] [Message Queue]
|
[Worker Service]
|
==========================
Trust Boundary: Data
==========================
|
[Primary DB]--->[Replica DB]
|
[Object Store]
Legend:
[Box] = Process
(Parens) = External entity / proxy
==== = Trust boundary
---> = Data flow
Threat Dragon Model (JSON)
{
"summary": {
"title": "E-Commerce Platform",
"owner": "Security Team",
"description": "Threat model for the e-commerce API platform"
},
"detail": {
"diagrams": [
{
"title": "API Data Flow",
"diagramType": "STRIDE",
"cells": [
{
"type": "tm.Actor",
"name": "Web Client",
"threats": []
},
{
"type": "tm.Process",
"name": "API Gateway",
"threats": ["T001", "T002", "T003", "T004"]
},
{
"type": "tm.Process",
"name": "Order Service",
"threats": ["T005"]
},
{
"type": "tm.Store",
"name": "Orders Database",
"threats": ["T006"]
},
{
"type": "tm.Boundary",
"name": "DMZ"
},
{
"type": "tm.Boundary",
"name": "Internal Network"
}
]
}
]
}
}
Threat Library
# threat-library.yaml - Reusable threat patterns
categories:
authentication:
- id: TL-AUTH-001
name: "Credential stuffing"
description: "Attacker uses leaked credential databases to attempt logins"
applicable_to: ["login endpoints", "API authentication"]
mitigations: ["MFA", "rate limiting", "credential breach monitoring", "CAPTCHA"]
- id: TL-AUTH-002
name: "Session hijacking"
description: "Attacker steals session tokens via XSS or network sniffing"
applicable_to: ["web applications", "APIs with session tokens"]
mitigations: ["HttpOnly cookies", "TLS", "session binding", "short TTL"]
- id: TL-AUTH-003
name: "OAuth token theft"
description: "Access tokens stolen from logs, URLs, or insecure storage"
applicable_to: ["OAuth/OIDC integrations"]
mitigations: ["PKCE", "short-lived tokens", "token binding", "secure storage"]
injection:
- id: TL-INJ-001
name: "SQL injection"
description: "Malicious SQL in user input executes unauthorized queries"
applicable_to: ["database-backed endpoints", "search functionality"]
mitigations: ["parameterized queries", "ORM", "input validation", "WAF"]
- id: TL-INJ-002
name: "Command injection"
description: "User input passed to system commands without sanitization"
applicable_to: ["file processing", "system administration features"]
mitigations: ["avoid shell commands", "input allowlisting", "sandboxing"]
- id: TL-INJ-003
name: "SSRF (Server-Side Request Forgery)"
description: "Attacker makes server send requests to internal resources"
applicable_to: ["URL fetching features", "webhook handlers", "PDF generators"]
mitigations: ["URL allowlisting", "network segmentation", "metadata endpoint blocking"]
supply_chain:
- id: TL-SC-001
name: "Dependency confusion"
description: "Malicious package with internal name published to public registry"
applicable_to: ["npm, pip, maven projects using private packages"]
mitigations: ["namespace scoping", "registry prioritization", "SBOM monitoring"]
- id: TL-SC-002
name: "Compromised CI/CD pipeline"
description: "Attacker injects malicious code through build system compromise"
applicable_to: ["all software builds"]
mitigations: ["SLSA compliance", "signed commits", "ephemeral builders", "provenance"]
data:
- id: TL-DATA-001
name: "Unencrypted data at rest"
description: "Sensitive data stored without encryption on disk or in database"
applicable_to: ["databases", "object storage", "backups"]
mitigations: ["AES-256 encryption", "KMS-managed keys", "encrypted volumes"]
- id: TL-DATA-002
name: "PII exposure in logs"
description: "Personal data written to application or infrastructure logs"
applicable_to: ["all services handling PII"]
mitigations: ["log sanitization", "structured logging", "PII detection scanning"]
Risk Scoring Matrix
Likelihood Rating
| Score | Level | Description |
|---|
| 1 | Very Low | Requires nation-state resources; no known exploits |
| 2 | Low | Requires significant expertise and specific conditions |
| 3 | Medium | Moderately skilled attacker with available tools |
| 4 | High | Script-kiddie level; public exploits available |
| 5 | Very High | Trivial to exploit; automated scanning detects it |
Impact Rating
| Score | Level | Description |
|---|
| 1 | Negligible | No data exposure; cosmetic only |
| 2 | Minor | Limited data exposure; single user affected |
| 3 | Moderate | Significant data exposure; service degradation |
| 4 | Major | Large-scale data breach; extended outage |
| 5 | Critical | Complete system compromise; regulatory breach |
Risk Matrix
Impact -> 1 2 3 4 5
Likelihood
5 Medium High High Critical Critical
4 Low Medium High High Critical
3 Low Low Medium High High
2 Info Low Low Medium High
1 Info Info Low Low Medium
Risk Treatment Decisions
risk_treatment:
critical: # Score >= 20
action: "Immediate remediation required"
sla: "24 hours"
approval: "CISO"
high: # Score 12-19
action: "Remediation in current sprint"
sla: "1 week"
approval: "Security Lead"
medium: # Score 6-11
action: "Remediation in next sprint"
sla: "1 month"
approval: "Team Lead"
low: # Score 2-5
action: "Track and address in backlog"
sla: "1 quarter"
approval: "Team Lead"
info: # Score 1
action: "Accept risk and document"
sla: "None"
approval: "Team Lead"
OWASP Threat Dragon Setup
# Run Threat Dragon locally with Docker
docker run -d \
--name threat-dragon \
-p 3000:3000 \
-e ENCRYPTION_KEYS='["threat-dragon-encryption-key-change-me"]' \
-e NODE_ENV=production \
owasp/threat-dragon:v2.2.0
# Access at http://localhost:3000
# Or install as desktop application
# Download from: https://github.com/OWASP/threat-dragon/releases
Integration with CI/CD
# .github/workflows/threat-model-review.yml
name: Threat Model Review
on:
pull_request:
paths:
- 'docs/threat-model/**'
- 'architecture/**'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate threat model files
run: |
for model in docs/threat-model/*.yaml; do
echo "Validating $model..."
python -c "
import yaml, sys
with open('$model') as f:
data = yaml.safe_load(f)
required = ['component', 'threats']
for r in required:
if r not in data:
print(f'ERROR: Missing required field: {r}')
sys.exit(1)
for t in data.get('threats', []):
if t.get('status') == 'Open' and t.get('risk_score', 0) >= 12:
print(f'WARNING: High-risk open threat: {t[\"id\"]} - {t[\"description\"]}')
print(f'OK: {len(data[\"threats\"])} threats documented')
"
done
- name: Check for unaddressed critical threats
run: |
CRITICAL=$(grep -r "risk_score: \(1[5-9]\|2[0-5]\)" docs/threat-model/*.yaml | grep "status: \"Open\"" | wc -l)
if [ "$CRITICAL" -gt 0 ]; then
echo "WARNING: $CRITICAL critical/high-risk threats still open"
echo "Review required before merging architectural changes"
fi
Troubleshooting
| Problem | Cause | Solution |
|---|
| Threat model sessions are unproductive | Participants don't understand the system | Share architecture docs before the session; include a system walkthrough |
| Too many threats identified | Scope too broad | Focus on one component or trust boundary per session |
| Threats are too vague | No structured methodology | Use STRIDE per element; fill in the worksheet template for each |
| Team doesn't follow up on findings | No ownership or tracking | Assign each threat to a team with SLA; track in issue tracker |
| Threat model becomes stale | No trigger to update | Require review on architecture changes (CI/CD gate on diagram changes) |
| Disagreements on risk scores | Subjective scoring | Use the scoring matrix consistently; calibrate with historical incidents |
Best Practices
- Integrate threat modeling into the SDLC at the design phase
- Review threat models when architecture changes occur
- Include developers, ops, and security in sessions
- Use the threat library to ensure consistent coverage
- Document all risk acceptance decisions with rationale
- Track threats in the same system as other work items
- Conduct annual reviews of all active threat models
- Start with the most critical data flows and expand
- Keep sessions timeboxed (90 minutes maximum)
- Maintain a living threat library updated with new patterns
Related Skills
- sast-scanning - Code analysis
- penetration-testing - Validation of threat model findings
- incident-response - Response when threats materialize
Entra App RegistrationCorrectly register an application in Microsoft Entra ID, configure OAuth 2.0 flows, request the right API permissions, and generate working MSAL authentication snippets484k1.3k
Openclaw Secure Linux CloudDeploy and harden an OpenClaw agent instance on a Linux cloud server following battle-tested security defaults.270k72
Better Auth Best PracticesCorrectly configure Better Auth for secure authentication with database adapters, sessions, OAuth, email/password, and plugins in TypeScript projects.80.9k206
Firebase Security Rules AuditorAutomatically audit Firebase Firestore security rules for bypass vulnerabilities and logic gaps before deploying.80.4k397
Audit WebsiteRun comprehensive audits that surface SEO, performance, security, technical, and content issues with LLM-optimized reports and health scores.65.6k85