Threat Model

Threat Model

Purpose

Apply STRIDE threat modeling to identify security risks in proposed features and produce mitigation recommendations.

Scope Constraints

Analyzes feature proposals, architecture diagrams, and authentication/authorization flows for security threats. Does not execute exploits, modify code, or access production systems. Limited to design-time threat identification and mitigation planning.

Inputs

• Feature description or proposal being analyzed
• System architecture context (services, data stores, external dependencies)
• Authentication/authorization flows involved
• Data sensitivity classification

Input Sanitization

No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.

Procedure

Step 1: Define Trust Boundaries

Identify what's inside the trust boundary, what's outside, and where boundaries are crossed. Map out the system perimeter, internal service boundaries, and client/server boundaries.

Step 2: Enumerate Data Flows

Trace each data flow: user input → processing → storage → output. Identify each hop, transformation, and boundary crossing. Note where data changes trust level.

Step 3: Apply STRIDE Per Data Flow

For each data flow, analyze all six threat categories:

• Spoofing: Can someone impersonate a legitimate user or service?
• Tampering: Can data be modified in transit or at rest?
• Repudiation: Can actions be denied without an audit trail?
• Information Disclosure: Can sensitive data leak through errors, logs, or APIs?
• Denial of Service: Can the system be overwhelmed or made unavailable?
• Elevation of Privilege: Can a user gain unauthorized access to resources?

Step 4: Rate Each Threat

Use Likelihood x Impact to assign a Risk Score:

• Critical: Likely + Severe impact (data breach, full compromise)
• High: Likely + Moderate impact, or Possible + Severe impact
• Medium: Possible + Moderate impact
• Low: Unlikely + Minor impact

Step 5: Propose Mitigations

For all High+ threats, propose specific, actionable mitigations. Not "add security" — instead "validate JWT signature on every API route using middleware X" or "add rate limiting of 100 req/min per IP on /api/auth endpoints."

Step 6: Identify Residual Risks

Document what remains after mitigations are applied. Note accepted risks and their justification.

Progress Checklist

• Step 1: Trust boundaries defined
• Step 2: Data flows enumerated
• Step 3: STRIDE analysis applied per data flow
• Step 4: Threats rated by likelihood x impact
• Step 5: Mitigations proposed for High+ threats
• Step 6: Residual risks documented

Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.

Output Format

Trust Boundary Diagram

┌─────────────────────────────┐
│  Trust Boundary: [Name]     │
│                             │
│  [Internal Components]      │
│                             │
└──────────┬──────────────────┘
           │ [Data Flow]
           ▼
  [External Component]

Threat Table

Residual Risk Summary

• [Risk]: [Why it's accepted] — [Monitoring approach]

Handoff

• Hand off to failure-mode-analysis if infrastructure failure scenarios are identified during threat modeling.
• Hand off to architect/codebase-context if architectural vulnerabilities require structural remediation.

Quality Checks

• Every data flow has full STRIDE analysis
• All High+ threats have specific, actionable mitigations
• Mitigations reference concrete implementation approaches
• Auth flows are fully covered (login, session, token refresh, logout)
• Third-party integrations are analyzed for trust boundary crossings
• Residual risks are documented with justification

Evolution Notes