Threat Modeling Frameworks

Master STRIDE, LINDDUN, and PASTA frameworks

TL;DR

STRIDE (Microsoft) is element-based: identify threats per system component (Spoofing identity, Tampering data, Repudiation of actions, Information disclosure, Denial of service, Elevation of privilege). LINDDUN (KU Leuven) focuses on privacy threats (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure, Unawareness, Non-compliance). PASTA (attack-centric) works backward from attacker goals to identify attack paths. Choose based on your priority: STRIDE for general security, LINDDUN for privacy-heavy systems, PASTA for understanding attacker motivation.

Learning Objectives

• Apply STRIDE to identify security threats
• Use LINDDUN for privacy threat analysis
• Conduct PASTA (attack path) analysis
• Choose appropriate framework for context
• Create actionable threat models
• Prioritize mitigations by impact and likelihood

Motivating Scenario

Your team designed a health data sharing platform. Everyone agrees it should be secure. But "secure" means different things: prevent tampering (STRIDE's Tampering), prevent patient linking across systems (LINDDUN's Linkability), or stop an attacker from gaining system access (PASTA's attack tree). Without a shared framework, threat modeling is chaotic and incomplete.

Core Concepts

STRIDE Framework

Microsoft's element-centric approach. For each system component, ask: What STRIDE threats exist?

Threat	Definition	Example	Mitigation
Spoofing	Pretend to be someone/something else	Attacker claims to be user Alice	Authentication (password, MFA, certs)
Tampering	Modify data/code in transit or at rest	Attacker modifies transaction amount	Checksums, encryption, digital signatures
Repudiation	Deny performing an action	"I didn't approve that payment"	Audit logs, digital signatures, non-repudiation
Information Disclosure	Unauthorized access to data	Attacker reads customer emails	Encryption, access control
Denial of Service	Make system unavailable	DOS attack overwhelms server	Rate limiting, redundancy, DNS protection
Elevation of Privilege	Gain higher permissions than authorized	User escalates to admin	Authorization checks, least privilege

LINDDUN Framework

Privacy-centric (important for GDPR, CCPA compliance). Ask: What privacy risks exist?

Threat	Definition	Example	Mitigation
Linkability	Link user actions across systems	Device fingerprinting correlates users	Anonymization, data minimization
Identifiability	Identify individual from data	De-identified dataset re-identified	Differential privacy, aggregation
Non-repudiation	User can't deny action	Audit logs prove user deleted data	Consent, transparency, user control
Detectability	Presence/absence of info detectable	Timing side-channel reveals algorithm	Constant-time operations
Disclosure	Unauthorized access to info	Memory dump reveals encryption keys	Encryption, secure storage
Unawareness	User unaware of data collection	Hidden tracking, fingerprinting	Transparency, consent
Non-compliance	Violation of regulations	Data not deleted per GDPR request	Policy automation, compliance checks

PASTA Framework

Attack-centric. Works backward from attacker goals to identify exploitable paths.

Stages:

1. Identify stakeholders and assets: What do attackers want?
2. Define attack scenarios: What paths lead to asset compromise?
3. Analyze attack feasibility: How likely and difficult?
4. Enumerate controls: What defends against this?
5. Recommend mitigations: What closes the gap?

Practical Example

STRIDE Analysis

System: User Login Service

[User] ---(username/password)---> [Auth Server] ---(session token)---> [Client]

STRIDE Threats:

Spoofing:
  - Attacker claims to be user by guessing password
  - Mitigation: Strong password policy, rate limiting, MFA

Tampering:
  - Attacker modifies session token
  - Mitigation: Cryptographic signing, timestamp validation

Repudiation:
  - User claims they didn't log in from X IP
  - Mitigation: Audit logs with IP, timestamp, device

Information Disclosure:
  - Password transmitted in plaintext
  - Mitigation: HTTPS/TLS encryption

Denial of Service:
  - Attacker floods login endpoint with requests
  - Mitigation: Rate limiting, CAPTCHA after N failures

Elevation of Privilege:
  - User with limited access claims admin role
  - Mitigation: Role validation, authorization checks

LINDDUN Privacy Analysis

System: Health Data Sharing Platform

LINDDUN Threats:

Linkability:
  - Attacker correlates patient visits across time/clinics
  - Mitigation: Anonymization, pseudonyms, no persistent IDs

Identifiability:
  - De-identified health record re-identified via public info
  - Example: "40-year-old female from ZIP 12345 with rare disease" = 1 person
  - Mitigation: Differential privacy, aggregation, coarsening

Non-repudiation:
  - Patient shares data, later claims non-consent
  - Mitigation: Signed consent, audit trail

Detectability:
  - Presence of data reveals info (e.g., patient sought psychiatry = mental health issue)
  - Mitigation: Dummy records, hiding access patterns

Disclosure:
  - Database breach exposes health records
  - Mitigation: Encryption, key separation, access control

Unawareness:
  - Platform secretly shares data with researchers
  - Mitigation: Explicit consent, transparency

Non-compliance:
  - Patient requests data deletion; not honored
  - Mitigation: Automated deletion, compliance audits

PASTA Attack Path

Attacker Goal: Exfiltrate customer database

Attack Path Analysis:

Goal: Access Database
├── Path 1: SQL Injection
│   ├── Attacker crafts malicious SQL in login form
│   ├── Application concatenates unescaped SQL
│   ├── Attacker retrieves entire database
│   └── Mitigation: Parameterized queries
│
├── Path 2: Compromise Web Server
│   ├── Attacker scans for outdated framework versions
│   ├── Applies known exploit
│   ├── Gains code execution on server
│   ├── Connects to database as app user
│   └── Mitigation: Patching, Web Application Firewall
│
└── Path 3: Steal DBA Credentials
    ├── Attacker socially engineers DBA
    ├── Gains VPN access
    ├── Connects directly to database
    └── Mitigation: MFA, access logging, network segmentation

High-Risk Paths: SQL Injection (easiest), DBA compromise (highest impact)
Prioritize: Fix SQL Injection first (low effort), then MFA (prevents DBA path)

Choosing a Framework

Use STRIDE when:

• General security assessment needed
• Per-element analysis preferred
• Addressing CIA triad concerns

Use LINDDUN when:

• Privacy is primary concern
• GDPR, CCPA, health data compliance
• Tracking and identification risks

Use PASTA when:

• Understanding attacker motivation
• Prioritizing high-impact paths
• Red team exercises

Combine them: Large systems use multiple. STRIDE catches authentication flaws; LINDDUN catches privacy leaks; PASTA identifies highest-risk paths.

Threat Modeling Artifacts

Threat Model Document:

# Threat Model: Payment Service

## System Overview
- Components: Web API, Database, Payment Gateway
- Assets: Customer credit cards, transaction history
- Trust Boundaries: Internet, Internal network, Payment Gateway

## Threats (STRIDE)
- Spoofing: Attacker claims to be customer
  - Mitigation: OAuth 2.0 authentication
  - Status: Implemented

- Tampering: Attacker modifies transaction amount
  - Mitigation: HTTPS, checksums, database constraints
  - Status: Implemented

[... more threats ...]

## Mitigations & Status
- MFA: Implemented, deployed to 95% of users
- Input validation: Implemented for all inputs
- Rate limiting: Planned, in development

## Risk Ranking
1. API key exposure: High likelihood, high impact
2. SQL injection: Medium likelihood, high impact
3. DOS attack: Low likelihood, medium impact

Design Review Checklist

• Threat modeling completed before/early in design
• Appropriate framework chosen (STRIDE/LINDDUN/PASTA)
• All system components analyzed
• Threats ranked by impact and likelihood
• Mitigations identified for each threat
• Mitigations implemented or scheduled
• Residual risks documented and accepted
• Threat model updated after major changes
• Security team reviewed threat model
• Assumptions about trust boundaries explicit

Self-Check

• What's the difference between STRIDE and LINDDUN threats?
• Which framework focuses on attacker motivation?
• How would you prioritize threats for mitigation?

One Takeaway

Threat models prevent surprises by identifying threats systematically before they become breaches.

Next Steps

• Read Assets, Attack Surfaces, Trust Boundaries for scoping threat models
• Study Abuse & Misuse Cases for user-centric threats
• Explore Implementation Guidance for specific mitigations

Framework Comparison and Selection

Framework	Focus	Best For	Effort
STRIDE	Security (CIA)	General applications	2-3 hours
LINDDUN	Privacy (GDPR compliance)	Data-heavy systems	2-3 hours
PASTA	Attacker perspective	Red team exercises	4-6 hours

Recommendation: Start with STRIDE (fastest), add LINDDUN if privacy critical, use PASTA for complex systems.

Real-World Threat Model Document

# Threat Model: Payment Processing Service

## System Components
- Web API (Node.js)
- Database (PostgreSQL)
- Payment Gateway (Stripe)
- Message Queue (RabbitMQ)

## STRIDE Analysis

### Spoofing Identity
- Threat: Attacker impersonates user via stolen JWT token
- Likelihood: Medium (tokens in logs, browser memory)
- Impact: High (can approve payments)
- Mitigation: JWTs expire in 15 minutes, refresh tokens with strict rotation
- Status: Implemented

### Tampering Data
- Threat: Attacker modifies transaction amount in transit
- Likelihood: Low (HTTPS enforced)
- Impact: High (financial fraud)
- Mitigation: TLS 1.2+, certificate pinning, checksums
- Status: Implemented

### Repudiation
- Threat: User denies approving payment
- Likelihood: High (common dispute)
- Impact: Medium (chargebacks)
- Mitigation: Immutable audit log, digital signatures, confirmation emails
- Status: Partial (email not signed)

### Information Disclosure
- Threat: Card numbers exposed in logs
- Likelihood: High (developers often log parameters)
- Impact: Severe (PCI violation)
- Mitigation: Redact sensitive data in logs, encryption at rest, vault for secrets
- Status: Needs improvement (audit logs currently have full card numbers)

### Denial of Service
- Threat: Attacker floods payment endpoint
- Likelihood: High (public endpoint)
- Impact: High (service unavailable)
- Mitigation: Rate limiting (10 requests/min), CAPTCHA, DDoS protection
- Status: Rate limiting implemented

### Elevation of Privilege
- Threat: Customer escalates to admin
- Likelihood: Low (proper auth checks)
- Impact: High (full system access)
- Mitigation: Role-based access control, JWT claims validation
- Status: Implemented

## Risk Summary
- Critical: Fix Information Disclosure (card numbers in logs)
- High: Add email signature for repudiation
- Medium: All others addressed

## Action Items
- [ ] Sanitize all logs (redact card numbers, SSNs, etc.)
- [ ] Add cryptographic signature to confirmation emails
- [ ] Penetration test by Q2
- [ ] Review threat model in 6 months

References

• STRIDE Threat Model (Microsoft)
• LINDDUN Privacy Threat Modeling (KU Leuven)
• PASTA Framework (Gartner)
• Threat Modeling: Design for Security (Adam Shostack)
• Real-world threat model examples and case studies