threat-modeling

Produces structured threat models for software systems using STRIDE on data flow diagrams. Generates DFDs with trust boundaries, identifies threats per element, scores risks, and defines concrete mitigations. Outputs a complete threat model Markdown document through phased, interactive delivery. Use when threat modeling a system, analyzing security threats, identifying attack surfaces, performing STRIDE analysis, assessing security risks in architecture, creating a threat model document, or when the user mentions threat model, attack surface, trust boundaries, STRIDE, or security risk analysis.

Threat Modeling

Produce a threat model for a user-described system using STRIDE-per-element on a data flow diagram.

Workflow

Deliver in phases, presenting each for user review before proceeding. For "quick" or "draft" requests, produce the full document in one pass.

Phase 1: Scope and system model

  1. Gather from the user: system purpose, components, data flows, actors, deployment context.
  2. Ask about:
    • Trust boundaries (where privilege, network, or ownership changes)
    • Data classifications (PII, secrets, financial, health, IP)
    • Threat actors (external attacker, insider, automated, nation-state)
  3. Draw a Level-1 DFD in ASCII art showing processes (⬭), data stores (▭▭), external entities (⬜), data flows (→), and trust boundaries (┄┄┄).
  4. List assets with Confidentiality / Integrity / Availability ratings.

Present the DFD and asset list. Ask the user to confirm or correct before proceeding.

Trust boundaries to check:

  • Internet ↔ DMZ / edge
  • App tier ↔ data tier
  • Authenticated ↔ admin scope
  • Your org ↔ vendor / 3rd-party API
  • Tenant A ↔ Tenant B (multi-tenant)
  • Host ↔ container / serverless
  • LLM system prompt ↔ untrusted user or tool input

For DFD construction details, see references/01-foundations-and-system-modeling.md.

Phase 2: Identify threats

Apply STRIDE-per-element, starting at trust boundary crossings.

STRIDEThreatViolatesApplies to
S SpoofingForged identityAuthenticityProcesses, external entities
T TamperingModified dataIntegrityProcesses, data stores, data flows
R RepudiationDeniable actionNon-repudiabilityProcesses, data stores*, external entities
I Info disclosureData leakConfidentialityProcesses, data stores, data flows
D Denial of serviceUnavailabilityAvailabilityProcesses, data stores, data flows
E Elevation of privilegeUnauthorized accessAuthorizationProcesses

* Only if the store serves as an audit log.

For each element or flow crossing a trust boundary:

  1. Walk S-T-R-I-D-E. Ask: "How could this happen here?"
  2. Record each credible threat as: asset, adversary, method, consequence.
  3. Consider chained threats — an I enabling an E enabling a T.

Present the threat list. Ask the user to confirm before proceeding.

Example threat row (data flow: User → Web Frontend over HTTPS):

STRIDEElement/FlowThreatMitigation
SUser → FrontendAttacker impersonates user with stolen session tokenTLS 1.3, short-lived tokens, MFA
IUser → FrontendSession cookie leaked via XSSHttpOnly, Secure, SameSite=Lax, strict CSP

Does this system include AI, LLM, or agentic components? If yes, read references/05-ai-and-agentic-threats.md and apply its additional threat categories.

For STRIDE session details and pitfalls, see references/02-methodologies-and-stride.md.

Phase 3: Score and prioritize

FieldValues
LikelihoodLow (1) / Medium (2) / High (3)
ImpactLow (1) / Medium (2) / High (3) / Severe (4)
ExposureInternal (1) / Authenticated (2) / Public (3)
ScoreLikelihood × Impact × Exposure
Tier1–5 Low · 6–12 Medium · 13–24 High · 25+ Critical

For each threat, assign disposition:

DispositionWhen
MitigateReduce likelihood/impact with controls
TransferShift to a party better positioned to bear it
AcceptBelow tolerance; document owner + review date
EliminateRemove the feature or asset

For alternative scoring schemes (CVSS, OWASP Risk Rating), see references/03-risk-scoring-and-mitigations.md.

Phase 4: Define mitigations

For each threat not accepted or transferred, define a mitigation that is concrete (specific control, not "improve security"), testable, layered (multiple controls for Critical/High), and owned.

STRIDECanonical controls
SMFA, mTLS, FIDO2, token binding, service identity (SPIFFE)
TInput validation, parameterized queries, HMAC/signing, CSP
RAppend-only audit logs, signed actions, centralized SIEM
IEncryption (transit + rest), least privilege, data minimization, output sanitization
DRate limiting, circuit breakers, autoscaling, quotas, WAF, CDN
ELeast privilege, authz on every request, separation of duties, sandboxing

Present mitigations. Ask the user to confirm before producing the final document.

For mitigation catalogs and MITRE ATT&CK/D3FEND integration, see references/03-risk-scoring-and-mitigations.md.

Phase 5: Produce the threat model document

Assemble the final document using this template:

# Threat Model: <System Name>

## Metadata
- **Owner(s):**
- **Last reviewed:** YYYY-MM-DD
- **Next review due:** YYYY-MM-DD

## System Description
<1–3 paragraphs: what the system does, who uses it.>

## Scope
- **In scope:**
- **Out of scope:**
- **Assumptions:**

## Assets
| Asset | Description | C | I | A | Notes |
|---|---|---|---|---|---|

## Actors
| Actor | Legitimate? | Motivation | Capability |
|---|---|---|---|

## Data Flow Diagram
<ASCII DFD with trust boundaries marked.>

## Trust Boundaries
| Boundary | Separates | Controls |
|---|---|---|

## Threats
| ID | STRIDE | Element/Flow | Threat | L | I | E | Score | Tier | Mitigation | Owner | Status |
|----|--------|--------------|--------|---|---|---|-------|------|-----------|-------|--------|

## Accepted Risks
| ID | Description | Rationale | Owner | Review Date |
|---|---|---|---|---|

## Open Questions
-

## Change Log
- YYYY-MM-DD: Initial threat model

Edge cases

Reference material

Load on demand for deeper guidance: