# Threat Modeling > Structured threat modeling for systems, features, and architecture changes — STRIDE plus OWASP/ATT&CK, calibrated by impact and likelihood. Use when asked for a threat model or design security review, or when someone describes a design and asks "is this secure?" / "how could this be abused?" / "what could go wrong?" - Skill: `aarnold-livefront/threat-modeling` (Agent Skill) - Install (CLI): `npx skillmds@latest add aarnold-livefront/threat-modeling` - Raw SKILL.md: https://api.skillmd.com/api/skills/aarnold-livefront/threat-modeling/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: aarnold-livefront (https://skillmd.com/u/aarnold-livefront) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/aarnold-livefront/threat-modeling --- # Threat Modeling Threat modeling answers one question: *what could go wrong, and does it matter enough to fix?* Frameworks structure the thinking — they don't replace it. Understand the system first, then apply structured analysis to surface threats you might otherwise miss. ## The process ### 1. Understand the system Before naming threats, establish: - **What does it do?** Core function, data handled, happy path - **Who are the actors?** Legitimate users, admins, external services, anonymous callers — and potential adversaries - **What's valuable?** What would an attacker want to steal, corrupt, disrupt, or impersonate? - **What are the trust boundaries?** Where does data or control flow from one trust level to another — across a network, a process boundary, between user roles, between internal and external systems? Sketch data flows and trust boundaries explicitly, even in prose. Threats live at boundaries. ### 2. Enumerate threats with STRIDE For each trust-boundary crossing and each significant component, work through: - **Spoofing** — false identity claims (credential theft, token replay, DNS spoofing, ARP poisoning) - **Tampering** — undetected modification of data in transit or at rest (MITM, SQL injection, parameter manipulation, log tampering) - **Repudiation** — denying an action was taken (missing audit logs, unsigned operations, log deletion) - **Information Disclosure** — sensitive data reaching unauthorized parties (IDOR, over-permissive APIs, error messages, side channels) - **Denial of Service** — degrading or denying availability (resource exhaustion, algorithmic complexity, missing rate limits, state exhaustion) - **Elevation of Privilege** — gaining more access than intended (role bypass, JWT manipulation, path traversal, deserialization) For each threat that applies: name it, describe the realistic attack path (who does what, from where), estimate impact and likelihood. ### 3. Layer in OWASP and ATT&CK STRIDE is comprehensive but abstract. Supplement with: **OWASP Top 10** — sanity check on the most common real-world web/API vulnerabilities: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, authentication failures, software integrity failures, logging failures, SSRF. **MITRE ATT&CK (including ICS/IoT)** — useful when the system touches networks, devices, or operational infrastructure. ATT&CK frames threats in terms of attacker TTPs, helping you see realistic attack chains rather than isolated vulnerabilities. ATT&CK for ICS adds protocol abuse, firmware manipulation, and lateral movement through device trust chains. Use these as lenses, not checklists. A threat without a plausible attacker or realistic impact isn't worth prioritizing just because a framework names it. ### 4. Prioritize by risk — calibrated, not uniform Don't return a flat list of 40 equally-weighted items. Anchor severity to concrete outcomes for *this* system: | Severity | Anchor | |---|---| | **Critical** | Persistent attacker control, large-scale data exposure, auth bypass that grants admin, or undetected manipulation of operational systems | | **High** | Bypass of a primary security control, theft of data for one user/tenant, or remote DoS that takes the system offline | | **Medium** | Real but limited impact (single-record disclosure, partial DoS, requires already-compromised account) | | **Low** | Theoretical, requires unrealistic attacker access, or is mitigated by defense-in-depth elsewhere | Be honest. If something is low priority, say so rather than padding the list. ### 5. Recommend mitigations For each significant threat, propose a mitigation that is: - **Specific** — not "add authentication" but "add resource-level authorization checks verifying the requesting user owns the resource before returning it" - **Proportionate** — match the control to the risk; don't recommend HSMs for low-value data - **Practical** — acknowledge operational burden; a control that won't be maintained is worse than no control ## Dual-use tools If the system *intentionally* does things that would be malicious in another context — TLS interception, traffic modification, port scanning, packet capture, fuzzing, scripted breakpoints — its threat model is different from a normal web app. Cover at minimum: - **Misuse by the operator** (deliberate or accidental) — what blast radius does the tool grant a privileged user? - **Compromise of the tool itself** — if the proxy/scanner/MITM is breached, captured data and intercepted credentials are at stake; lateral risk into intercepted networks may be material - **Captured-data confidentiality** — encryption at rest, retention, access logging, redaction - **Outbound legality and consent** — note when the tool's operation depends on authorization that lives outside the code (engagement scope, rules of engagement, lab isolation) Don't bury these in generic STRIDE. They're the highest-impact threats for that class of system. ## Output format **System summary** — 2–3 sentences on what's analyzed and what's in scope. **Trust boundary map** — prose or list of where trust level changes. **Threat findings** — grouped by severity (critical → high → medium → low). Each: threat name, attack path, impact, likelihood, recommended mitigation. **Out of scope / assumptions** — what you couldn't assess; what you assumed. A threat model that clearly identifies the 3 things that matter most and explains why is more useful than one with 40 equally-weighted items. ## Worked example (abbreviated) > System: a small "share by link" feature — authenticated user creates a token-bearing URL that lets recipients view a single document for 7 days. ``` System summary: Token-bearing URLs scoped to one document, time-limited. Trust boundaries: anonymous internet → API; storage of document blobs. Critical Token guessing/brute force — if tokens are short or low-entropy, an attacker enumerates URLs and reads documents. Mitigation: 128-bit random tokens, rate-limit token-validation endpoint, lock after N failed attempts per IP. High Token leak via logs/referer — tokens in URL path/query are logged by proxies and forwarded as Referer when documents include external resources. Mitigation: put token in fragment and validate via JS, OR use a short-lived exchange where the URL token is swapped for a session cookie on first hit. Medium Revocation gap — owner deletes the doc but issued tokens still validate until expiry, depending on storage. Mitigation: validate against a "live document" check, not just token signature. Low Side-channel timing on token validation — feasible but bounded; constant-time compare resolves it. Out of scope: authn for the issuing user (assumed sound); virus scanning of shared blobs (separate control). ``` The point: anchored severities, concrete mitigations, the 3–4 things that matter — not a flat OWASP recital.