Execution Threat Modeling

Threat Modeling (STRIDE)

Systematic process to identify, score, and mitigate security threats before they become vulnerabilities.

When to Threat Model

• New system or service being designed
• Significant architectural change to existing system
• New data flow involving sensitive/regulated data
• Integration with external/untrusted systems
• Before security-critical feature development

Workflow

Step 1: Decompose the System

Identify and document:

1. Assets: What are we protecting? (data, services, credentials, reputation)
2. Entry points: Where can external actors interact? (APIs, UI, file uploads, webhooks, message queues)
3. Trust boundaries: Where do privilege levels change? (client→server, public→private subnet, service→database)
4. Data flows: How does data move between components? (HTTP, gRPC, events, files)
5. Technologies: What stack is used? (language, framework, database, cloud services)

Output: A data flow diagram (DFD) showing components, data stores, data flows, and trust boundaries.

[Browser] --HTTPS--> |TRUST BOUNDARY| --> [API Gateway] --gRPC--> [User Service] --SQL--> [(User DB)]
                                                |
                                          --gRPC--> [Order Service] --SQL--> [(Order DB)]
                                                |
                                          --HTTPS--> [Payment Provider (external)]

Step 2: Identify Threats (STRIDE)

For each component and data flow, systematically check each STRIDE category:

Process: Walk through each component on the DFD and ask all 6 STRIDE questions. Document every plausible threat.

Step 3: Score Severity

Use simplified DREAD scoring (1–3 scale for speed):

Score = sum of all factors (range 5–15)

Step 4: Prioritize Mitigations

For each threat above the acceptable risk threshold:

1. Eliminate: Remove the feature/component that creates the threat
2. Mitigate: Add controls that reduce likelihood or impact
3. Transfer: Shift risk to a third party (insurance, managed service)
4. Accept: Document as known risk with owner and review date

Prioritize mitigations by:

• Score (highest first)
• Cost of mitigation (prefer cheap, structural fixes)
• Coverage (one fix that addresses multiple threats)

Step 5: Document Residual Risks

After mitigations are planned, document what remains:

• Threats accepted without mitigation (with justification)
• Threats partially mitigated (residual risk level)
• Assumptions that must hold for mitigations to be effective
• Monitoring/detection for accepted risks

STRIDE Mitigation Patterns

Reusable Template

# Threat Model: [System/Feature Name]

**Date**: YYYY-MM-DD
**Author**: [Name]
**Reviewers**: [Names]
**Status**: Draft | Reviewed | Approved

## 1. System Overview

[Brief description of the system and its purpose]

### 1.1 Assets
| Asset | Sensitivity | Description |
|-------|-------------|-------------|
| | | |

### 1.2 Entry Points
| ID | Entry Point | Protocol | Auth Required |
|----|-------------|----------|---------------|
| EP1 | | | |

### 1.3 Trust Boundaries
| Boundary | From | To | Controls |
|----------|------|-----|----------|
| TB1 | | | |

### 1.4 Data Flow Diagram

[Diagram or description showing components, flows, and trust boundaries]

## 2. Threats Identified

| ID | Component | STRIDE | Threat Description | Score (DREAD) | Priority |
|----|-----------|--------|-------------------|---------------|----------|
| T1 | | | | /15 | |
| T2 | | | | /15 | |

## 3. Mitigations

| Threat ID | Mitigation | Strategy | Owner | Status |
|-----------|-----------|----------|-------|--------|
| T1 | | Eliminate/Mitigate/Transfer/Accept | | |

## 4. Residual Risks

| Threat ID | Residual Risk | Justification | Review Date |
|-----------|--------------|---------------|-------------|
| | | | |

## 5. Assumptions

- [Assumption 1]
- [Assumption 2]

## 6. Review Schedule

Next review: [Date or trigger condition]

Tips for Effective Threat Modeling

• Timebox: 60–90 minutes per session. Multiple short sessions beat one marathon.
• Right people: Developer(s) who built it + security-minded reviewer + ops/infrastructure if relevant.
• Iterate: Update the threat model when the system changes, not just at initial design.
• Focus on high-value targets: Start with the most sensitive data flows and exposed entry points.
• Use "what if" thinking: "What if this service is compromised? What if this credential leaks? What if this input is 10GB?"
• Don't boil the ocean: A focused threat model on the critical path beats a shallow model of everything.

Quick-Reference: Per-Component Checks

Cross-References

• knowledge-owasp-top-10 — Specific vulnerability categories to check for
• knowledge-secure-by-design — Architectural principles that mitigate structural threats
• knowledge-auth-patterns — Authentication/authorization threat mitigations
• knowledge-privacy-by-design — Data sensitivity classification and PII threat considerations