Threat Modeling

Threat Modeling Patterns

STRIDE Framework

STRIDE Analysis Template

## Component: Payment API

### Data Flow: User → POST /checkout → Payment Service → Stripe

| STRIDE | Threat | Mitigation |
|--------|--------|-----------|
| Spoofing | Attacker impersonates user | JWT with short TTL + refresh rotation |
| Tampering | Modify cart total in transit | Server-side total calculation, HTTPS |
| Repudiation | Dispute payment occurred | Immutable audit log with user_id + timestamp |
| Info Disclosure | Expose card numbers in logs | PCI DSS — never log card data, use tokens |
| DoS | Flood checkout endpoint | Rate limit: 10 req/min per user |
| EoP | User accesses another's order | Enforce user_id ownership on every DB query |

Data Flow Diagram (DFD) Elements

[External Entity] → (Process) → [Data Store]
                          ↕
                   ---- Trust Boundary ----

Example:
[Browser] → (Auth Service) → [Users DB]
                ↓ JWT
[Browser] → (API Gateway) → (Order Service) → [Orders DB]
                                   ↓
                            [Payment Service]  ← trust boundary
                                   ↓
                            [Stripe API]       ← external

Attack Trees

Goal: Steal user credentials
├── Phishing attack
│   ├── Spear phish C-level → credential harvest
│   └── Mass phish → credential stuffing
├── Brute force login
│   ├── No rate limiting → dictionary attack
│   └── Leaked password DB → credential stuffing
├── Session hijack
│   ├── XSS → steal cookie
│   ├── Network sniff (no HTTPS)
│   └── CSRF → force authenticated action
└── Server-side attack
    ├── SQL injection → dump credentials table
    └── Path traversal → read config files

Mitigations Matrix

MITIGATIONS = {
    "Spoofing": [
        "Strong authentication (MFA, passkeys)",
        "Short-lived tokens with rotation",
        "mTLS for service-to-service",
    ],
    "Tampering": [
        "Input validation + schema enforcement",
        "HTTPS everywhere (TLS 1.2+)",
        "Request signing for sensitive operations",
        "Idempotency keys for financial ops",
    ],
    "Repudiation": [
        "Append-only audit log with user_id",
        "Log all auth events with IP + user-agent",
        "Signed log entries (WORM storage)",
    ],
    "Information Disclosure": [
        "Encrypt at rest (AES-256-GCM)",
        "Minimal error messages in API responses",
        "No PII in logs or URLs",
        "Column-level encryption for sensitive fields",
    ],
    "Denial of Service": [
        "Rate limiting per user/IP",
        "Resource quotas (DB connection pool, memory)",
        "CDN + WAF for DDoS absorption",
        "Circuit breakers for downstream dependencies",
    ],
    "Elevation of Privilege": [
        "Ownership check on every resource query",
        "Role-based access control (RBAC)",
        "Principle of least privilege for service accounts",
        "Separate admin API with additional auth",
    ],
}

Threat Modeling Process

1. DECOMPOSE (What are we building?)
   - Draw data flow diagram
   - Identify trust boundaries
   - List entry points and assets

2. IDENTIFY THREATS (What can go wrong?)
   - Apply STRIDE to each data flow
   - Use attack trees for high-value assets
   - Reference past incidents and CVEs

3. RANK THREATS (How serious?)
   DREAD score (Damage, Reproducibility, Exploitability, Affected Users, Discoverability)
   Risk = Likelihood × Impact

4. MITIGATE (What do we do about it?)
   - Redesign (eliminate root cause)
   - Defend (add control)
   - Accept (document residual risk)
   - Transfer (insurance, third-party)

5. VALIDATE (Did we fix it?)
   - Security review of implemented controls
   - Penetration test high-risk areas
   - Repeat threat model when architecture changes

When to Threat Model

• New feature with user-facing auth or data handling
• Changes to trust boundaries (new external integrations)
• Changes to data sensitivity (PII, payment, health data)
• Before major releases or architecture changes
• Annually for existing high-risk components