CIPHER 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
2. STRIDE Deep Dive
3. Data Flow Diagram Templates
4. STRIDE-per-Element Tables
5. DREAD Risk Scoring
6. Zero Trust Architecture
7. OWASP Defensive Controls by Vulnerability Class
8. Threat Model Execution Playbook
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

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
Damage	Nothing	Individual user data	Complete system compromise
Reproducibility	Very hard, race condition	Authenticated user	Anyone, any time
Exploitability	Requires custom tooling + deep knowledge	Available tools, moderate skill	Script kiddie, automated
Affected Users	None / single user	Some users / one tenant	All users / all tenants
Discoverability	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

# 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