Cybersecurity Threat Modeling

# Cybersecurity Threat Modeling

Systematic threat identification using STRIDE methodology. Map threats to mitigations before writing code.

## Overview

This skill implements the **STRIDE threat model**:

| Category | Threat | Question |
|----------|--------|----------|
| **S** — Spoofing | Identity impersonation | Can an attacker pretend to be someone else? |
| **T** — Tampering | Data modification | Can an attacker modify data in transit or at rest? |
| **R** — Repudiation | Denying actions | Can a user deny performing an action? |
| **I** — Information Disclosure | Data leaks | Can sensitive data be exposed? |
| **D** — Denial of Service | Availability attacks | Can the service be made unavailable? |
| **E** — Elevation of Privilege | Unauthorized access | Can a user gain higher privileges? |

## When to Use

- Designing a new system or feature architecture
- Before a security review of existing code
- When adding new external integrations (APIs, webhooks, OAuth)
- When handling new categories of sensitive data
- Architecture review for compliance (SOC 2, HIPAA, PCI-DSS)
- After a security incident (retrospective threat modeling)

## Step 1: Identify Assets

List what needs protection:

```markdown
## Assets Inventory

| Asset | Sensitivity | Location |
|-------|:-----------:|----------|
| User credentials | Critical | PostgreSQL (encrypted) |
| Session tokens | High | Redis / cookies |
| Payment info | Critical | Stripe (delegated) |
| User PII (email, name) | High | PostgreSQL |
| API keys | Critical | Environment variables |
| Application logs | Medium | CloudWatch |
| Static assets | Low | CDN |
```

## Step 2: Map Data Flows

Identify trust boundaries and data movement:

```markdown
## Data Flow Diagram

Browser → [TLS] → CDN → [TLS] → Load Balancer → App Server → Database
                                                  ↓
                                         [TLS] → External APIs
                                                  ↓
                                         [TLS] → Payment Provider

Trust Boundaries:
1. Browser ↔ CDN (public internet)
2. CDN ↔ App Server (internal network)
3. App Server ↔ Database (VPC)
4. App Server ↔ External APIs (public internet)
```

## Step 3: Apply STRIDE to Each Component

### Spoofing Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| Login endpoint | Credential stuffing | Rate limiting, MFA, breach detection |
| API tokens | Token theft via XSS | httpOnly cookies, CSP headers |
| Webhooks | Spoofed webhook calls | HMAC signature verification |
| OAuth | Token substitution | State parameter, PKCE flow |
| Email | Phishing with spoofed sender | DMARC, SPF, DKIM |

### Tampering Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| API requests | Parameter manipulation | Server-side validation (Zod schemas) |
| Database | Direct DB modification | RLS policies, audit triggers |
| Config files | Unauthorized config changes | Immutable infrastructure, signed configs |
| Client state | LocalStorage/cookie tampering | Server-side session validation |
| File uploads | Malicious file content | Content type validation, virus scanning |

### Repudiation Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| Admin actions | Deny performing destructive action | Immutable audit logs with user ID |
| Transactions | Deny initiating payment | Signed transaction records |
| Data changes | Deny modifying records | Database audit trail (created_by, updated_by) |
| API calls | Deny making API request | Request logging with authentication context |

### Information Disclosure Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| Error responses | Stack trace leaks | Generic error messages in production |
| API responses | Over-fetching sensitive fields | Response DTOs, field-level access control |
| Logs | PII in log files | Log sanitization, PII masking |
| Source code | Exposed .env or config | .gitignore, secret scanning, pre-commit hooks |
| Database | SQL injection data exfiltration | Parameterized queries, WAF |
| Backups | Unencrypted backup access | Encrypted backups, access controls |

### Denial of Service Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| API endpoints | Request flooding | Rate limiting, WAF, CDN |
| File uploads | Large file upload attacks | File size limits, streaming validation |
| Database | Expensive query attacks | Query timeouts, pagination limits |
| Auth endpoints | Account lockout abuse | Progressive delays, CAPTCHA |
| Webhooks | Webhook flood | Queue-based processing, deduplication |

### Elevation of Privilege Threats

| Component | Threat | Mitigation |
|-----------|--------|------------|
| User roles | Horizontal privilege escalation | Resource ownership checks on every request |
| Admin panel | Vertical privilege escalation | Role-based middleware, separate admin auth |
| API keys | Scope escalation | Least-privilege API key scopes |
| JWT claims | Token claim manipulation | Server-side claim validation, short expiry |
| File access | Path traversal | Sanitize paths, chroot, allowlist directories |

## Step 4: Risk Matrix

Prioritize threats by likelihood and impact:

```markdown
## Risk Assessment

| Threat | Likelihood | Impact | Risk Level | Priority |
|--------|:---------:|:------:|:----------:|:--------:|
| SQL injection | Medium | Critical | High | P1 |
| XSS via user content | High | High | High | P1 |
| Credential stuffing | High | High | High | P1 |
| SSRF via webhooks | Low | Critical | Medium | P2 |
| DoS on API | Medium | Medium | Medium | P2 |
| Log data exposure | Low | Medium | Low | P3 |
```

**Risk Level Formula:**
- Critical impact + High likelihood = **P1** (fix before shipping)
- Critical impact + Low likelihood = **P2** (fix within sprint)
- Medium impact + any likelihood = **P2-P3** (schedule fix)
- Low impact = **P3** (backlog)

## Step 5: M