securityengineering
Threat Model Writing
Create STRIDE-based threat models with asset identification, threat actor enumeration, attack surface mapping, risk scoring, and a prioritized mitigation matrix — producing a living security document.
threat-modelingSTRIDEsecurityrisk-assessmentattack-surface
Works well with agents
Works well with skills
threat-model-writing/
SKILL.md
Markdown| 1 | |
| 2 | # Threat Model Writing |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following information. If any is missing, ask the user before proceeding: |
| 7 | |
| 8 | 1. **System description** — What does the system do? Architecture type (monolith, microservices, serverless)? |
| 9 | 2. **Data sensitivity** — PII, financial, health, credentials, intellectual property? |
| 10 | 3. **Trust boundaries** — Where does trusted meet untrusted? Browser-to-API, service-to-database, internal-to-third-party? |
| 11 | 4. **Deployment environment** — Cloud provider, on-prem, hybrid? Network boundaries? |
| 12 | 5. **Compliance requirements** — SOC 2, HIPAA, PCI-DSS, GDPR, or none? |
| 13 | 6. **Existing security controls** — Authentication, authorization, encryption, and monitoring already in place? |
| 14 | |
| 15 | If the user provides only a feature name ("we built a payments API"), push back and ask for architecture details, data flows, and trust boundaries. |
| 16 | |
| 17 | ## Threat model template |
| 18 | |
| 19 | Every section is required unless explicitly marked optional. |
| 20 | |
| 21 | ### Title |
| 22 | |
| 23 | `[System Name] — STRIDE Threat Model` |
| 24 | |
| 25 | ### 1. System Overview (3-5 sentences) |
| 26 | |
| 27 | Describe purpose, architecture, and key data flows. List major components and how they communicate: |
| 28 | |
| 29 | ``` |
| 30 | User Browser → (HTTPS) → API Gateway → (gRPC) → Auth Service → (TLS) → Database |
| 31 | → (gRPC) → Payment Service → (TLS) → Stripe API |
| 32 | ``` |
| 33 | |
| 34 | ### 2. Assets |
| 35 | |
| 36 | Enumerate what an attacker would target. For each asset, state CIA requirements: |
| 37 | |
| 38 | | Asset | Confidentiality | Integrity | Availability | Notes | |
| 39 | |-------|----------------|-----------|--------------|-------| |
| 40 | | User credentials | Critical | Critical | High | Hashed with bcrypt, salted | |
| 41 | | Payment tokens | Critical | Critical | High | Tokenized via Stripe, never stored raw | |
| 42 | |
| 43 | ### 3. Threat Actors |
| 44 | |
| 45 | Identify who might attack the system and their capabilities. Tailor to the system — a B2B internal tool has different actors than a public consumer API. |
| 46 | |
| 47 | - **External unauthenticated** — Script kiddies, automated scanners. Low skill, high volume. |
| 48 | - **External authenticated** — Malicious users with valid accounts. Medium skill, targeted. |
| 49 | - **Insider** — Employees or contractors with system access. High skill, privileged. |
| 50 | - **Supply chain** — Compromised dependencies or third-party services. |
| 51 | |
| 52 | ### 4. Attack Surface |
| 53 | |
| 54 | Map every entry point: network endpoints, authentication flows, data inputs (uploads, forms, query params, webhooks), administrative interfaces (admin panels, CI/CD pipelines), and third-party integrations. |
| 55 | |
| 56 | ### 5. STRIDE Threat Matrix |
| 57 | |
| 58 | For each STRIDE category, list threats with concrete attack scenarios. Use one table per category with columns: ID, Threat, Attack scenario, Affected component. Prefix IDs by category (S-, T-, R-, I-, D-, E-). |
| 59 | |
| 60 | | ID | Category | Threat | Attack scenario | Component | |
| 61 | |----|----------|--------|-----------------|-----------| |
| 62 | | S-1 | Spoofing | Session hijacking | Attacker steals session cookie via XSS on profile page | Auth Service | |
| 63 | | T-1 | Tampering | Price manipulation | Attacker modifies cart total in client-side request | Payment Service | |
| 64 | | R-1 | Repudiation | Unsigned admin actions | Admin deletes data with no audit log entry | Admin Panel | |
| 65 | | I-1 | Info Disclosure | Verbose errors | Stack traces leak DB schema to unauthenticated users | API Gateway | |
| 66 | | D-1 | Denial of Service | Unthrottled endpoint | 10k req/sec to /search exhausts DB connections | API Gateway | |
| 67 | | E-1 | Elevation of Privilege | IDOR | User accesses other users' data by changing ID in URL | API Gateway | |
| 68 | |
| 69 | Every threat must describe a specific attack, not a generic category. "SQL injection" is not a threat; "Attacker injects SQL via the unsanitized `search` param in `/api/products`" is. |
| 70 | |
| 71 | ### 6. Risk Scoring |
| 72 | |
| 73 | Score each threat: Likelihood (1-5) x Impact (1-5) = Risk Score. |
| 74 | |
| 75 | | Threat ID | Likelihood | Impact | Risk Score | Priority | |
| 76 | |-----------|-----------|--------|------------|----------| |
| 77 | | E-1 | 4 | 5 | 20 | Critical | |
| 78 | | T-1 | 4 | 4 | 16 | Critical | |
| 79 | | S-1 | 3 | 5 | 15 | Critical | |
| 80 | | I-1 | 3 | 3 | 9 | High | |
| 81 | |
| 82 | Priority bands: Critical (15-25), High (8-14), Medium (4-7), Low (1-3). |
| 83 | |
| 84 | ### 7. Mitigations |
| 85 | |
| 86 | For each threat at High or above, specify a concrete mitigation with a named control and current status. |
| 87 | |
| 88 | | Threat ID | Mitigation | Control type | Status | |
| 89 | |-----------|-----------|--------------|--------| |
| 90 | | E-1 | Enforce server-side ownership checks on every data access query | Preventive | Not started | |
| 91 | | T-1 | Validate and sign cart totals server-side; reject tampered payloads | Preventive | Not started | |
| 92 | | S-1 | Set CSP headers; sanitize all user-generated content | Preventive | Partial | |
| 93 | |
| 94 | Status values: Not started, In progress, Partial, Complete. |
| 95 | |
| 96 | ### 8. Residual Risk (optional) |
| 97 | |
| 98 | After mitigations, list risks that remain accepted. Document why (cost, low likelihood, compensating controls), who approved acceptance, and when it will be re-evaluated. |
| 99 | |
| 100 | --- |
| 101 | |
| 102 | ## Quality checklist |
| 103 | |
| 104 | Before delivering a threat model, verify: |
| 105 | |
| 106 | - [ ] Every asset has CIA ratings, not just a name |
| 107 | - [ ] Threat actors are tailored to this system, not a generic list |
| 108 | - [ ] Every STRIDE threat has a concrete attack scenario |
| 109 | - [ ] Risk scores use both likelihood and impact, not gut feeling |
| 110 | - [ ] Mitigations name specific controls ("add CSP headers"), not vague guidance ("improve security") |
| 111 | - [ ] All Critical and High threats have mitigations with a clear status |
| 112 | - [ ] Trust boundaries and data flows are explicitly documented |
| 113 | |
| 114 | ## Common mistakes to avoid |
| 115 | |
| 116 | - **Generic threats without scenarios**. "SQL injection" is a category. "Attacker injects SQL via the unsanitized `search` param in `/api/products`" is a threat. |
| 117 | - **Ignoring insider threats**. Most models only consider external attackers. Always model what a malicious or compromised insider could do. |
| 118 | - **Mitigations without status tracking**. "Encrypt data" with no owner or status is a wish, not a control. |
| 119 | - **Scoring all threats as Critical**. If everything is critical, nothing is. Use the full scoring range. |
| 120 | - **Treating the model as a one-time artifact**. Note the review cadence (quarterly, per-release) and who owns updates. |
| 121 |