gh-lyndonkl-claude/skills/security-threat-model/resources/methodology.md

Security Threat Model: Advanced Methodologies

Table of Contents

1. Attack Trees & Attack Graphs
2. DREAD Risk Scoring
3. Abuse Cases & Misuse Stories
4. Data Flow Diagrams (DFD) for Threat Modeling
5. Threat Intelligence Integration
6. Advanced STRIDE Patterns

1. Attack Trees & Attack Graphs

Attack Tree Construction

Attack tree: Hierarchical diagram showing how security goals can be defeated through combinations of attacks.

Structure:

• Root (top): Attacker's goal (e.g., "Steal customer credit card data")
• Nodes: Sub-goals or attack steps
• Leaves (bottom): Atomic attacks (individual exploits)
• AND nodes: All child attacks must succeed (serial gates)
• OR nodes: Any child attack succeeds (parallel gates)

Example (Steal Credit Card Data):

[Steal CC Data] (ROOT - OR)
├── [Compromise Database] (AND)
│   ├── [Gain network access] (OR)
│   │   ├── Phish employee for VPN creds
│   │   └── Exploit public-facing vulnerability
│   └── [Escalate privileges to DBA] (OR)
│       ├── SQL injection → shell → lateral movement
│       └── Steal DB credentials from secrets file
├── [Intercept in Transit] (AND)
│   ├── [MITM between user and server] (OR)
│   │   ├── Compromise WiFi router
│   │   └── BGP hijacking (sophisticated)
│   └── [Decrypt TLS] (OR)
│       ├── Steal server private key
│       └── Downgrade to weak cipher (if supported)
└── [Social Engineering] (OR)
    ├── Phish customer directly for CC
    └── Compromise customer support → access CC vault

Leaf Attack Attributes:

• Difficulty: Low (script kiddie), Medium (skilled attacker), High (APT)
• Cost: $0-100, $100-10K, $10K+ (attacker resources)
• Detection Likelihood: Low (0-30%), Medium (30-70%), High (70-100%)
• Impact: If this leaf succeeds, what's compromised?

Analysis:

• Most likely path: Lowest combined difficulty + cost
• Stealthiest path: Lowest combined detection likelihood
• Critical leaves: Appear in multiple paths (defend these first)

Mitigation Strategy:

• Prune OR nodes: Block at least one child (breaks that path)
• Strengthen AND nodes: Make any one child infeasible (breaks entire branch)
• Monitor leaves: Add detection at leaf level (early warning)

Attack Graph Analysis

Attack graph: Network-level visualization showing how attacker moves laterally.

Components:

• Nodes: Network hosts (web server, DB, workstation)
• Edges: Exploits that allow movement between nodes
• Entry points: Internet-facing hosts (start nodes)
• Crown jewels: High-value targets (end nodes)

Example:

[Internet] → [Web Server] (SQLi) → [App Server] (lateral via shared subnet)
                                         ↓
                            [Database] (DB creds in config file)

Path Analysis:

• Shortest path: Fewest hops to crown jewels
• Easiest path: Lowest aggregate difficulty
• Most likely path: Attacker's expected route (probability-weighted)

Mitigations:

• Network segmentation: Break edges (VLANs, security groups, air gaps)
• Least privilege: Reduce accessible edges from each node
• Defense in depth: Require multiple successful exploits per path

2. DREAD Risk Scoring

DREAD: Microsoft's risk scoring model for prioritizing threats.

Scoring Criteria (1-10 scale)

D - Damage Potential

• 1-3: Minor impact (single user affected, limited data)
• 4-7: Significant impact (many users, sensitive data)
• 8-10: Catastrophic (all users, regulated data breach, life-safety)

R - Reproducibility

• 1-3: Hard to reproduce (race condition, specific timing)
• 4-7: Moderate (requires specific configuration, some skill)
• 8-10: Trivial (works every time, no special conditions)

E - Exploitability

• 1-3: Very difficult (requires custom exploit, deep expertise)
• 4-7: Moderate (exploit code available, requires adaptation)
• 8-10: Trivial (point-and-click tool, no skill needed)

A - Affected Users

• 1-3: Minimal (single user, admin only, specific config)
• 4-7: Moderate (some users, default install, optional feature)
• 8-10: All users (default config, core functionality)

D - Discoverability

• 1-3: Obscure (requires source code audit, specific knowledge)
• 4-7: Moderate (found through scanning, disclosed vulnerability)
• 8-10: Obvious (visible in UI, publicly documented, automated scanners find it)

Calculating DREAD Score

Formula: (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) / 5

Example (SQL Injection in Login Form):

• Damage: 10 (full database access, PII breach)
• Reproducibility: 10 (always works with same payload)
• Exploitability: 8 (SQLMap automates it, some skill needed)
• Affected Users: 10 (all users, login is core functionality)
• Discoverability: 9 (login forms are obvious attack surface, scanners find it)
• DREAD Score: (10+10+8+10+9)/5 = 9.4 (Critical)

Example (Admin API without rate limiting):

• Damage: 7 (can enumerate accounts, some PII)
• Reproducibility: 10 (always works)
• Exploitability: 10 (trivial, just send requests)
• Affected Users: 6 (admin API, limited exposure)
• Discoverability: 5 (requires knowledge of API endpoint, not in public docs)
• DREAD Score: (7+10+10+6+5)/5 = 7.6 (High)

Using DREAD for Prioritization

Thresholds:

• 9.0-10.0: Critical (P0, fix immediately)
• 7.0-8.9: High (P1, fix this sprint)
• 5.0-6.9: Medium (P2, backlog priority)
• 3.0-4.9: Low (P3, monitor, accept risk)
• 1.0-2.9: Minimal (P4, informational)

Advantages:

• Quantitative scoring aids prioritization
• Granular (1-10 scale) vs. coarse (Low/Med/High)
• Factors in exploitability and discoverability (not just impact)

Limitations:

• Subjective (scorers may disagree)
• Doesn't account for existing mitigations (score pre-mitigation threat)
• "Discoverability" less relevant in post-disclosure world (assume all vulns are known)

3. Abuse Cases & Misuse Stories

Abuse Cases

Abuse case: Scenario where functionality is misused for malicious purposes (not a bug, feature used as weapon).

Structure:

• Actor: Who abuses (insider, competitor, attacker)
• Goal: What they want (exfiltrate data, disrupt service, frame someone)
• Preconditions: What they need (account, network access, knowledge)
• Steps: How they abuse the feature
• Result: What damage occurs
• Mitigation: How to detect or prevent

Example (Bulk Data Export Feature):

Abuse Case: Insider data exfiltration

• Actor: Disgruntled employee with valid credentials
• Goal: Steal entire customer database before leaving company
• Preconditions: Login access, export feature available to all users
• Steps:
  1. Log in with legitimate credentials
  2. Navigate to export page
  3. Select "All customers" (no pagination limit)
  4. Click "Export to CSV"
  5. Download 10M customer records
  6. Upload to competitor or dark web
• Result: Massive data breach, GDPR violation, competitive damage
• Mitigation:
  • Detective: Audit log for large exports, alert on exports >1000 records
  • Preventive: Require manager approval for exports >100 records
  • Corrective: Watermark exports with user ID (attribution), DLP to prevent upload

Misuse Stories (Agile Format)

Misuse story: Agile user story from attacker's perspective.

Format: "As a [attacker type], I want to [malicious action], so that I can [attacker goal]"

Example:

• "As a script kiddie, I want to enumerate valid usernames through password reset, so that I can target credential stuffing attacks"
  • Mitigation: Generic error messages ("If that email exists, we sent a reset link"), rate limiting
• "As a competitor, I want to scrape all product prices and descriptions, so that I can undercut pricing"
  • Mitigation: Rate limiting, CAPTCHA, robots.txt, legal terms of service, API authentication
• "As a disgruntled ex-employee, I want to use my old credentials that weren't revoked, so that I can delete critical data for revenge"
  • Mitigation: Offboarding checklist (revoke all access day 1), audit logs, backups, immutable delete (soft delete with retention)

Misuse Case Matrix

Feature	Legitimate Use	Misuse	Mitigation
Search	Find products	Enumerate database, injection testing	Rate limiting, parameterized queries, no PII in results
File upload	Share documents	Malware upload, path traversal, storage DoS	File type validation (magic bytes), size limits, virus scan, separate domain
Admin panel	Manage system	Privilege escalation, mass data modification	Strong auth (MFA), audit logs, confirmation dialogs, IP whitelisting
API	Integrate systems	Credential theft, rate limit bypass, cost attacks	API key rotation, quota limits, cost caps, monitoring
Commenting	User feedback	Spam, XSS, phishing links, hate speech	Content filtering, CAPTCHA, XSS prevention (CSP), moderation queue

4. Data Flow Diagrams (DFD) for Threat Modeling

DFD Levels

Level 0 (Context Diagram):

• High-level: System as single process, external entities only
• Use for: Executive overview, scope definition

Level 1 (Major Components):

• Shows: Main processes, data stores, external entities, trust boundaries
• Use for: STRIDE analysis at component level

Level 2+ (Detailed):

• Decomposes: Level 1 processes into sub-processes
• Use for: Deep dive on critical components (auth, payment, data handling)

DFD Elements

Symbols:

• External Entity (rectangle): User, third-party service, external system
• Process (circle): Component that transforms data (web server, API, background job)
• Data Store (parallel lines): Database, file system, cache, queue
• Data Flow (arrow): Data moving between elements (HTTP request, DB query, file read)
• Trust Boundary (dotted line box): Security domain boundary

Example (Login Flow - Level 1):

[User] ---(email, password)---> [Web Server] ---(credentials)---> [Database]
                                       |                              |
                                       |<--(user record, hashed pw)---|
                                       |
                                       |---(session token)---> [Redis Cache]

Trust boundaries:

• User ↔ Web Server (untrusted → trusted, validate all input)
• Web Server ↔ Database (application → data layer, parameterized queries)

Applying STRIDE to DFD

For each element type, ask specific STRIDE questions:

External Entity:

• Spoofing: Can attacker impersonate this entity? (auth required?)
• Repudiation: Can entity deny actions? (audit logging?)

Process:

• Tampering: Can attacker modify process logic? (code signing, integrity checks?)
• Information Disclosure: Does process leak sensitive data in logs/errors?
• Denial of Service: Can attacker crash/exhaust this process?
• Elevation of Privilege: Can attacker gain higher permissions through this process?

Data Store:

• Tampering: Can attacker modify stored data? (access control, integrity checks?)
• Information Disclosure: Can attacker read sensitive data? (encryption at rest, access control?)
• Denial of Service: Can attacker fill/corrupt data store?

Data Flow:

• Tampering: Can attacker modify data in transit? (TLS, message signing?)
• Information Disclosure: Can attacker eavesdrop? (encryption in transit?)
• Denial of Service: Can attacker block/flood this flow?

DFD-Based Threat Enumeration

Systematic approach:

1. Draw DFD with trust boundaries
2. Number each data flow (DF1, DF2, ...)
3. For each flow crossing trust boundary, apply STRIDE
4. For each process, apply STRIDE
5. For each data store with sensitive data, apply Tampering + Information Disclosure
6. Document threats in spreadsheet (DFD element, STRIDE category, threat description, mitigation)

Example:

DFD Element	Trust Boundary	STRIDE	Threat	Likelihood	Impact	Mitigation
DF1: User → Web Server	Yes (external → internal)	Spoofing	CSRF attack using stolen session cookie	Medium	High	CSRF tokens, SameSite cookies
DF1: User → Web Server	Yes	Tampering	MITM modifies login request	Low	High	HTTPS, HSTS
P1: Web Server	No	Elevation of Privilege	SQLi escalates to admin via DB access	Medium	Critical	Parameterized queries, least privilege DB user
DS1: Database	No	Information Disclosure	Backup left public on S3	Low	Critical	S3 bucket policy (private), encryption

5. Threat Intelligence Integration

MITRE ATT&CK Mapping

MITRE ATT&CK: Knowledge base of adversary tactics and techniques observed in real-world attacks.

Tactics (why): Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Impact

Example Mapping:

System Feature	ATT&CK Technique	Mitigation
Web application login	T1078 (Valid Accounts)	MFA, account lockout, monitoring
API with OAuth	T1550 (Use Alternate Authentication Material - token theft)	Short-lived tokens, token rotation, secure storage
File upload	T1105 (Ingress Tool Transfer - upload malware)	File type validation, virus scanning
Admin panel	T1078.003 (Valid Accounts: Local Accounts)	Principle of least privilege, MFA, audit logs
Database backups	T1530 (Data from Cloud Storage Object)	Encryption, private buckets, access logging

Using ATT&CK:

• Threat modeling input: Browse ATT&CK for tactics relevant to your system (e.g., "Initial Access" for Internet-facing apps)
• Red teaming: Use ATT&CK techniques to simulate attacks during testing
• Detection engineering: Map ATT&CK techniques to monitoring rules (e.g., T1078 → alert on failed login spike)

CVE/CWE Mapping

CWE (Common Weakness Enumeration): Catalog of software weaknesses.

Top CWEs (CWE Top 25):

• CWE-79: Cross-Site Scripting (XSS)
• CWE-89: SQL Injection
• CWE-20: Improper Input Validation
• CWE-78: OS Command Injection
• CWE-190: Integer Overflow
• CWE-352: CSRF
• CWE-22: Path Traversal
• CWE-798: Hard-coded Credentials

CVE (Common Vulnerabilities and Exposures): Specific vulnerabilities in specific products.

Integration:

• Dependency scanning: Identify CVEs in third-party libraries (npm audit, Snyk, Dependabot)
• Patch management: Prioritize CVEs with public exploits (CVSS ≥7.0, exploited in wild)
• Threat model coverage: Ensure threat model addresses CWE Top 25 for your language/framework

6. Advanced STRIDE Patterns

STRIDE for Cloud Infrastructure

Cloud-specific threats:

Spoofing:

• IAM role assumption: Attacker assumes role with excessive permissions
• Instance metadata service (IMDS): Attacker fetches IAM credentials from EC2 metadata
• Mitigation: Least privilege IAM, IMDSv2 (session-based), instance profile credential rotation

Tampering:

• S3 bucket policy override: Attacker modifies bucket to public
• Security group modification: Attacker opens firewall rules
• Mitigation: AWS Config rules (detect policy changes), SCPs (deny public access), CloudTrail alerts

Information Disclosure:

• Public snapshot: EBS/RDS snapshot left world-readable
• CloudWatch Logs exposure: Logs contain secrets, accessible to over-permissioned roles
• Mitigation: Automated snapshot encryption, secrets redaction in logs, least privilege CloudWatch access

Denial of Service:

• Cost attack: Attacker triggers expensive operations (Lambda invocations, data transfer)
• Resource exhaustion: Attacker fills S3 bucket, exhausts RDS connections
• Mitigation: Cost alarms, resource quotas, rate limiting

Elevation of Privilege:

• Privilege escalation via misconfigured IAM: Attacker modifies own permissions
• Container escape: Attacker breaks out of container to host
• Mitigation: IAM permission boundaries, pod security policies, AppArmor/SELinux

STRIDE for APIs

API-specific threats:

Spoofing:

• API key theft: Hardcoded in client, extracted from mobile app
• JWT forgery: Weak secret, algorithm confusion (RS256 → HS256)
• Mitigation: API key rotation, secure storage (Keychain), strong JWT secrets (256-bit), algorithm whitelisting

Tampering:

• Parameter tampering: Modify user_id in request to access other user's data (IDOR)
• Mass assignment: Send unexpected fields to create admin users
• Mitigation: Authorization checks (verify user_id matches authenticated user), allowlist input fields

Repudiation:

• No audit trail: API calls not logged, can't prove who did what
• Mitigation: Comprehensive API logging (request ID, user ID, timestamp, endpoint, status)

Information Disclosure:

• Over-fetching: GraphQL query returns entire user object including PII
• Verbose errors: Stack traces reveal internal structure
• Mitigation: Field-level authorization (GraphQL), generic error messages to client

Denial of Service:

• Query depth attack: GraphQL query with 50 nested levels exhausts CPU
• Rate limit bypass: Distributed requests from many IPs
• Mitigation: Query depth limiting, query cost analysis, distributed rate limiting (Redis), CAPTCHA

Elevation of Privilege:

• OAuth scope creep: App requests excessive scopes, user approves without reading
• Broken Object Level Authorization (BOLA): API doesn't check if user can access resource
• Mitigation: Minimal scopes (principle of least privilege), authorization middleware on every endpoint

STRIDE for Mobile Apps

Mobile-specific threats:

Spoofing:

• Jailbreak/root detection bypass: Attacker modifies app to skip security checks
• Certificate pinning bypass: Attacker uses Frida to disable pinning, installs proxy cert
• Mitigation: Multiple anti-tamper checks, runtime integrity verification, server-side device attestation

Tampering:

• Reverse engineering: Attacker decompiles APK/IPA, finds hardcoded secrets
• Mitigation: ProGuard/R8 obfuscation (Android), app encryption (iOS), no secrets in client code (fetch from server)

Information Disclosure:

• Insecure local storage: SQLite DB unencrypted, accessible via device backup
• Logging sensitive data: Passwords/tokens in Logcat (Android) or Console (iOS)
• Mitigation: Keychain (iOS) / Keystore (Android), encrypted databases (SQLCipher), disable logging in production

Denial of Service:

• Battery drain attack: Malicious app or ad SDK consumes CPU/network
• Mitigation: Background task limits, network efficiency monitoring

Elevation of Privilege:

• Permission escalation: App tricks user into granting dangerous permissions
• Mitigation: Request permissions at time of use (just-in-time), explain why needed

---

When to Use Advanced Methodologies

Attack Trees: Complex systems with many attack paths, need to prioritize defenses, red team planning

DREAD Scoring: Quantitative risk prioritization, limited security budget, need to justify spending to leadership

Abuse Cases: Feature-rich applications, insider threat modeling, compliance requirements (SOX, HIPAA audit trails)

DFD-based STRIDE: New system design (pre-implementation), comprehensive threat coverage, training junior security engineers

Threat Intelligence (ATT&CK/CVE): Mature security programs, red team exercises, detection engineering, patch prioritization

Cloud/API/Mobile STRIDE: Specialized systems requiring domain-specific threat patterns

Start simple (basic STRIDE on trust boundaries), add complexity as needed (attack trees for critical paths, DREAD for prioritization).