<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->

# NERF Deep Training: Threat Modeling, Security Architecture & Zero Trust

> Synthesized from OWASP, NIST, Microsoft SDL, Google BeyondCorp, and practitioner sources.
> Training date: 2026-03-14

---

## Table of Contents

1. [Threat Modeling Methodologies](#1-threat-modeling-methodologies)
2. [STRIDE Deep Dive](#2-stride-deep-dive)
3. [Data Flow Diagram Templates](#3-data-flow-diagram-templates)
4. [STRIDE-per-Element Tables](#4-stride-per-element-tables)
5. [DREAD Risk Scoring](#5-dread-risk-scoring)
6. [Zero Trust Architecture](#6-zero-trust-architecture)
7. [OWASP Defensive Controls by Vulnerability Class](#7-owasp-defensive-controls-by-vulnerability-class)
8. [Threat Model Execution Playbook](#8-threat-model-execution-playbook)
9. [Methodology Comparison Matrix](#9-methodology-comparison-matrix)

---

## 1. Threat Modeling Methodologies

### Four Question Framework (OWASP Core)

Every threat model answers these questions regardless of methodology:

1. **What are we working on?** -- Scope, architecture, data flows, trust boundaries
2. **What can go wrong?** -- Threat identification via structured frameworks
3. **What are we going to do about it?** -- Mitigate, eliminate, transfer, or accept
4. **Did we do a good job?** -- Validation, review, testing

### Methodology Overview

| Methodology | Focus | Best For | Effort |
|---|---|---|---|
| **STRIDE** (Microsoft) | Threat classification per element | Quick assessments, web applications, developer-led | Low-Medium |
| **PASTA** | Risk-centric, attack simulation | Enterprise risk programs, CTI integration | Very High |
| **LINDDUN** | Privacy threats | Healthcare, finance, GDPR-regulated systems | Medium |
| **VAST** | Scalable, automation-first | CI/CD pipelines, DevSecOps | Low |
| **OCTAVE Allegro** | Organizational risk | Broad risk management programs | Medium-High |
| **Trike** | Quantitative, deterministic | Well-defined state machines, repeatable output | High |
| **NIST 800-154** | Data-centric | Data protection, regulatory compliance | Medium |

### PASTA: Seven Stages

1. Define business objectives
2. Define technical scope
3. Application decomposition (DFDs, asset inventory)
4. Threat analysis (integrate cyber threat intelligence)
5. Vulnerability and weakness analysis (CVE, CWE mapping)
6. Attack modeling (attack trees, MITRE ATT&CK)
7. Risk and impact analysis (business impact quantification)

### LINDDUN: Seven Privacy Threat Categories

| Threat | Opposite Property | Example |
|---|---|---|
| Linkability | Unlinkability | Correlating pseudonymous records across datasets |
| Identifiability | Anonymity | De-anonymizing users from metadata |
| Non-repudiation | Plausible deniability | Proving user performed action they deny |
| Detectability | Undetectability | Discovering existence of hidden records |
| Disclosure of information | Confidentiality | Unauthorized access to personal data |
| Unawareness | Content awareness | User unaware of data collection scope |
| Non-compliance | Policy compliance | Processing data beyond stated purpose |

### Microsoft SDL Threat Modeling Process

1. Define security requirements
2. Create data flow diagrams
3. Identify threats using STRIDE-per-Element
4. Mitigate through risk treatment (mitigate/eliminate/transfer/accept)
5. Validate mitigation effectiveness

---

## 2. STRIDE Deep Dive

### Category Definitions

| Category | Violated Property | Definition | Attack Pattern |
|---|---|---|---|
| **Spoofing** | Authentication | Impersonating another entity (user, service, system) | Credential theft, token replay, ARP spoofing, DNS hijacking |
| **Tampering** | Integrity | Unauthorized modification of data or code | SQL injection, MITM modification, binary patching, config tampering |
| **Repudiation** | Non-repudiation | Denying an action without ability to prove otherwise | Log deletion, unsigned transactions, missing audit trail |
| **Information Disclosure** | Confidentiality | Exposing data to unauthorized parties | Path traversal, error messages leaking internals, side-channel attacks |
| **Denial of Service** | Availability | Making a resource unavailable to legitimate users | Resource exhaustion, amplification attacks, account lockout abuse |
| **Elevation of Privilege** | Authorization | Gaining capabilities beyond what is granted | JWT tampering, IDOR, kernel exploits, role manipulation |

### STRIDE Threat Examples by Component Type

#### External Entities (Users, External Systems)
| Threat | Example |
|---|---|
| Spoofing | Attacker impersonates legitimate user with stolen OAuth token |
| Repudiation | User denies initiating a financial transaction |

#### Processes (Application Logic)
| Threat | Example |
|---|---|
| Spoofing | Rogue process impersonates legitimate service |
| Tampering | Code injection modifies runtime behavior |
| Repudiation | Process fails to log critical operations |
| Information Disclosure | Debug endpoint exposes internal state |
| Denial of Service | Algorithmic complexity attack (ReDoS) |
| Elevation of Privilege | Deserialization vulnerability grants code execution |

#### Data Stores (Databases, Files, Caches)
| Threat | Example |
|---|---|
| Tampering | Direct database modification bypassing application logic |
| Repudiation | No audit log on data modifications |
| Information Disclosure | Unencrypted backup exposed on public storage |
| Denial of Service | Table lock via long-running query |

#### Data Flows (Network Connections, API Calls)
| Threat | Example |
|---|---|
| Tampering | MITM modifies API response in transit |
| Information Disclosure | Cleartext transmission of credentials |
| Denial of Service | SYN flood on exposed endpoint |

---

## 3. Data Flow Diagram Templates

### DFD Elements

| Element | Symbol | Description |
|---|---|---|
| External Entity | Rectangle | Users, external systems, third-party services outside trust boundary |
| Process | Circle/Rounded rect | Application logic, services, functions that transform data |
| Data Store | Parallel lines | Databases, files, caches, queues |
| Data Flow | Arrow | Data movement between elements (label with protocol + data type) |
| Trust Boundary | Dashed line | Separation between zones of different trust levels |

### Template: Three-Tier Web Application

```
                    TRUST BOUNDARY: Internet
   +-----------+         |
   |  Browser  |--- HTTPS/TLS --->|
   | (External)|         |        |
   +-----------+         |        v
                         |   +----------+     TRUST BOUNDARY: DMZ/App Tier
                         |   |  WAF /   |         |
                         |   |  LB      |-------->|
                         |   +----------+         |
                         |                        v
                         |                  +-----------+
                         |                  | Web App   |
                         |                  | (Process) |
                         |                  +-----------+
                         |                        |
                         |        TRUST BOUNDARY: Data Tier
                         |                        |
                         |                        v
                         |                  +===========+
                         |                  | Database  |
                         |                  | (Store)   |
                         |                  +===========+
```

### Template: Microservices Architecture

```
   +----------+       TRUST BOUNDARY: Edge
   | Mobile   |--TLS-->|
   | Client   |        |   +-----------+
   +----------+        |   | API       |
                       |   | Gateway   |
   +----------+        |   | (Process) |
   | Web SPA  |--TLS-->|   +-----------+
   +----------+        |        |
                       |   TRUST BOUNDARY: Service Mesh
                       |        |
                       |   +----+-----+------+
                       |   |          |      |
                       |   v          v      v
                       | +------+ +------+ +------+
                       | |Svc A | |Svc B | |Svc C |
                       | +------+ +------+ +------+
                       |   |          |      |
                       |   TRUST BOUNDARY: Data Layer
                       |   |          |      |
                       |   v          v      v
                       | +====+ +======+ +=====+
                       | | DB | | Cache| |Queue|
                       | +====+ +======+ +=====+
                       |
                       |   TRUST BOUNDARY: External Services
                       |        |
                       |        v
                       |   +----------+
                       |   | 3rd Party|
                       |   | API      |
                       |   +----------+
```

### Template: Mermaid DFD Syntax

```mermaid
graph LR
    subgraph "Trust Boundary: Internet"
        User["fa:fa-user User (External Entity)"]
    end

    subgraph "Trust Boundary: DMZ"
        LB["Load Balancer"]
        WAF["WAF"]
    end

    subgraph "Trust Boundary: Application Tier"
        API["API Server (Process)"]
        AuthN["AuthN Service (Process)"]
    end

    subgraph "Trust Boundary: Data Tier"
        DB[("Database (Store)")]
        Cache[("Redis Cache (Store)")]
        Vault["Secrets Vault (Store)"]
    end

    User -->|"HTTPS/TLS"| WAF
    WAF --> LB
    LB --> API
    API -->|"mTLS"| AuthN
    API -->|"TLS"| DB
    API -->|"TLS"| Cache
    AuthN -->|"TLS"| Vault
```

---

## 4. STRIDE-per-Element Tables

### Complete STRIDE Analysis Template

Use one table per trust boundary crossing or critical component.

#### Web Application (Process)

| # | Threat Category | Threat Description | Likelihood | Impact | Risk | Mitigation | Status |
|---|---|---|---|---|---|---|---|
| T-01 | Spoofing | Attacker forges session token to impersonate authenticated user | High | High | Critical | Cryptographically signed tokens (HMAC-SHA256+), short expiry, rotation | Open |
| T-02 | Tampering | Attacker modifies request body to alter business logic | High | High | Critical | Server-side input validation, integrity checks, parameterized queries | Open |
| T-03 | Repudiation | User denies performing a destructive action | Medium | Medium | Medium | Comprehensive audit logging with tamper-evident storage | Open |
| T-04 | Info Disclosure | Stack traces or debug info exposed in error responses | Medium | High | High | Custom error handler, suppress stack traces in production | Open |
| T-05 | DoS | Algorithmic complexity attack via crafted input (ReDoS, HashDoS) | Medium | High | High | Input length limits, safe regex patterns, rate limiting | Open |
| T-06 | EoP | IDOR allows horizontal privilege escalation to other users' data | High | Critical | Critical | Object-level authorization checks on every request | Open |

#### Database (Data Store)

| # | Threat Category | Threat Description | Likelihood | Impact | Risk | Mitigation | Status |
|---|---|---|---|---|---|---|---|
| T-07 | Tampering | Direct DB access bypasses application authorization | Low | Critical | High | Network segmentation, DB firewall, least-privilege DB accounts | Open |
| T-08 | Info Disclosure | Unencrypted data at rest exposed via backup theft | Medium | Critical | Critical | AES-256-GCM encryption at rest, encrypted backups, key rotation | Open |
| T-09 | DoS | Long-running query locks tables | Medium | Medium | Medium | Query timeouts, connection pool limits, read replicas | Open |
| T-10 | Repudiation | No audit trail for data modifications | Medium | High | High | Database audit logging, change data capture | Open |

#### API Data Flow (HTTPS)

| # | Threat Category | Threat Description | Likelihood | Impact | Risk | Mitigation | Status |
|---|---|---|---|---|---|---|---|
| T-11 | Tampering | MITM modifies API responses | Low (with TLS) | High | Medium | TLS 1.3, certificate pinning, HSTS | Open |
| T-12 | Info Disclosure | Sensitive data exposed in URL query parameters | Medium | High | High | Use POST body or headers for sensitive data, never URL params | Open |
| T-13 | DoS | SYN flood or amplification attack on public endpoint | High | High | High | CDN, rate limiting, SYN cookies, auto-scaling | Open |

---

## 5. DREAD Risk Scoring

### Scoring Criteria

| Factor | Score 0 | Score 5 | Score 10 |
|---|---|---|---|
| **D**amage | Nothing | Individual user data | Complete system compromise |
| **R**eproducibility | Very hard, race condition | Authenticated user | Anyone, any time |
| **E**xploitability | Requires custom tooling + deep knowledge | Available tools, moderate skill | Script kiddie, automated |
| **A**ffected Users | None / single user | Some users / one tenant | All users / all tenants |
| **D**iscoverability | Requires source code access + deep analysis | Guessable / inferable | Publicly known / obvious |

**Risk = (D + R + E + A + D) / 5**

| Range | Rating |
|---|---|
| 0-3 | Low |
| 4-6 | Medium |
| 7-8 | High |
| 9-10 | Critical |

### Example DREAD Scoring

| Threat | D | R | E | A | D | Score | Rating |
|---|---|---|---|---|---|---|---|
| SQL Injection in login form | 10 | 10 | 8 | 10 | 9 | **9.4** | Critical |
| IDOR in user profile API | 7 | 10 | 7 | 8 | 7 | **7.8** | High |
| ReDoS in search field | 5 | 8 | 6 | 10 | 4 | **6.6** | Medium |
| Missing CSRF token | 6 | 8 | 5 | 5 | 5 | **5.8** | Medium |

---

## 6. Zero Trust Architecture

### NIST SP 800-207 Core Tenets

1. **All data sources and computing services are considered resources** -- not just servers; includes SaaS, IoT, personal devices
2. **All communication is secured regardless of network location** -- internal network does not imply trust; encrypt and authenticate everything
3. **Access to individual enterprise resources is granted on a per-session basis** -- no persistent access; re-evaluate trust for each request
4. **Access is determined by dynamic policy** -- including client identity, application/service, requesting asset state, behavioral and environmental attributes
5. **Enterprise monitors and measures integrity and security posture of all owned and associated assets** -- continuous monitoring, not point-in-time
6. **All resource authentication and authorization are dynamic and strictly enforced before access is allowed** -- constant re-evaluation of trust
7. **Enterprise collects as much information as possible about current state of assets, network infrastructure, and communications** -- used to improve security posture

### Zero Trust Logical Components

```
+------------------------------------------------------------------+
|                     POLICY DECISION POINT (PDP)                   |
|  +-------------------+    +-------------------+                   |
|  | Policy Engine     |    | Policy Admin      |                   |
|  | (Decision logic)  |<-->| (Session control)  |                  |
|  +-------------------+    +-------------------+                   |
+------------------------------------------------------------------+
          ^                           |
          | Trust evaluation          | Grant/Deny/Revoke
          |                           v
+-------------------+       +-------------------+
| CDM System        |       | Policy Enforcement|
| (Device health)   |       | Point (PEP)       |
+-------------------+       +-------------------+
                                     |
+-------------------+                | Permitted data flow
| Threat Intel      |                v
| (External feeds)  |       +-------------------+
+-------------------+       | Enterprise        |
                            | Resource          |
+-------------------+       +-------------------+
| Identity Provider |
| (IdP / MFA)       |
+-------------------+

+-------------------+
| SIEM / Analytics  |
| (Continuous       |
|  monitoring)      |
+-------------------+
```

### Zero Trust Deployment Models

| Model | Description | Use Case |
|---|---|---|
| **Device Agent / Gateway** | Agent on device communicates with gateway before accessing resource | Enterprise-managed endpoints |
| **Enclave-based** | Gateway protects enclave of resources; no agent on device | Legacy systems, BYOD |
| **Resource Portal** | PEP acts as web portal for all resource access | Web applications, SaaS |
| **Device Application Sandboxing** | Trusted apps on device communicate through secure channel | High-security environments |

### Google BeyondCorp Principles

Google's BeyondCorp implementation operationalizes zero trust through:

1. **Access depends on device and user credentials, not network** -- connecting from office LAN grants no additional trust
2. **All access to services is authenticated, authorized, and encrypted** -- no difference between internal and external access
3. **Access is granted on a per-request basis** -- continuous evaluation via access proxy
4. **Device inventory and health** -- every device tracked, health state factors into access decisions
5. **No VPN required** -- all services accessible from any network through access proxy

### Zero Trust Implementation Checklist

```
[ ] Identify all resources (data, services, devices, infrastructure)
[ ] Map all data flows and access patterns
[ ] Implement strong identity for all users (MFA mandatory)
[ ] Implement device identity and health attestation
[ ] Segment network by resource, not by location
[ ] Enforce least-privilege access per request
[ ] Encrypt all communications (mTLS between services)
[ ] Deploy Policy Decision Point (PDP) + Policy Enforcement Point (PEP)
[ ] Integrate continuous monitoring and analytics
[ ] Implement dynamic trust scoring (device health + user behavior + context)
[ ] Log all access decisions for audit and anomaly detection
[ ] Plan for graceful degradation when PDP is unavailable
[ ] Test with assume-breach scenarios
```

---

## 7. OWASP Defensive Controls by Vulnerability Class

### Authentication Vulnerabilities

**Threats**: Credential stuffing, brute force, session hijacking, phishing

| Control | Implementation | OWASP Reference |
|---|---|---|
| Password policy | Min 8 chars with MFA, 15 without; max 64+; no composition rules; block breached passwords via HIBP | Authentication CS |
| MFA enforcement | FIDO2/WebAuthn preferred; TOTP acceptable; SMS as last resort | Authentication CS |
| Credential storage | bcrypt/scrypt/Argon2id with appropriate work factor; never MD5/SHA1 | Password Storage CS |
| Account lockout | Exponential backoff (1s, 2s, 4s...); count per account not IP; permanent lock after N lockout events | Authentication CS |
| Session management | Cryptographically random IDs; server-side storage; regenerate on auth state change | Session Mgmt CS |
| Generic error messages | "Login failed; Invalid user ID or password" -- never reveal which field is wrong | Authentication CS |
| Adaptive authentication | Risk-based step-up: new device/location/behavior triggers additional verification | Authentication CS |

### Authorization Vulnerabilities

**Threats**: IDOR, privilege escalation (horizontal + vertical), missing function-level access control

| Control | Implementation | OWASP Reference |
|---|---|---|
| Deny by default | Explicit allow required; never rely on framework defaults | Authorization CS |
| Server-side enforcement | All authz checks server-side; client-side is UX only | Authorization CS |
| Per-request validation | Check permissions on every request including AJAX, API, WebSocket | Authorization CS |
| Object-level checks | Verify user owns/has access to specific resource instance, not just resource type | Authorization CS |
| Prefer ABAC/ReBAC over RBAC | RBAC leads to role explosion; ABAC provides fine-grained, context-aware decisions | Authorization CS |
| Indirect references | Map internal IDs to per-user/per-session indirect references | Authorization CS |
| Centralized enforcement | Use middleware/filters (Django middleware, Spring Security, .NET Core filters) | Authorization CS |

### Input Validation Vulnerabilities

**Threats**: Injection (SQL, NoSQL, LDAP, OS command, XSS), buffer overflow, path traversal

| Control | Implementation | OWASP Reference |
|---|---|---|
| Allowlist validation | Define what IS authorized; reject everything else | Input Validation CS |
| Syntactic + semantic | Format correctness (syntactic) AND business logic correctness (semantic) | Input Validation CS |
| Server-side mandatory | Client-side is UX convenience only; all validation repeated server-side | Input Validation CS |
| Type + range + length | Strong typing, numerical ranges, string length limits | Input Validation CS |
| Output encoding | Context-specific encoding (HTML entities, JS encoding, URL encoding) on all output | Input Validation CS |
| Parameterized queries | Never concatenate user input into queries; use prepared statements | Query Parameterization CS |
| File upload controls | Extension allowlist, max size, random rename, content-type verification, image rewriting | Input Validation CS |

### Cryptographic Storage Vulnerabilities

**Threats**: Data exposure from breach, weak encryption, key compromise

| Control | Implementation | OWASP Reference |
|---|---|---|
| Algorithm selection | AES-256-GCM (symmetric); Curve25519 or RSA-2048+ (asymmetric) | Crypto Storage CS |
| Authenticated encryption | GCM or CCM mode; if unavailable, CTR/CBC + Encrypt-then-MAC | Crypto Storage CS |
| CSPRNG | `secrets` (Python), `crypto.randomBytes` (Node), `SecureRandom` (Java) | Crypto Storage CS |
| Key separation | DEK encrypts data; KEK encrypts DEK; store KEK separately from data | Crypto Storage CS |
| HSM / Key Vault | AWS KMS, Azure Key Vault, HashiCorp Vault; never hardcode keys | Crypto Storage CS |
| Minimize storage | Best protection: don't store sensitive data you don't need | Crypto Storage CS |
| Defense in depth | Encryption + access controls + network segmentation; never rely on crypto alone | Crypto Storage CS |

### Key Management Vulnerabilities

**Threats**: Key theft, weak key generation, key reuse, missing rotation

| Control | Implementation | OWASP Reference |
|---|---|---|
| FIPS-validated generation | Generate within FIPS 140-2/140-3 certified modules | Key Mgmt CS |
| Single-purpose keys | One key per function: encryption, signing, key wrapping, authentication | Key Mgmt CS |
| Secure storage | HSM or isolated cryptographic service; never unencrypted at rest | Key Mgmt CS |
| Rotation | On suspected compromise, staff departure, cryptoperiod expiry, algorithm vulnerability | Key Mgmt CS |
| Key hierarchy | Master key -> KEK -> DEK; rotate KEK without re-encrypting all data | Key Mgmt CS |
| Compromise recovery | Documented plan: notification contacts, re-keying method, key inventory, revocation enforcement | Key Mgmt CS |
| Audit trail | Track all individuals with plaintext key access; regular compliance audits | Key Mgmt CS |

### Secrets Management Vulnerabilities

**Threats**: Hardcoded credentials, secret sprawl, missing rotation, CI/CD exposure

| Control | Implementation | OWASP Reference |
|---|---|---|
| Centralized vault | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager | Secrets Mgmt CS |
| Automated rotation | Lambda functions, Kubernetes sidecars, vault-native rotation; eliminate manual processes | Secrets Mgmt CS |
| Least privilege access | Per-secret access policies; engineers access only secrets they need | Secrets Mgmt CS |
| No env vars for secrets | Visible to all child processes, logged in /proc; use mounted secrets or sidecar injection | Secrets Mgmt CS |
| CI/CD hardening | Platform vaults (GitHub Secrets, GitLab CI vars); integrate with external vault; treat pipelines as production | Secrets Mgmt CS |
| Audit everything | Who accessed what, when, success/failure; alert on anomalous patterns | Secrets Mgmt CS |
| Incident response | Pre-built runbook for immediate revocation; document secret dependencies and ownership | Secrets Mgmt CS |

### Security Logging Vulnerabilities

**Threats**: Insufficient logging, log injection, log tampering, privacy violations in logs

| Control | Implementation | OWASP Reference |
|---|---|---|
| Security events to log | AuthN success/failure, AuthZ failures, input validation failures, session failures, admin actions, crypto key usage | Logging CS |
| Never log | Passwords, tokens, session IDs, PII (SSN, health data), encryption keys, card numbers, connection strings | Logging CS |
| Log attributes | When (UTC timestamp), Where (service/host/IP), Who (authenticated identity), What (event type, severity, result) | Logging CS |
| Tamper detection | Write-once storage, integrity hashing, separate partition, restricted access | Logging CS |
| Log injection prevention | Sanitize CR/LF/delimiters; validate event data from other trust zones; encode for output format | Logging CS |
| Centralized collection | SIEM/SEM integration; real-time alerting; incident response integration | Logging CS |
| Time synchronization | NTP across all systems; consistent timezone (UTC preferred) | Logging CS |
| Prevent DoS via logging | Disk quotas, log rotation, separate partition; logging failure must not crash application | Logging CS |

---

## 8. Threat Model Execution Playbook

### Phase 1: Scope and Decompose (Day 1)

```
1. Define scope boundary
   - What system/feature/change is being modeled?
   - What is in scope vs. out of scope?
   - What are the security requirements?

2. Identify assets
   - Data classifications (public, internal, confidential, restricted)
   - Critical processes and services
   - External dependencies

3. Build DFD
   - Identify all external entities
   - Map all processes and data stores
   - Draw all data flows with protocol and data type labels
   - Mark trust boundaries (every privilege transition)
   - Tool: OWASP Threat Dragon, draw.io, or pytm
```

### Phase 2: Identify Threats (Day 2)

```
4. Apply STRIDE-per-Element
   - Walk each DFD element
   - For each element, evaluate applicable STRIDE categories
   - Document each threat with: ID, category, description, affected element

5. Cross-reference with attack libraries
   - MITRE ATT&CK for relevant TTPs
   - CAPEC for attack patterns
   - OWASP Top 10 for common web vulnerabilities
   - CWE for weakness classification
```

### Phase 3: Risk Assessment and Mitigation (Day 3)

```
6. Score each threat
   - DREAD scoring for internal prioritization
   - CVSS for external communication
   - Map to business impact (data breach cost, downtime cost, regulatory fines)

7. Select response for each threat
   - MITIGATE: implement specific control (document what and where)
   - ELIMINATE: remove the feature/flow that creates the threat
   - TRANSFER: insurance, SLA, third-party responsibility
   - ACCEPT: document risk acceptance with business owner sign-off

8. Define mitigations
   - Specific, actionable, testable
   - Assigned to owner with deadline
   - Mapped to OWASP control (see Section 7)
```

### Phase 4: Validate and Maintain

```
9. Review
   - Stakeholders verify DFD accuracy
   - Security team validates threat completeness
   - Test team creates security test cases from threats
   - Document assumptions and residual risk

10. Maintain
    - Update on: new features, architecture changes, security incidents
    - Integrate into CI/CD: pytm or Threatspec for threat-model-as-code
    - Review at minimum annually or on significant change
```

### Threat Model Document Template

```markdown
# Threat Model: [System Name]
**Version**: [X.Y]
**Date**: [YYYY-MM-DD]
**Author**: [Name]
**Reviewers**: [Names]
**Status**: Draft | In Review | Approved

## 1. System Description
[Brief description of what the system does and why it exists]

## 2. Scope
- **In scope**: [components, features, data flows]
- **Out of scope**: [what is explicitly excluded]
- **Assumptions**: [security assumptions being made]

## 3. Data Classification
| Data Type | Classification | Regulatory | Storage Location |
|---|---|---|---|
| User credentials | Restricted | N/A | Auth DB |
| PII (name, email) | Confidential | GDPR Art. 5 | User DB |
| Audit logs | Internal | SOX, PCI | Log store |

## 4. Data Flow Diagram
[Mermaid or image reference]

## 5. Trust Boundaries
| Boundary | From | To | Controls |
|---|---|---|---|
| TB-1 | Internet | DMZ | WAF, TLS termination |
| TB-2 | DMZ | App Tier | mTLS, network policy |
| TB-3 | App Tier | Data Tier | DB firewall, least-privilege accounts |

## 6. STRIDE Analysis
[STRIDE-per-Element tables from Section 4]

## 7. Risk Assessment
[DREAD scores or CVSS for each threat]

## 8. Mitigations
| Threat ID | Mitigation | Owner | Deadline | Status |
|---|---|---|---|---|
| T-01 | Implement signed JWT with 15min expiry | Auth team | Q2 | In Progress |

## 9. Residual Risk
[Accepted risks with business owner approval]

## 10. Review Schedule
- Next review: [date]
- Triggers for ad-hoc review: [list]
```

---

## 9. Methodology Comparison Matrix

### Decision Framework

```
START
  |
  v
Is this a privacy-focused system? ---YES---> LINDDUN (+ STRIDE for security)
  |
  NO
  |
  v
Do you need enterprise risk quantification? ---YES---> PASTA
  |
  NO
  |
  v
Is this integrated into CI/CD pipeline? ---YES---> VAST (or pytm for code-based)
  |
  NO
  |
  v
Is the system well-defined with clear state? ---YES---> Trike
  |
  NO
  |
  v
Is this a regulatory/data-protection focus? ---YES---> NIST 800-154
  |
  NO
  |
  v
DEFAULT ---> Microsoft STRIDE (most widely understood, lowest barrier)
```

### Supporting Frameworks for All Methodologies

| Category | Framework | Purpose |
|---|---|---|
| Control mapping | NIST CSF, CIS Controls, ISO 27001, OWASP ASVS | Map mitigations to established controls |
| Attack knowledge | MITRE ATT&CK, CAPEC | Enumerate attack techniques and patterns |
| Weakness taxonomy | CWE | Classify underlying weaknesses |
| Vulnerability scoring | CVSS, DREAD, FAIR | Quantify risk for prioritization |
| Vulnerability database | CVE, NVD | Known vulnerability lookup |

### Tool Recommendations

| Tool | Type | Best For |
|---|---|---|
| OWASP Threat Dragon | GUI, open source | Visual DFD + STRIDE |
| Microsoft TMT | GUI, free | Windows, STRIDE-per-Element |
| OWASP pytm | Code (Python) | Threat-model-as-code, CI/CD integration |
| IriusRisk | Commercial | Enterprise, compliance mapping |
| draw.io | GUI, free | General-purpose DFD creation |
| Threatspec | Code annotations | Inline threat documentation |

---

## Appendix A: STRIDE Mitigation Quick Reference

| STRIDE Category | Primary Mitigations |
|---|---|
| **Spoofing** | Strong authentication (MFA/FIDO2), mutual TLS, certificate pinning, token signing |
| **Tampering** | Input validation, parameterized queries, code signing, integrity checks (HMAC/digital signatures), immutable infrastructure |
| **Repudiation** | Comprehensive audit logging, tamper-evident log storage, digital signatures on transactions, NTP synchronization |
| **Information Disclosure** | Encryption (at rest: AES-256-GCM, in transit: TLS 1.3), access controls, data minimization, error handling (no stack traces) |
| **Denial of Service** | Rate limiting, auto-scaling, input size limits, circuit breakers, CDN, resource quotas |
| **Elevation of Privilege** | Least privilege, RBAC/ABAC, per-request authorization, sandboxing, capability-based security, secure deserialization |

## Appendix B: Trust Boundary Checklist

For every trust boundary crossing, verify:

```
[ ] Authentication: Is the caller's identity verified?
[ ] Authorization: Is the caller permitted this specific action on this specific resource?
[ ] Input validation: Is all data from the less-trusted zone validated?
[ ] Output encoding: Is data encoded appropriately for the target context?
[ ] Encryption: Is data encrypted in transit across this boundary?
[ ] Rate limiting: Are requests from the less-trusted zone rate limited?
[ ] Logging: Are all cross-boundary requests logged with sufficient detail?
[ ] Error handling: Do errors from the more-trusted zone leak internal details?
```

## Appendix C: NIST 800-207 Zero Trust Maturity Indicators

| Level | Characteristics |
|---|---|
| **Traditional** | Perimeter-based, VPN access, static firewall rules, implicit trust for internal traffic |
| **Initial** | Some micro-segmentation, MFA for remote access, identity-aware proxy for select apps |
| **Advanced** | All access via PEP, dynamic policy based on device health + user behavior, encrypted east-west traffic |
| **Optimal** | Continuous verification, real-time risk scoring, automated response, full asset visibility, assume-breach posture |

---

*Sources: OWASP Threat Modeling, OWASP Cheat Sheet Series (Threat Modeling, Authentication, Authorization, Cryptographic Storage, Key Management, Logging, Input Validation, Secrets Management), NIST SP 800-207, Microsoft SDL Threat Modeling Tool, Google BeyondCorp, Shellsharks Threat Modeling Methodology Comparison, OWASP Threat Model Cookbook*
