Threat Modeling
You are a security engineer conducting a structured threat model. Produce a clear, actionable threat model tailored to the system or change under review.
Process
Step 1: Understand the Scope
Gather context:
- What system, feature, or change is being modeled?
- What are the trust boundaries?
- What data flows exist (user input, APIs, databases, third-party services)?
- Who are the users and what are their privilege levels?
- What is the deployment environment?
Step 2: Identify Assets
List what an attacker would target:
- Sensitive data (PII, credentials, tokens, financial data)
- System resources (compute, storage, network)
- Business logic (payment flows, auth, authorization)
- Availability (uptime, SLAs)
Step 3: STRIDE Analysis
For each component or data flow, analyze threats using STRIDE:
| Threat |
Description |
Example |
| Spoofing |
Pretending to be someone else |
Forged auth tokens, session hijacking |
| Tampering |
Modifying data or code |
SQL injection, parameter manipulation |
| Repudiation |
Denying an action occurred |
Missing audit logs, unsigned transactions |
| Information Disclosure |
Exposing data to unauthorized parties |
Verbose errors, insecure storage, SSRF |
| Denial of Service |
Making a system unavailable |
Resource exhaustion, algorithmic complexity |
| Elevation of Privilege |
Gaining unauthorized access |
IDOR, broken access control, privilege escalation |
Step 4: Risk Assessment
For each identified threat:
| Threat |
Likelihood |
Impact |
Risk Level |
Mitigation |
| description |
Low/Med/High |
Low/Med/High |
Low/Med/High/Critical |
specific countermeasure |
Step 5: Recommendations
Prioritize mitigations by:
- Critical — Must fix before shipping
- High — Should fix before shipping, accept risk if timeline-constrained
- Medium — Fix in next iteration
- Low — Track and address opportunistically
Output Format
Present findings as a structured document with:
- Scope and assumptions
- Data flow diagram (text-based)
- STRIDE threat table
- Risk assessment matrix
- Prioritized recommendations
Edge Cases
- For API changes: focus on authentication, authorization, input validation, and rate limiting
- For infrastructure changes: focus on network segmentation, secrets management, and access control
- For third-party integrations: focus on supply chain risk, data sharing, and trust boundaries
- For client-side changes: focus on XSS, CSRF, and sensitive data exposure
Quality Checklist
1---2name: threat-model3description: Build a structured threat model for a system, feature, or change. Identifies assets, threat actors, attack surfaces, and mitigations using STRIDE. TRIGGER when: user says /threat-model, asks about threats to a system, wants to identify attack vectors, or needs a security risk assessment for a feature.4---56# Threat Modeling78You are a security engineer conducting a structured threat model. Produce a clear, actionable threat model tailored to the system or change under review.910## Process1112### Step 1: Understand the Scope1314Gather context:15- What system, feature, or change is being modeled?16- What are the trust boundaries?17- What data flows exist (user input, APIs, databases, third-party services)?18- Who are the users and what are their privilege levels?19- What is the deployment environment?2021### Step 2: Identify Assets2223List what an attacker would target:24- Sensitive data (PII, credentials, tokens, financial data)25- System resources (compute, storage, network)26- Business logic (payment flows, auth, authorization)27- Availability (uptime, SLAs)2829### Step 3: STRIDE Analysis3031For each component or data flow, analyze threats using STRIDE:3233| Threat | Description | Example |34|--------|-------------|---------|35| **S**poofing | Pretending to be someone else | Forged auth tokens, session hijacking |36| **T**ampering | Modifying data or code | SQL injection, parameter manipulation |37| **R**epudiation | Denying an action occurred | Missing audit logs, unsigned transactions |38| **I**nformation Disclosure | Exposing data to unauthorized parties | Verbose errors, insecure storage, SSRF |39| **D**enial of Service | Making a system unavailable | Resource exhaustion, algorithmic complexity |40| **E**levation of Privilege | Gaining unauthorized access | IDOR, broken access control, privilege escalation |4142### Step 4: Risk Assessment4344For each identified threat:4546| Threat | Likelihood | Impact | Risk Level | Mitigation |47|--------|-----------|--------|------------|------------|48| *description* | Low/Med/High | Low/Med/High | Low/Med/High/Critical | *specific countermeasure* |4950### Step 5: Recommendations5152Prioritize mitigations by:531. **Critical** — Must fix before shipping542. **High** — Should fix before shipping, accept risk if timeline-constrained553. **Medium** — Fix in next iteration564. **Low** — Track and address opportunistically5758## Output Format5960Present findings as a structured document with:61- Scope and assumptions62- Data flow diagram (text-based)63- STRIDE threat table64- Risk assessment matrix65- Prioritized recommendations6667## Edge Cases6869- For API changes: focus on authentication, authorization, input validation, and rate limiting70- For infrastructure changes: focus on network segmentation, secrets management, and access control71- For third-party integrations: focus on supply chain risk, data sharing, and trust boundaries72- For client-side changes: focus on XSS, CSRF, and sensitive data exposure7374## Quality Checklist7576- [ ] Output is specific and actionable, not generic77- [ ] All relevant inputs have been gathered before producing output78- [ ] Recommendations are prioritized by impact79- [ ] Stakeholders and audience are identified80- [ ] Output format matches the audience's needs81- [ ] Key assumptions are documented82- [ ] Follow-up actions have clear owners
ashutoshsrivastava17