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

Threat Modeling ist die systematische Methode, Bedrohungen gegen ein System zu identifizieren bevor sie ausgenutzt werden. Es ist die kosteneffizienteste Sicherheitsmaßnahme überhaupt - Fehler im Design zu finden kostet 100x weniger als Fehler in der Produktion zu beheben. Es beantwortet vier Kernfragen: Was bauen wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir es richtig gemacht?

Warum Threat Modeling?

Kosten von Sicherheitsfehlern je nach Entdeckungszeitpunkt:
(nach IBM Systems Sciences Institute)

Design-Phase:     1x (z.B. 100 EUR Aufwand)
Entwicklung:      6x
Test/QA:          15x
Produktion:       30-100x
Nach Datenpanne:  bis 1000x (Bußgeld, Reputationsschaden, Forensik)

→ 2h Threat Modeling in der Design-Phase spart 200h nachträgliche Fixes!

Was Threat Modeling leistet:
  → Bedrohungen identifizieren bevor Code existiert
  → Prioritäten setzen: welche Bedrohungen wirklich gefährlich sind
  → Security Requirements für Entwickler ableiten
  → Compliance-Dokumentation (ISO 27001, DSGVO Art. 32, NIS2)
  → Kommunikationswerkzeug: Security + Dev + Business sprechen gemeinsam

Was Threat Modeling NICHT ist:
  → Kein Pentest-Ersatz (Pentest findet Implementierungsfehler)
  → Kein einmaliger Prozess (jede Architekturänderung = neues TM)
  → Keine Garantie (aber erhebliche Risikoreduktion)

Wann Threat Modeling durchführen:
  → Design-Phase: am wirkungsvollsten (günstigste Fehlerbehebung)
  → Sprint-Beginn: bei neuen Features (Agile Threat Modeling)
  → Vor Penetrationstest: Scope besser verstehen
  → Nach Incident: Was hätte Threat Modeling erkannt?
  → Bei Systemänderungen: API-Änderung, neuer Drittanbieter, etc.

Die vier Kernfragen

Threat Modeling Grundstruktur:

1. Was bauen wir?
   → System-Dokumentation: DFD (Data Flow Diagram), Architekturdiagramm
   → Identifikation: Assets, Vertrauensgrenzen, Datenflüsse, Einstiegspunkte

2. Was kann schiefgehen?
   → Framework-basierte Bedrohungsidentifikation (STRIDE, PASTA, etc.)
   → Threat Intelligence: welche TTPs nutzen relevante Angreifer?
   → Attack Trees: Angriffsbaum-Analyse

3. Was tun wir dagegen?
   → Mitigationen für jede Bedrohung
   → Risikobewertung: Likelihood × Impact = Risiko
   → Entscheidung: Mitigieren / Akzeptieren / Versichern / Vermeiden

4. Haben wir es richtig gemacht?
   → Review: alle Bedrohungen adressiert?
   → Tests: Penetrationstest validiert Mitigationen?
   → Update: bei Systemänderungen Threat Model aktualisieren

Data Flow Diagramm (DFD)

DFD als Basis für alle Threat Modeling Methoden:

DFD-Elemente:
  [Rechteck]     External Entity:  Nutzer, externe Systeme (außerhalb unserer Kontrolle)
  (Oval)         Process:          Software, die Daten verarbeitet
  = =            Data Store:       Datenbank, Datei, Speicher
  →              Data Flow:        Datenübertragung zwischen Elementen
  ---Strich---   Trust Boundary:   Grenze zwischen Vertrauenszonen

Beispiel: Web-Applikation Login-Flow

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

Angriffsfläche identifizieren:
  → Jeder Datenflusspfeil = potenzieller Angriffspunkt
  → Jede Trust-Boundary-Überquerung = kritisch prüfen
  → External Entities: müssen immer als "hostile" betrachtet werden
  → Data Stores: was passiert bei SQL-Injection?

DFD Level 0: Kontextdiagramm (Systemgrenzen)
DFD Level 1: Haupt-Komponenten und Datenflüsse
DFD Level 2: Detaillierte interne Prozesse

DFD-Tools:
  OWASP Threat Dragon:  owasp.org/www-project-threat-dragon/ (kostenlos)
  Microsoft TMT 2016:   Für Windows, STRIDE-integriert
  draw.io + Stencils:   Flexibel, Kollaborativ (Confluence-Plugin)
  PlantUML:             Code-basiert, versionierbar in Git
  Miro:                 Online-Whiteboard, gut für Workshops

STRIDE-Framework (Microsoft)

STRIDE - Bedrohungskategorien für jedes DFD-Element:

S - Spoofing (Identitätsvortäuschung):
  Frage: Kann ein Angreifer vorgeben, jemand anderes zu sein?
  Betrifft: Externe Akteure, Prozesse, Datenflüsse
  Beispiele:
  → JWT-Token fälschen (alg=none Attack)
  → ARP-Spoofing im internen Netz
  → IP-Spoofing: gefälschte Source-IP in UDP-Paketen
  → Credential Stuffing: fremde Zugangsdaten nutzen
  Mitigationen: Starke Authentifizierung (MFA!), TLS, HMAC

T - Tampering (Datenmanipulation):
  Frage: Können Daten unbefugt verändert werden?
  Betrifft: Datenflüsse, Datenspeicher
  Beispiele:
  → SQL Injection modifiziert Datenbankinhalt
  → HTTP-Parameter-Manipulation (Preis, UserID)
  → Man-in-the-Middle modifiziert API-Response
  → Config-File verändern
  Mitigationen: Integritätsprüfung (HMAC, Signaturen), Input Validation

R - Repudiation (Abstreitbarkeit):
  Frage: Kann jemand Aktionen abstreiten?
  Betrifft: Alle Interaktionen mit Außenwirkung
  Beispiele:
  → User streitet Bestellung ab (kein Audit Log)
  → Admin-Aktion nicht nachvollziehbar
  → Fehlende Logs: keine Nachweisbarkeit von Transaktionen
  Mitigationen: Audit Logs (unveränderlich!), digitale Signaturen, separate Accounts

I - Information Disclosure (Informationsoffenbarung):
  Frage: Können Daten unbefugt eingesehen werden?
  Betrifft: Datenflüsse, Datenspeicher
  Beispiele:
  → Error Messages enthüllen interne Struktur (Stack Traces)
  → Unverschlüsselte Übertragung sensibler Daten
  → Directory Listing auf Webserver
  → IDOR: /api/users/1, /api/users/2 → alle User-Daten
  Mitigationen: Verschlüsselung, Zugriffskontrollen, Fehlerbehandlung

D - Denial of Service (Verfügbarkeitsbeeinträchtigung):
  Frage: Kann ein Angreifer den Dienst zum Ausfall bringen?
  Betrifft: Prozesse, Datenflüsse
  Beispiele:
  → DDoS auf öffentliche API
  → Resource Exhaustion durch teure Queries
  → Disk Full durch unkontrolliertes Logging
  → ReDoS: Regular Expression DoS
  Mitigationen: Rate Limiting, Auto-Scaling, Timeouts, Backups, WAF

E - Elevation of Privilege (Rechteausweitung):
  Frage: Kann jemand mehr Rechte erlangen als vorgesehen?
  Betrifft: Prozesse, Externe Akteure
  Beispiele:
  → SQL Injection → DBA-Rechte
  → IDOR: User A sieht Daten von User B
  → JWT-Manipulation: role: "user" → role: "admin"
  → Insecure Deserialization: Code-Execution als System-User
  Mitigationen: Least Privilege, Sandboxing, Input Validation, Authorization Checks

STRIDE per Element:
  External Entities: STE__ (kein Denial of Service, keine Elevation)
  Processes:         STRIDE (alle Kategorien möglich)
  Data Stores:       _TRI__ (Tampering, Repudiation, Info Disclosure)
  Data Flows:        S_RID_ (Spoofing, Repudiation, Info Disclosure, DoS)

STRIDE-Workshop Anleitung (2h)

Vorbereitung (30min):
  → DFD Level 1 erstellen (gemeinsam mit Dev-Team)
  → Trust Boundaries einzeichnen
  → Teilnehmer: Dev-Lead, Security Champion, Product Owner

Analyse (60min):
  → Jedes DFD-Element durchgehen
  → STRIDE-Checkliste pro Element:
    Datenfluss HTTP GET /api/users:
    S: Wer authentifiziert sich? → JWT (aber: alg=none möglich?)
    T: Kann Response manipuliert werden? → TLS (aber: Zertifikat pinning?)
    R: Wird Request geloggt? → Ja, Audit Log
    I: Welche Daten werden übertragen? → User-Liste, PII?
    D: Rate Limiting vorhanden? → Nein → FINDING!
    E: Kann normaler User Admin-Daten sehen? → IDOR-Prüfung!

Priorisierung (30min):
  → DREAD-Score oder CVSS für jede Bedrohung
  → Eintrittswahrscheinlichkeit × Impact → Risikomatrix
  → Top 5 Bedrohungen → Security Requirements

PASTA-Framework

PASTA (Process for Attack Simulation and Threat Analysis):

PASTA ist risikobasiert und Business-orientiert:
→ 7-Phasen-Prozess (mehr Aufwand als STRIDE, aber umfassender)
→ Verbindet Business-Risiken mit technischen Bedrohungen
→ Attacke-zentriert: simulative Angreifer-Perspektive

Phase 1 - Define Objectives:
  → Business Objectives: Was soll das System leisten?
  → Security Objectives: Vertraulichkeit, Integrität, Verfügbarkeit
  → Compliance-Anforderungen: DSGVO, PCI DSS, NIS2
  Output: Scope-Dokument

Phase 2 - Define Technical Scope:
  → Systemarchitektur: alle Komponenten
  → Abhängigkeiten: Third-Party-APIs, Libraries
  → Attack Surface: Welche Eingabepunkte hat das System?
  Output: Technisches Systemdiagramm

Phase 3 - Application Decomposition:
  → DFD erstellen (wie STRIDE)
  → Datenklassifizierung: welche Daten werden verarbeitet?
  → Trust Levels: wer darf was?
  Output: DFD + Asset-Liste

Phase 4 - Threat Analysis:
  → Threat Intelligence: welche Bedrohungsakteure sind relevant?
  → TTPs (MITRE ATT&CK): welche Techniken nutzen Angreifer?
  → Historical Incidents: ähnliche Systeme wurden wie kompromittiert?
  Output: Threat-Library angepasst auf Kontext

Phase 5 - Vulnerability and Weakness Analysis:
  → SAST-Ergebnisse: bekannte Code-Schwachstellen
  → DAST-Ergebnisse: laufende Schwachstellen
  → CVE-Analyse für verwendete Bibliotheken
  → Mapping: Vulnerabilities → Threats aus Phase 4
  Output: Vulnerability-Threat-Mapping

Phase 6 - Attack Simulation:
  → Attack Trees: Wie kombiniert ein Angreifer Schwachstellen?
  → Attack Scenarios: "Angreifer kompromittiert DB via SQL Injection"
  → Exploitation Chains: mehrstufige Angriffe modellieren
  → Likelihood bewerten: wie wahrscheinlich ist dieser Angriff?
  Output: Attack Trees + Exploitation Scenarios

Phase 7 - Risk and Impact Analysis:
  → Business Impact: Was kostet Eintreten jedes Szenarios?
  → Residualrisiko nach Mitigationen
  → ROI der Sicherheitsmaßnahmen
  Output: Risikobericht + priorisierte Maßnahmenliste

PASTA vs. STRIDE:
  → STRIDE: schnell, strukturiert, developer-freundlich
  → PASTA: umfassend, Business-aligned, mehr Aufwand
  → Empfehlung: STRIDE für Sprint-Threat-Modeling, PASTA für System-Design

LINDDUN (Privacy-fokussiert)

LINDDUN - Threat Modeling für Datenschutz/Privacy:

Einsatz: Wenn DSGVO Art. 25 (Privacy by Design) gefordert ist
Sinnvoll für: Gesundheitsdaten, Zahlungsdaten, HR-Systeme

L - Linkability (Verknüpfung):
  Datenpunkte verknüpfbar → Profil erstellbar
  Beispiel: Tracking-Pixel in zwei verschiedenen Webshops → gleicher User
  Beispiel: Browser-Fingerprinting + Login + Kaufhistorie = Profil

I - Identifiability (Identifizierung):
  Person aus Daten identifizierbar (Re-Identifizierung)
  Beispiel: Kombination aus PLZ + Geburtsdatum + Geschlecht → eindeutig

N - Non-Repudiation (Nicht-Abstreitbarkeit):
  Person kann nicht abstreiten, dass Daten von ihr stammen (privacy-relevant)
  Beispiel: Detaillierte Logs verhindern Abstreitbarkeit - DSGVO-Problem!
  Beispiel: IP-Adresse eindeutig → Aktivitätsprotokoll nicht bestreitbar

D - Detectability (Entdeckung):
  Aktivitäten von Personen erkennbar
  Beispiel: Traffic-Analyse zeigt: "User kommuniziert mit HIV-Beratungsstelle"
  (auch ohne Inhalt zu kennen!)

D - Disclosure of Information (Datenweitergabe):
  Unbeabsichtigte Datenweitergabe
  Beispiel: API gibt mehr Daten zurück als notwendig (Excessive Data Exposure)

U - Unawareness (Unwissenheit):
  User weiß nicht, welche Daten gesammelt werden
  Beispiel: App sammelt Standortdaten ohne klare Information
  Beispiel: Keine Privacy Notice, unklare Cookie-Einwilligung

N - Non-Compliance (Nichteinhaltung):
  Verstoß gegen Datenschutzgesetze
  Beispiel: Fehlende Löschfristen, kein Betroffenenrechte-Prozess
  Beispiel: Keine Rechtsgrundlage für Verarbeitung (DSGVO Art. 6)

Wann LINDDUN:
  → Alle Systeme die personenbezogene Daten verarbeiten (fast alle!)
  → DSGVO-Datenschutz-Folgenabschätzung (DSFA) als Grundlage
  → Kombination mit STRIDE: technische + Datenschutz-Bedrohungen

DREAD-Scoring

DREAD - Risikobewertung für Bedrohungen:

Bewertung je 1-3 (niedrig/mittel/hoch):

D - Damage Potential:
  3 = kompletter System-Kompromiss
  2 = Datenverlust, Systemunterbrechung
  1 = minimaler Schaden

R - Reproducibility:
  3 = jederzeit reproduzierbar
  2 = gelegentlich reproduzierbar
  1 = selten reproduzierbar

E - Exploitability:
  3 = kein Spezialwissen, Script-Kiddie kann es
  2 = Erfahrener Angreifer nötig
  1 = Experte, spezifisches Wissen nötig

A - Affected Users:
  3 = alle Nutzer betroffen
  2 = viele Nutzer, wichtige Nutzer
  1 = wenige/unwichtige Nutzer

D - Discoverability:
  3 = öffentlich bekannt, in Default-Config
  2 = durch Testen auffindbar
  1 = schwer zu finden

Score: (D + R + E + A + D) / 5
→ 2.5-3.0 = Kritisch
→ 1.5-2.4 = Hoch
→ 1.0-1.4 = Mittel

Beispiel: SQL-Injection in Login:
  D=3 (DB-Zugriff), R=3 (deterministisch), E=2 (Sqlmap nötig),
  A=3 (alle Nutzer), D=3 (OWASP bekannt) → 2.8 = Kritisch

MITRE ATT&CK als Threat Modeling Referenz

ATT&CK-Integration in Threat Modeling:

Was ATT&CK bietet:
  → 193+ Techniken für Enterprise (Windows, macOS, Linux, Cloud)
  → Sub-Techniken für Details
  → Malware-Gruppen: welche TTPs nutzen APT28, Lazarus, etc.?
  → Mitigations: direkt pro Technik

ATT&CK-Mapping Beispiel (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):
  → Visuelle Darstellung welche TTPs für System-Typ relevant
  → Heatmap: häufig genutzte Techniken hervorheben
  → Export als JSON → in Threat-Modeling-Tool importieren

Threat Actor Mapping:
  # Welche APT-Gruppe targeting meinen Sektor?
  → Finanzsektor: Carbanak, Lazarus, FIN7
  → Gesundheitswesen: APT41, Dark Caracal
  → KRITIS/Energie: Sandworm, Dragonfly

Tools und Automatisierung

Threat Modeling Tools:

Microsoft Threat Modeling Tool (kostenlos):
  → Download: microsoft.com/en-us/securityengineering/sdl/tmtool
  → STRIDE-basiert, DFD-Editor integriert
  → Automatische Threat-Generierung aus DFD-Elementen
  → Reports: Word, PDF, HTML
  → Limitation: Windows-only, kein Collaboration

OWASP Threat Dragon (Open Source):
  → Web-basiert oder Desktop-App
  → DFD-Editor, STRIDE-Bedrohungen
  → GitHub-Integration (Threat Model als JSON in Repo)
  → Team-Collaboration: mehrere Personen bearbeiten

IriusRisk (kommerziell):
  → Enterprise-Grade Threat Modeling
  → JIRA/GitHub-Integration: Issues aus Bedrohungen
  → Bibliothek: vordefiniierte Threats für Technologien (AWS, Kubernetes, etc.)
  → Automatisierung: CI/CD-Pipeline-Integration

Threagile (Code-basiert, Open Source):
  → Threat Model als YAML-Datei definieren
  → Automatische Analyse und PDF-Report
  → Git-versionierbar (Infrastructure as Code Prinzip!)
  → CI/CD-Integration: Threat Modeling als Pipeline-Stage

  # Threagile YAML-Beispiel:
  title: "Web Application Threat Model"
  business_overview:
    description: "E-Commerce-Plattform für B2B-Kunden"
  technical_overview:
    description: "Three-Tier Web App mit 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 mit LINDDUN-Support

Threat Modeling in den SDLC integrieren

Integration in Entwicklungsprozess (Agile/Scrum):

Sprint 0 / Design Phase:
  → Neues Feature: 2h Threat Modeling Workshop
  → Teilnehmer: Dev-Lead, Security Champion, Product Owner
  → Output: Threat Model Dokument + Security Stories im Backlog

Kontinuierliche Updates:
  → Architekturänderungen: TM aktualisieren (auch kleine Änderungen!)
  → Neue Abhängigkeiten: Neue Attack Surface?
  → Incidents: Threat Model war falsch → korrigieren

Dokumentation:
  → STRIDE-Tabelle mit gefundenen Bedrohungen
  → Risikomatrix: Eintrittswahrscheinlichkeit × Impact
  → Gegenmaßnahmen mit Ticket-Links (JIRA, GitHub Issues)
  → Residualrisiko mit Akzeptanz-Unterschrift (CISO/Owner)

ROI von Threat Modeling:
  □ Bugs in Design-Phase: 10x günstiger als in Production
  □ Penetrationstest kürzer: Scope besser bekannt
  □ Security-Anforderungen klar: Entwickler wissen was zu implementieren
  □ Compliance: ISO 27001, DSGVO DSFA, BSI IT-Grundschutz
  □ Dokumentation: Architektur-Sicherheits-Entscheidungen nachvollziehbar

ISO 27001 Relevanz:
  A.5.8: Informationssicherheit im Projektmanagement
  A.8.25: Sicherer Entwicklungslebenszyklus
  A.8.26: Anforderungen an Anwendungssicherheit
  → Threat Models sind Nachweis für Sicherheitsanforderungen in der Entwicklung