---
name: threat-model-builder
description: Describe a system in plain English and receive a structured STRIDE threat model with data flow diagram, threat list per element, prioritised mitigations, and residual-risk register.
version: 1.0.0
author: VantagePoint Networks
audience: Product Managers, Architects, Security Engineers, Engineering Leads
output_format: Markdown — system description, asset/flow inventory, STRIDE threats, mitigations, residual risk.
license: MIT
---

# Threat Model Builder

A Claude Code skill that produces a STRIDE threat model in under an hour, not a week. Consumes a plain-English description of a system and produces a working threat model complete with data flow diagram (text-based), per-element threats, mitigations, and a residual risk register.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/threat-model-builder`. Describe the system, its users, its data, and its boundaries.

## When to use this

- A new feature is entering design review and you need a threat model but no dedicated security engineer.
- An architecture review is scheduled and you want a first-draft threat model to react to.
- You're preparing for a pen test and want to give the testers a threat model to work from.
- Compliance (ISO 27001, SOC 2, NIS 2) asks for threat modelling evidence on significant changes.
- You're building a security training exercise and want a worked example.

## What you'll get

A Markdown threat model with:

1. **System description** — what it does, who uses it, what data it handles.
2. **Assets** — data, systems, credentials, brand.
3. **Trust boundaries** — where authority changes (public internet, auth'd user, admin, backend service account).
4. **Data flow diagram** — text-based (like a mermaid or PlantUML-compatible pseudo-diagram).
5. **STRIDE analysis per element/flow** — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
6. **Threat list** — prioritised by likelihood × impact.
7. **Mitigations** — preventive, detective, corrective.
8. **Residual risks** — what we accept with rationale.
9. **Validation checklist** — questions a pen tester / reviewer should ask.

## Clarifying questions I will ask you

1. **What does the system do?** — 2–3 sentences.
2. **Who uses it?** — user types + their authority levels.
3. **What data does it process or store?** — types, classification, volume if relevant.
4. **What does it connect to?** — external APIs, internal services, databases, third-party.
5. **Trust boundaries** — where do internet / auth'd user / admin / backend transitions happen?
6. **Deployment** — cloud (which one), on-prem, hybrid?
7. **Identity / AuthN** — how do users authenticate? MFA? SSO?
8. **Threats you're specifically worried about** — if any.
9. **Regulatory scope** — PCI, HIPAA, GDPR, ITAR, etc.

## How I build the model

I follow a simplified Microsoft STRIDE + Shostack's "four questions":
- What are we building?
- What can go wrong?
- What are we going to do about it?
- Did we do a good job?

And per element, I walk STRIDE:

| Letter | Threat class | Typical control |
|---|---|---|
| **S**poofing | Impersonation | Strong authN, MFA, certificate auth |
| **T**ampering | Unauthorised modification | Integrity signatures, immutability, code signing |
| **R**epudiation | "Wasn't me" | Tamper-evident audit log, non-repudiation via signed records |
| **I**nformation disclosure | Data leak | Encryption in transit + at rest, access control, log redaction |
| **D**enial of service | Availability | Rate limiting, quota, load shedding, DDoS protection |
| **E**levation of privilege | AuthZ bypass | Least privilege, authZ checks on every boundary, defence in depth |

## Example output (excerpt)

Input: *"A SaaS customer-support portal. Customers log in via email + password + SMS OTP to view their own tickets, create new ones, and upload attachments. Agents log in via SSO from our IdP to triage tickets. Everything hosted on AWS. Uses Postgres (RDS), S3 for attachments, SendGrid for outbound email."*

```markdown
# Threat model — Customer Support Portal

## System description
Customer-facing support portal. Customers: email + password + SMS OTP, see own tickets only. Agents: SAML SSO from corporate IdP, triage all tickets. Data: ticket text, PII (name, email, phone), attachments (potential PII/confidential). Hosted on AWS us-east-1 + eu-west-2 active-active.

## Assets (ranked)
1. Customer ticket data + attachments (PII, sometimes sensitive)
2. Authentication credentials (customer + agent)
3. System availability (brand + SLA)
4. Audit log integrity
5. Outbound email reputation

## Trust boundaries
- Public internet ↔ CDN / WAF
- WAF ↔ App
- App ↔ DB (RDS)
- App ↔ S3
- App ↔ SendGrid
- Corporate IdP ↔ App (agent SSO)
- Customer browser ↔ App (session cookie)

## Data flow diagram (textual)
\`\`\`
Customer browser ──(HTTPS, session cookie)──> CDN ──> WAF ──> App
                                                             ├──> RDS (ticket metadata)
                                                             ├──> S3 (attachments, signed URLs)
                                                             └──> SendGrid (notifications)
Agent browser ──(HTTPS, SAML session)──> CDN ──> WAF ──> App [admin context]
Corporate IdP ──(SAML)──> App
\`\`\`

## STRIDE — Customer AuthN flow

### S — Spoofing
- **Threat:** credential stuffing on the login endpoint.
- **Likelihood:** High. **Impact:** Medium-High.
- **Mitigations:**
  - Rate limit login attempts per IP + per account.
  - MFA (SMS OTP is weak — recommend TOTP or passkey for high-value tenants).
  - Breached-password lookup (HIBP Pwned Passwords) on registration + periodic sweep.
  - CAPTCHA on suspicious attempts.

### T — Tampering
- **Threat:** session token manipulation.
- **Mitigations:** HMAC-signed session cookies, HttpOnly + Secure + SameSite=Lax, short TTL.

### R — Repudiation
- **Threat:** customer claims "I didn't open that ticket".
- **Mitigations:** immutable append-only audit log with per-action signing; IP + user-agent + session ID recorded.

### I — Information disclosure
- **Threat:** IDOR on ticket retrieval returning other customers' data.
- **Mitigations:** authZ on every endpoint, row-level security in DB keyed on customer_id, negative test case on every ticket endpoint.

### D — Denial of service
- **Threat:** password-reset flood exhausting SendGrid quota.
- **Mitigations:** per-account + global rate limit on password reset; alert on quota nearing; backup MTA.

### E — Elevation of privilege
- **Threat:** parameter tampering elevates customer session to agent.
- **Mitigations:** strict session role claim, authZ at the API layer, no client-side role determination.

## STRIDE — Agent SSO flow
[... similar treatment ...]

## Top prioritised threats (for backlog)

| Priority | Threat | Element | Likelihood | Impact | Mitigation in place? |
|---|---|---|---|---|---|
| P1 | IDOR on /api/tickets/:id | App ↔ RDS | Med | High (PII disclosure) | Partial — add negative tests + row-level DB policy |
| P1 | Credential stuffing | Customer login | High | Med | Partial — add breached-password + TOTP option |
| P2 | SendGrid quota DoS | App ↔ SendGrid | Med | Med | Missing — add rate limit + secondary MTA |
| P2 | Signed S3 URL replay | App ↔ S3 | Low | Med | Partial — short TTL; ensure single-use nonce |
| P3 | Session fixation | Customer login | Low | Med | In place |

## Residual risks accepted
- SMS OTP is phishable and SIM-swap exposed. Accepted for phase 1; TOTP/passkey on roadmap for phase 2.
- SendGrid is a single point of failure for outbound notifications. Accepted; DR plan covers a manual swap to SES.

## Validation checklist (handover to pen test)
- [ ] Test IDOR on every `/api/tickets/:id`, `/api/attachments/:id`, `/api/users/:id`.
- [ ] Credential stuffing + password-spray against `/api/login` — expect rate limit + lockout.
- [ ] Session tampering: modify role claim, replay cookie.
- [ ] S3 signed URL: attempt replay after expiry, attempt with different user session.
- [ ] SendGrid rate limit: trigger password reset loop, confirm limit.
- [ ] Agent privilege escalation: as customer, attempt endpoints prefixed `/admin/`.
```

## What I won't do

- I won't invent threats that don't apply (e.g., supply-chain attacks on a pure-SaaS component).
- I won't rate risk without reasoning — every priority has a likelihood + impact written down.
- I won't produce a 300-page model when a 10-page one is useful.
- I won't claim completeness; threat modelling is iterative, and I'll note what needs follow-up.

## Reference

- [Microsoft STRIDE](https://learn.microsoft.com/en-us/training/modules/tm-introduction-to-threat-modeling/)
- Adam Shostack — "Threat Modeling: Designing for Security"
- OWASP Threat Modeling Cheat Sheet
- Shostack's "Four Questions": build / go wrong / do about it / good job

## Attribution

Built by **Hak** at **VantagePoint Networks**. MIT licensed.