security-threat-model

What this skill does

# Security Threat Model

## Table of Contents
1. [Workflow](#workflow)
2. [STRIDE Framework](#stride-framework)
3. [Trust Boundary Mapping](#trust-boundary-mapping)
4. [Common Patterns](#common-patterns)
5. [Guardrails](#guardrails)
6. [Quick Reference](#quick-reference)

## Workflow

Copy this checklist and track your progress:

```
Security Threat Model Progress:
- [ ] Step 1: Map system architecture and data flows
- [ ] Step 2: Identify trust boundaries
- [ ] Step 3: Classify data and compliance requirements
- [ ] Step 4: Apply STRIDE to identify threats
- [ ] Step 5: Define mitigations, monitoring, and prioritize risks
```

**Step 1: Map system architecture and data flows**

Document components, external services, users, data stores, and communication paths. See [Common Patterns](#common-patterns) for architecture examples. For straightforward systems → Use [resources/template.md](resources/template.md).

**Step 2: Identify trust boundaries**

Mark where data crosses security domains (user → server, server → database, internal → third-party). See [Trust Boundary Mapping](#trust-boundary-mapping) for boundary types.

**Step 3: Classify data and compliance requirements**

Rate data sensitivity (public, internal, confidential, restricted), identify PII/PHI/PCI, document compliance obligations (GDPR, HIPAA, PCI DSS). See [resources/template.md](resources/template.md) for classification tables.

**Step 4: Apply STRIDE to identify threats**

For each trust boundary and data flow, systematically check all six STRIDE threat categories. See [STRIDE Framework](#stride-framework) for threat identification. For complex systems with multiple attack surfaces → Study [resources/methodology.md](resources/methodology.md) for advanced attack tree analysis and DREAD scoring.

**Step 5: Define mitigations, monitoring, and prioritize risks**

Propose preventive/detective/corrective controls, establish monitoring and alerting, prioritize by risk score (likelihood × impact). Self-check using [resources/evaluators/rubric_security_threat_model.json](resources/evaluators/rubric_security_threat_model.json). Minimum standard: Average score ≥ 3.5.

## STRIDE Framework

**S - Spoofing Identity**
- **Threat**: Attacker impersonates legitimate user or system
- **Examples**: Stolen credentials, session hijacking, caller ID spoofing, email spoofing
- **Mitigations**: Multi-factor authentication, certificate validation, cryptographic signatures, mutual TLS

**T - Tampering with Data**
- **Threat**: Unauthorized modification of data in transit or at rest
- **Examples**: Man-in-the-middle attacks, SQL injection, file modification, message replay
- **Mitigations**: HTTPS/TLS, input validation, parameterized queries, digital signatures, checksums, immutable storage

**R - Repudiation**
- **Threat**: User denies performing action, no proof of activity
- **Examples**: Deleted logs, unsigned transactions, missing audit trails
- **Mitigations**: Comprehensive audit logging, digital signatures on transactions, tamper-proof logs, third-party timestamping

**I - Information Disclosure**
- **Threat**: Exposure of sensitive information to unauthorized parties
- **Examples**: Database dumps, verbose error messages, unencrypted backups, API over-fetching
- **Mitigations**: Encryption at rest/in transit, access control, data minimization, secure deletion, redaction in logs

**D - Denial of Service**
- **Threat**: System becomes unavailable or degraded
- **Examples**: Resource exhaustion, distributed attacks, algorithmic complexity exploits, storage filling
- **Mitigations**: Rate limiting, auto-scaling, circuit breakers, input size limits, CDN/DDoS protection

**E - Elevation of Privilege**
- **Threat**: Attacker gains unauthorized access or permissions
- **Examples**: SQL injection to admin, IDOR to other user data, path traversal, privilege escalation bugs
- **Mitigations**: Principle of least privilege, input validation, authorization checks on every request, role-based access control

## Trust Boundary Mapping

**Trust boundary**: Where data crosses security domains with different trust levels.

**Common boundaries:**
- **User → Application**: Untrusted input enters system (validate, sanitize, rate limit)
- **Application → Database**: Application credentials vs. user permissions (parameterized queries, connection pooling)
- **Internal → External Service**: Data leaves your control (encryption, audit logging, contract terms)
- **Public → Private Network**: Internet to internal systems (firewall, VPN, API gateway)
- **Client-side → Server-side**: JavaScript to backend (never trust client, re-validate server-side)
- **Privileged → Unprivileged Code**: Admin functions vs. user code (isolation, separate processes, security boundaries)

**Boundary analysis questions:**
- What data crosses this boundary? (classify sensitivity)
- Who/what is on each side? (authentication, authorization)
- What could go wrong at this crossing? (apply STRIDE)
- What controls protect this boundary? (authentication, encryption, validation, rate limiting)

## Common Patterns

**Pattern 1: Web Application with Database**
- **Boundaries**: User ↔ Web Server ↔ Database
- **Critical threats**: SQLi (Tampering), XSS (Spoofing), CSRF (Spoofing), session hijacking (Spoofing), IDOR (Elevation of Privilege)
- **Key mitigations**: Parameterized queries, CSP headers, CSRF tokens, HttpOnly/Secure cookies, authorization checks

**Pattern 2: API with Third-Party OAuth**
- **Boundaries**: User ↔ Frontend ↔ API Server ↔ OAuth Provider ↔ Third-Party API
- **Critical threats**: Token theft (Spoofing), scope creep (Elevation of Privilege), authorization code interception, redirect URI manipulation
- **Key mitigations**: PKCE for public clients, state parameter validation, token rotation, minimal scopes, HTTPS only

**Pattern 3: Microservices Architecture**
- **Boundaries**: API Gateway ↔ Service A ↔ Service B ↔ Message Queue ↔ Database
- **Critical threats**: Service impersonation (Spoofing), lateral movement (Elevation of Privilege), message tampering (Tampering), service enumeration (Information Disclosure)
- **Key mitigations**: mTLS between services, service mesh, API authentication per service, network policies, least privilege IAM

**Pattern 4: File Upload Service**
- **Boundaries**: User ↔ Upload Handler ↔ Virus Scanner ↔ Object Storage
- **Critical threats**: Malware upload (Tampering), path traversal (Information Disclosure), file overwrite (Tampering), storage exhaustion (DoS)
- **Key mitigations**: File type validation (magic bytes not extension), size limits, virus scanning, unique file naming, separate storage domain

**Pattern 5: Mobile App with Backend API**
- **Boundaries**: Mobile App ↔ API Gateway ↔ Backend Services
- **Critical threats**: API key extraction (Information Disclosure), certificate pinning bypass (Tampering), local data theft (Information Disclosure), reverse engineering
- **Key mitigations**: Certificate pinning, ProGuard/R8 obfuscation, biometric auth, local encryption (Keychain/Keystore), root/jailbreak detection

## Guardrails

**Assume breach mindset:**
- Don't ask "can attacker get in?" but "when attacker gets in, what damage can they do?"
- Defense in depth: Multiple overlapping controls, no single point of failure
- Least privilege: Minimal permissions by default, explicit grants only

**Prioritize realistically:**
- Focus on high-value assets (customer data, credentials, financial data) first
- Address compliance-critical threats (PCI, HIPAA) before nice-to-haves
- Balance security cost vs. risk (don't over-engineer low-risk systems)

**Avoid security theater:**
- **Security theater**: Controls that feel secure but don't meaningfully reduce risk (e.g., password complexity without rate limiting = still vulnerable to credential stuffing)
- **Effective security**: Address actual threat vectors with measurable risk reduction

**Document assumptions:**
- "Assumes database is not publicly accessible" (v