Threat Model

Step 2: Data Flow Mapping (MANDATORY)

Map every path data takes through the system. This is the foundation of the threat model.

graph LR
    subgraph "Trust Boundary: Internet"
        User[User Browser]
    end

    subgraph "Trust Boundary: DMZ"
        LB[Load Balancer]
        WAF[WAF]
    end

    subgraph "Trust Boundary: Application"
        API[API Server]
        Worker[Background Worker]
    end

    subgraph "Trust Boundary: Data"
        DB[(Database)]
        Cache[(Redis)]
        Queue[Message Queue]
    end

    subgraph "Trust Boundary: External"
        ThirdParty[Third-party API]
    end

    User -->|HTTPS| WAF
    WAF -->|HTTP| LB
    LB -->|HTTP| API
    API -->|SQL/TLS| DB
    API -->|Redis Protocol| Cache
    API -->|AMQP| Queue
    Queue -->|AMQP| Worker
    Worker -->|SQL/TLS| DB
    API -->|HTTPS| ThirdParty

For each data flow, document:

Trust boundaries are the critical concept. Every time data crosses a trust boundary, it must be validated, authenticated, and potentially encrypted.

Step 3: STRIDE Analysis (per component and data flow)

For EACH component and EACH data flow crossing a trust boundary, systematically evaluate all six STRIDE categories:

Spoofing (Identity)

Tampering (Integrity)

Repudiation (Accountability)

Information Disclosure (Confidentiality)

Denial of Service (Availability)

Elevation of Privilege (Authorisation)

Step 4: Risk Assessment (MANDATORY — every threat gets a score)

For each identified threat, assess risk as likelihood x impact:

Likelihood:

Impact:

Risk matrix:

Step 5: Mitigations

For each threat, document the mitigation:

Control types:

• Preventive — stops the attack (input validation, encryption, auth)
• Detective — detects the attack (monitoring, logging, alerting)
• Corrective — responds to the attack (incident response, auto-remediation)

Each threat must have at least one preventive control. Detective and corrective controls are layered on top (defence in depth).

Step 6: Residual Risk Assessment

After mitigations, reassess:

• What risk remains even with mitigations in place?
• Are there accepted risks? (Document them explicitly with an owner and review date)
• What would change the risk profile? (New features, scale changes, regulatory changes)

Anti-Patterns (NEVER do these)

• Threat modelling without data flows — if you haven't mapped data flows, you haven't threat modelled. You've just made a list of worries
• Generic threats without specifics — "SQL injection is a risk" without identifying WHERE in YOUR system it's a risk is useless
• No risk scoring — every threat needs likelihood and impact. Without scoring, everything is equally important (which means nothing is)
• Mitigations without status — a mitigation that says "use encryption" without noting whether it's implemented or TODO is incomplete
• One-time exercise — threat models must be updated when the system changes. If the architecture changes, the threat model changes
• Ignoring insider threats — most threat models only consider external attackers. Insiders are often the highest-capability threat actor

Output Format

# Threat Model: [System Name]

## Scope
- **System:** [name and version]
- **In scope:** [components]
- **Out of scope:** [exclusions]
- **Threat actors:** [table]

## Data Flow Diagram
[Mermaid diagram with trust boundaries]

## Data Flow Inventory
| Flow | Protocol | Auth | Encryption | Classification |
|---|---|---|---|---|

## STRIDE Analysis
### [Component/Flow Name]
[Per-STRIDE-category analysis with evidence]

## Risk Register
| # | STRIDE | Threat | Likelihood | Impact | Risk | Mitigation | Status |
|---|---|---|---|---|---|---|---|

## Prioritised Action Items
1. [Critical risk — immediate action required]
2. [High risk — address this sprint]
3. [Medium risk — planned for next iteration]

## Accepted Risks
| Risk | Justification | Owner | Review date |
|---|---|---|---|

## Review Schedule
- Next review: [date or trigger event]
- Review triggers: [new features, architecture changes, incidents]

Related Skills

• /security-engineer:security-review — validate that modelled threats have adequate mitigations in the code.
• /security-engineer:dependency-audit — check that third-party components in the threat surface aren't themselves vulnerable.

Use the threat model template (templates/threat-model.md) for consistent output structure.