Threat Modeling Frameworks: STRIDE, PASTA, LINDDUN, MITRE ATT&CK und Praxis-Integration

Threat modeling is a systematic method for identifying threats to a system before they are exploited. It is the most cost-effective security measure available—finding flaws in the design costs 100 times less than fixing flaws in production. It answers four key questions: What are we building? What could go wrong? What are we doing to prevent it? Did we do it right?

Why Threat Modeling?

Cost of security flaws depending on when they are discovered:
(according to IBM Systems Sciences Institute)

Design phase:     1x (e.g., 100 EUR cost)
Development:      6x
Testing/QA:          15x
Production:       30–100x
After a data breach:  up to 1000x (fines, reputational damage, forensics)

→ 2 hours of threat modeling in the design phase saves 200 hours of subsequent fixes!

What Threat Modeling Does:
  → Identify threats before code exists
  → Set priorities: which threats are truly dangerous
  → Derive security requirements for developers
  → Compliance documentation (ISO 27001, GDPR Art. 32, NIS2)
  → Communication tool: Security, Dev, and Business speak with one voice

What Threat Modeling is NOT:
  → Not a substitute for penetration testing (penetration testing finds implementation errors)
  → Not a one-time process (every architecture change = new TM)
  → No guarantee (but significant risk reduction)

When to perform threat modeling:
  → Design phase: most effective (most cost-effective troubleshooting)
  → Start of sprint: for new features (Agile Threat Modeling)
  → Before penetration testing: to better understand the scope
  → After an incident: What would threat modeling have detected?
  → During system changes: API changes, new third-party providers, etc.

The Four Core Questions

Threat Modeling Basic Structure:

1. What are we building?
   → System documentation: DFD (Data Flow Diagram), architecture diagram
   → Identification: Assets, trust boundaries, data flows, entry points

2. What can go wrong?
   → Framework-based threat identification (STRIDE, PASTA, etc.)
   → Threat Intelligence: What TTPs do relevant attackers use?
   → Attack Trees: Attack tree analysis

3. What are we doing about it?
   → Mitigations for each threat
   → Risk assessment: Likelihood × Impact = Risk
   → Decision: Mitigate / Accept / Insure / Avoid

4. Did we do it right?
   → Review: Have all threats been addressed?
   → Tests: Does a penetration test validate the mitigations?
   → Update: Update the threat model when system changes occur

Data Flow Diagram (DFD)

DFD as the basis for all threat modeling methods:

DFD elements:
  [Rectangle]     External Entity:  Users, external systems (outside our control)
  (Oval)         Process:          Software that processes data
  = =            Data Store:       Database, file, storage
  →              Data Flow:        Data transfer between elements
  ---Line---   Trust Boundary:   Boundary between trust zones

Example: Web Application Login Flow

  [Browser]  ──HTTPS POST /login──►  (Auth Service)  ──SQL──►  [Users DB]
      │                                    │
  Trust Boundary: Internet/DMZ        Trust Boundary: App/DB
      │                                    │
  External User                       Session Token ──►  [Session Cache]
                                           │
                                      Event ──► (Audit Logger) ──► [Audit Log]

Identify attack surface:
  → Every data flow arrow = potential point of attack
  → Every trust boundary crossing = examine critically
  → External Entities: must always be considered "hostile"
  → Data Stores: what happens in case of SQL injection?

DFD Level 0: Context Diagram (System Boundaries)
DFD Level 1: Main Components and Data Flows
DFD Level 2: Detailed internal processes

DFD Tools:
  OWASP Threat Dragon:  owasp.org/www-project-threat-dragon/ (free)
  Microsoft TMT 2016:   For Windows, STRIDE-integrated
  draw.io + Stencils:   Flexible, collaborative (Confluence plugin)
  PlantUML:             Code-based, versionable in Git
  Miro:                 Online whiteboard, good for workshops

STRIDE Framework (Microsoft)

STRIDE - Threat categories for each DFD element:

S - Spoofing (impersonation):
  Question: Can an attacker pretend to be someone else?
  Affects: External actors, processes, data flows
  Examples:
  → Forging JWT tokens (alg=none attack)
  → ARP spoofing on the internal network
  → IP spoofing: forged source IP in UDP packets
  → Credential stuffing: using someone else’s login credentials
  Mitigations: Strong authentication (MFA!), TLS, HMAC

T - Tampering (data manipulation):
  Question: Can data be altered without authorization?
  Affects: Data flows, data storage
  Examples:
  → SQL injection modifies database content
  → HTTP parameter manipulation (price, UserID)
  → Man-in-the-Middle attack modifies API response
  → Modifying config files
  Mitigations: Integrity checks (HMAC, signatures), input validation

R - Repudiation:
  Question: Can someone deny having performed an action?
  Affects: All interactions with external impact
  Examples:
  → User denies placing an order (no audit log)
  → Admin action cannot be traced
  → Missing logs: no proof of transactions
  Mitigations: Audit logs (immutable!), digital signatures, separate accounts

I - Information Disclosure:
  Question: Can data be viewed without authorization?
  Applies to: Data flows, data storage
  Examples:
  → Error messages reveal internal structure (stack traces)
  → Unencrypted transmission of sensitive data
  → Directory listing on web server
  → IDOR: /api/users/1, /api/users/2 → all user data
  Mitigations: Encryption, access controls, error handling

D - Denial of Service (Availability Impairment):
  Question: Can an attacker cause the service to fail?
  Affects: Processes, data flows
  Examples:
  → DDoS on public API
  → Resource exhaustion due to expensive queries
  → Disk full due to uncontrolled logging
  → ReDoS: Regular Expression DoS
  Mitigations: Rate Limiting, Auto-Scaling, Timeouts, Backups, WAF

E - Elevation of Privilege:
  Question: Can someone gain more privileges than intended?
  Affects: Processes, External Actors
  Examples:
  → SQL Injection → DBA privileges
  → IDOR: User A views User B’s data
  → JWT Manipulation: role: "user" → role: "admin"
  → Insecure Deserialization: Code Execution as System User
  Mitigations: Least Privilege, Sandboxing, Input Validation, Authorization Checks

STRIDE by Element:
  External Entities: STE__ (no Denial of Service, no Elevation)
  Processes:         STRIDE (all categories possible)
  Data Stores:       _TRI__ (Tampering, Repudiation, Information Disclosure)
  Data Flows:        S_RID_ (Spoofing, Repudiation, Information Disclosure, DoS)

STRIDE Workshop Guide (2h)

Preparation (30min):
  → Create DFD Level 1 (together with the dev team)
  → Draw trust boundaries
  → Participants: Dev Lead, Security Champion, Product Owner

Analysis (60min):
  → Go through each DFD element
  → STRIDE checklist per element:
    Data flow HTTP GET /api/users:
    S: Who authenticates? → JWT (but: is alg=none possible?)
    T: Can the response be manipulated? → TLS (but: certificate pinning?)
    R: Is the request logged? → Yes, audit log
    I: What data is transmitted? → User list, PII?
    D: Rate limiting in place? → No → FINDING!
    E: Can a regular user view admin data? → IDOR check!

Prioritization (30 min):
  → DREAD score or CVSS for each threat
  → Probability of occurrence × Impact → Risk matrix
  → Top 5 threats → Security requirements

PASTA Framework

PASTA (Process for Attack Simulation and Threat Analysis):

PASTA is risk-based and business-oriented:
→ 7-phase process (more effort than STRIDE, but more comprehensive)
→ Links business risks to technical threats
→ Attack-centric: simulated attacker perspective

Phase 1 - Define Objectives:
  → Business Objectives: What is the system supposed to achieve?
  → Security Objectives: Confidentiality, Integrity, Availability
  → Compliance requirements: GDPR, PCI DSS, NIS2
  Output: Scope document

Phase 2 - Define Technical Scope:
  → System architecture: all components
  → Dependencies: third-party APIs, libraries
  → Attack surface: What entry points does the system have?
  Output: Technical system diagram

Phase 3 - Application Decomposition:
  → Create DFD (like STRIDE)
  → Data classification: What data is processed?
  → Trust levels: Who is allowed to do what?
  Output: DFD + asset list

Phase 4 - Threat Analysis:
  → Threat intelligence: Which threat actors are relevant?
  → TTPs (MITRE ATT&CK): What techniques do attackers use?
  → Historical Incidents: How were similar systems compromised?
  Output: Threat library adapted to the context

Phase 5 - Vulnerability and Weakness Analysis:
  → SAST results: Known code vulnerabilities
  → DAST results: Current vulnerabilities
  → CVE analysis for libraries in use
  → Mapping: Vulnerabilities → Threats from Phase 4
  Output: Vulnerability-Threat Mapping

Phase 6 - Attack Simulation:
  → Attack Trees: How does an attacker combine vulnerabilities?
  → Attack Scenarios: "Attacker compromises DB via SQL injection"
  → Exploitation Chains: Modeling multi-stage attacks
  → Assessing likelihood: How likely is this attack?
  Output: Attack Trees + Exploitation Scenarios

Phase 7 - Risk and Impact Analysis:
  → Business Impact: What is the cost of each scenario occurring?
  → Residual risk after mitigations
  → ROI of security measures
  Output: Risk report + prioritized list of measures

PASTA vs. STRIDE:
  → STRIDE: fast, structured, developer-friendly
  → PASTA: comprehensive, business-aligned, more effort
  → Recommendation: STRIDE for sprint threat modeling, PASTA for system design

LINDDUN (Privacy-focused)

LINDDUN - Threat Modeling for Data Protection/Privacy:

Use: When GDPR Art. 25 (Privacy by Design) is required
Useful for: Health data, payment data, HR systems

L - Linkability:
  Data points can be linked → Profile can be created
  Example: Tracking pixels in two different online stores → same user
  Example: Browser fingerprinting + login + purchase history = profile

I - Identifiability:
  Person identifiable from data (re-identification)
  Example: Combination of ZIP code + date of birth + gender → unique

N - Non-repudiation:
  Person cannot deny that data originates from them (privacy-relevant)
  Example: Detailed logs prevent denial - GDPR issue!
  Example: IP address unique → Activity log cannot be denied

D - Detectability:
  Activities of individuals can be detected
  Example: Traffic analysis shows: "User is communicating with an HIV counseling center"
  (even without knowing the content!)

D - Disclosure of Information:
  Unintended disclosure of data
  Example: API returns more data than necessary (Excessive Data Exposure)

U - Unawareness:
  User does not know what data is being collected
  Example: App collects location data without clear information
  Example: No privacy notice, unclear cookie consent

N - Non-Compliance:
  Violation of data protection laws
  Example: Missing retention periods, no data subject rights process
  Example: No legal basis for processing (GDPR Art. 6)

When to use LINDDUN:
  → All systems that process personal data (almost all!)
  → GDPR Data Protection Impact Assessment (DPIA) as a basis
  → Combination with STRIDE: technical + data protection threats

DREAD Scoring

DREAD - Risk Assessment for Threats:

Rating on a scale of 1–3 (low/medium/high):

D - Damage Potential:
  3 = Complete system compromise
  2 = Data loss, system disruption
  1 = Minimal damage

R - Reproducibility:
  3 = Reproducible at any time
  2 = Occasionally reproducible
  1 = Rarely reproducible

E - Exploitability:
  3 = No specialized knowledge required; a script kiddie can do it
  2 = Experienced attacker required
  1 = Expert required; specific knowledge required

A - Affected Users:
  3 = All users affected
  2 = Many users; important users
  1 = Few/unimportant users

D - Discoverability:
  3 = Publicly known; present in default configuration
  2 = discoverable through testing
  1 = hard to find

Score: (D + R + E + A + D) / 5
→ 2.5–3.0 = Critical
→ 1.5–2.4 = High
→ 1.0–1.4 = Medium

Example: SQL injection in login:
  D=3 (DB access), R=3 (deterministic), E=2 (Sqlmap required),
  A=3 (all users), D=3 (known by OWASP) → 2.8 = Critical

MITRE ATT&CK; as a Threat Modeling Reference

ATT&CK Integration in Threat Modeling:

What ATT&CK offers:
  → 193+ techniques for enterprise environments (Windows, macOS, Linux, cloud)
  → Sub-techniques for details
  → Malware groups: which TTPs do APT28, Lazarus, etc. use?
  → Mitigations: directly per technique

ATT&CK mapping example (web app):

  Tactic          Technique                   Mitigation
  ─────────────────────────────────────────────────────────
  Reconnaissance  T1595 Active Scanning       WAF, Rate Limit
  Initial Access  T1190 Public-facing App     Patch, WAF, DAST
  Execution       T1059 Command/Script        Input Validation, App Sandbox
  Persistence     T1505 Server Software       File Integrity Monitoring
  Priv. Escal.    T1078 Valid Accounts        MFA, PAM
  Collection      T1005 Data from Local Sys   DLP, Encryption

  MITRE Navigator (attack.mitre.org/navigator):
  → Visual representation of which TTPs are relevant for system types
  → Heatmap: highlights frequently used techniques
  → Export as JSON → import into threat modeling tool

Threat Actor Mapping:
  # Which APT group is targeting my sector?
  → Financial sector: Carbanak, Lazarus, FIN7
  → Healthcare: APT41, Dark Caracal
  → Critical Infrastructure/Energy: Sandworm, Dragonfly

Tools and Automation

Threat Modeling Tools:

Microsoft Threat Modeling Tool (free):
  → Download: microsoft.com/en-us/securityengineering/sdl/tmtool
  → STRIDE-based, integrated DFD editor
  → Automatic threat generation from DFD elements
  → Reports: Word, PDF, HTML
  → Limitation: Windows-only, no collaboration

OWASP Threat Dragon (Open Source):
  → Web-based or desktop app
  → DFD editor, STRIDE threats
  → GitHub integration (threat model as JSON in repository)
  → Team collaboration: multiple users can edit

IriusRisk (commercial):
  → Enterprise-grade threat modeling
  → JIRA/GitHub integration: issues generated from threats
  → Library: predefined threats for technologies (AWS, Kubernetes, etc.)
  → Automation: CI/CD pipeline integration

Threagile (code-based, open source):
  → Define threat model as a YAML file
  → Automatic analysis and PDF report
  → Git-versioned (Infrastructure as Code principle!)
  → CI/CD integration: Threat modeling as a pipeline stage

  # Threagile YAML example:
  title: "Web Application Threat Model"
  business_overview:
    description: "E-commerce platform for B2B customers"
  technical_overview:
    description: "Three-tier web app with PostgreSQL"
  technical_assets:
    web-server:
      id: web-server
      description: "Nginx + Node.js Application"
      type: process
      technologies: [ nginx, node-js ]
      trust_boundary: dmz

Cairis:
  → Open-source threat modeling tool with LINDDUN support

Integrating Threat Modeling into the SDLC

Integration into the Development Process (Agile/Scrum):

Sprint 0 / Design Phase:
  → New Feature: 2-hour Threat Modeling Workshop
  → Participants: Dev Lead, Security Champion, Product Owner
  → Output: Threat Model Document + Security Stories in the Backlog

Continuous Updates:
  → Architecture Changes: Update TM (even minor changes!)
  → New dependencies: New attack surface?
  → Incidents: Threat model was incorrect → correct

Documentation:
  → STRIDE table with identified threats
  → Risk matrix: Probability of occurrence × Impact
  → Countermeasures with ticket links (JIRA, GitHub Issues)
  → Residual risk with acceptance signature (CISO/Owner)

ROI of Threat Modeling:
  □ Bugs in design phase: 10x cheaper than in production
  □ Shorter penetration tests: Better understanding of scope
  □ Clear security requirements: Developers know what to implement
  □ Compliance: ISO 27001, GDPR, DSFA, BSI IT-Grundschutz
  □ Documentation: Architectural security decisions are traceable

ISO 27001 Relevance:
  A.5.8: Information security in project management
  A.8.25: Secure development lifecycle
  A.8.26: Application security requirements
  → Threat models serve as evidence of security requirements in development