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?

Nach IBM Systems Sciences Institute wächst der Aufwand zur Behebung von Sicherheitsfehlern je nach Entdeckungszeitpunkt drastisch: Ein Fehler in der Design-Phase kostet den Faktor 1, in der Entwicklung Faktor 6, in Test und QA Faktor 15, in der Produktion Faktor 30-100 und nach einer Datenpanne bis zum Faktor 1000 (Bußgeld, Reputationsschaden, Forensik). Zwei Stunden Threat Modeling in der Design-Phase können hunderte Stunden nachträglicher Fixes ersparen.

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, bei dem Security, Dev und Business gemeinsam sprechen.

Threat Modeling ist kein Pentest-Ersatz (Pentests finden Implementierungsfehler), kein einmaliger Prozess (jede Architekturänderung erfordert ein Update) und keine Garantie, aber eine erhebliche Risikoreduktion.

Der wirkungsvollste Zeitpunkt ist die Design-Phase. Weitere sinnvolle Anlässe: Sprint-Beginn bei neuen Features (Agile Threat Modeling), vor einem Penetrationstest, nach einem Incident ("Was hätte TM erkannt?") und bei Systemänderungen (API-Änderung, neuer Drittanbieter).

Die vier Kernfragen

Was bauen wir? System-Dokumentation via DFD (Data Flow Diagram) oder Architekturdiagramm; Identifikation von Assets, Vertrauensgrenzen, Datenflüssen und Einstiegspunkten.
Was kann schiefgehen? Framework-basierte Bedrohungsidentifikation (STRIDE, PASTA etc.); Threat Intelligence (welche TTPs nutzen relevante Angreifer?); Attack Trees.
Was tun wir dagegen? Mitigationen für jede Bedrohung; Risikobewertung (Likelihood × Impact); Entscheidung: Mitigieren / Akzeptieren / Versichern / Vermeiden.
Haben wir es richtig gemacht? Review (alle Bedrohungen adressiert?); Validierung durch Penetrationstest; Update bei Systemänderungen.

Data Flow Diagramm (DFD)

Das DFD ist die Grundlage für alle Threat-Modeling-Methoden. Es verwendet vier Elemente: External Entity (Rechteck, z. B. Nutzer oder externe Systeme außerhalb der eigenen Kontrolle), Process (Oval, Software die Daten verarbeitet), Data Store (Doppellinie, z. B. Datenbank oder Datei) und Data Flow (Pfeil, Datenübertragung zwischen Elementen). Trust Boundaries (gestrichelte Linien) trennen Vertrauenszonen.

Zur Angriffsfläche: Jeder Datenflusspfeil ist ein potenzieller Angriffspunkt. Jede Trust-Boundary-Überquerung ist kritisch zu prüfen. External Entities müssen immer als potentiell "hostile" betrachtet werden.

DFDs werden in Detailtiefe gestaffelt: Level 0 als Kontextdiagramm (Systemgrenzen), Level 1 für Haupt-Komponenten und Datenflüsse, Level 2 für detaillierte interne Prozesse.

Geeignete Tools: OWASP Threat Dragon (kostenlos, web-basiert), Microsoft Threat Modeling Tool 2016 (Windows, STRIDE-integriert), draw.io mit Stencils (flexibel, Confluence-Plugin), PlantUML (code-basiert, Git-versionierbar) und Miro (Online-Whiteboard für Workshops).

STRIDE-Framework (Microsoft)

STRIDE ist ein von Microsoft entwickeltes Framework, das Bedrohungskategorien für jedes DFD-Element systematisch abfragt:

S - Spoofing (Identitätsvortäuschung): Kann ein Angreifer vorgeben, jemand anderes zu sein? Betrifft externe Akteure, Prozesse, Datenflüsse. Beispiele: JWT-Token fälschen (alg=none Attack), ARP-Spoofing, IP-Spoofing, Credential Stuffing. Mitigationen: starke Authentifizierung (MFA), TLS, HMAC.

T - Tampering (Datenmanipulation): Können Daten unbefugt verändert werden? Betrifft Datenflüsse und Datenspeicher. Beispiele: SQL Injection, HTTP-Parameter-Manipulation, Man-in-the-Middle, Config-File-Änderung. Mitigationen: Integritätsprüfung (HMAC, Signaturen), Input Validation.

R - Repudiation (Abstreitbarkeit): Kann jemand Aktionen abstreiten? Betrifft alle Interaktionen mit Außenwirkung. Beispiele: fehlende Audit Logs, nicht nachvollziehbare Admin-Aktionen. Mitigationen: unveränderliche Audit Logs, digitale Signaturen, separate Accounts.

I - Information Disclosure (Informationsoffenbarung): Können Daten unbefugt eingesehen werden? Betrifft Datenflüsse und Datenspeicher. Beispiele: Stack Traces in Fehlermeldungen, unverschlüsselte Übertragung, Directory Listing, IDOR (/api/users/1, /api/users/2). Mitigationen: Verschlüsselung, Zugriffskontrollen, Fehlerbehandlung.

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

E - Elevation of Privilege (Rechteausweitung): Kann jemand mehr Rechte erlangen als vorgesehen? Betrifft Prozesse und externe Akteure. Beispiele: SQL Injection zu DBA-Rechten, IDOR, JWT-Manipulation (role: "user" zu role: "admin"), Insecure Deserialization. Mitigationen: Least Privilege, Sandboxing, Input Validation, Authorization Checks.

Welche STRIDE-Kategorien auf welche DFD-Elemente zutreffen: External Entities (S, T, R), Processes (alle: S, T, R, I, D, E), Data Stores (T, R, I), Data Flows (S, R, I, D).

STRIDE-Workshop Anleitung (2h)

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

Analyse (60 min): Jedes DFD-Element mit der STRIDE-Checkliste durchgehen. Beispiel für den Datenfluss HTTP GET /api/users: S (Wer authentifiziert sich? JWT vorhanden - aber ist alg=none möglich?), T (Kann Response manipuliert werden? TLS vorhanden - 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 notwendig!).

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

PASTA-Framework

PASTA (Process for Attack Simulation and Threat Analysis) ist risikobasiert und Business-orientiert. Es verbindet Business-Risiken mit technischen Bedrohungen in einem 7-Phasen-Prozess und betrachtet Angriffe aus Angreifer-Perspektive.

Phase 1 - Define Objectives: Business- und Security-Objectives klären, Compliance-Anforderungen (DSGVO, PCI DSS, NIS2). Output: Scope-Dokument.
Phase 2 - Define Technical Scope: Systemarchitektur, Abhängigkeiten (APIs, Libraries), Angriffsfläche (Eingabepunkte). Output: technisches Systemdiagramm.
Phase 3 - Application Decomposition: DFD erstellen, Datenklassifizierung, Trust Levels. Output: DFD + Asset-Liste.
Phase 4 - Threat Analysis: Relevante Bedrohungsakteure via Threat Intelligence identifizieren, TTPs via MITRE ATT&CK, historische Vorfälle ähnlicher Systeme. Output: angepasste Threat-Library.
Phase 5 - Vulnerability and Weakness Analysis: SAST- und DAST-Ergebnisse, CVE-Analyse für verwendete Bibliotheken, Mapping von Vulnerabilities auf Threats aus Phase 4. Output: Vulnerability-Threat-Mapping.
Phase 6 - Attack Simulation: Attack Trees, Exploitation Chains (mehrstufige Angriffe modellieren), Likelihood-Bewertung. Output: Attack Trees + Exploitation Scenarios.
Phase 7 - Risk and Impact Analysis: Business Impact pro Szenario, Residualrisiko nach Mitigationen, ROI der Sicherheitsmaßnahmen. Output: Risikobericht + priorisierte Maßnahmenliste.

STRIDE eignet sich für schnelles, strukturiertes Threat Modeling auf Developer-Ebene; PASTA ist umfassender und Business-aligned, erfordert aber deutlich mehr Aufwand. Empfehlung: STRIDE für Sprint-Threat-Modeling, PASTA für System-Design.

LINDDUN (Privacy-fokussiert)

LINDDUN ist das Threat-Modeling-Framework für Datenschutz und Privacy. Es kommt zum Einsatz, wenn DSGVO Art. 25 (Privacy by Design) gefordert ist - also für praktisch alle Systeme, die personenbezogene Daten verarbeiten, sowie als Grundlage für die DSFA (Datenschutz-Folgenabschätzung).

L - Linkability: Können Datenpunkte verknüpft werden, sodass Profile entstehen? Beispiel: Tracking-Pixel in zwei Webshops erlaubt Identifikation desselben Nutzers.
I - Identifiability: Ist eine Person aus den Daten identifizierbar (Re-Identifizierung)? Beispiel: Kombination aus PLZ, Geburtsdatum und Geschlecht kann eindeutig sein.
N - Non-Repudiation: Kann eine Person nicht abstreiten, dass Daten von ihr stammen? Problematisch aus Datenschutzsicht: Detaillierte Logs verhindern Abstreitbarkeit.
D - Detectability: Sind Aktivitäten von Personen erkennbar, auch ohne Inhalte zu kennen? Beispiel: Traffic-Analyse zeigt Verbindung zu HIV-Beratungsstelle.
D - Disclosure of Information: Werden Daten unbeabsichtigt weitergegeben? Beispiel: API gibt mehr Daten zurück als notwendig (Excessive Data Exposure).
U - Unawareness: Weiß der Nutzer nicht, welche Daten gesammelt werden? Beispiel: App sammelt Standortdaten ohne klare Information; unklare Cookie-Einwilligung.
N - Non-Compliance: Verstoß gegen Datenschutzgesetze. Beispiel: Fehlende Löschfristen, kein Prozess für Betroffenenrechte, fehlende Rechtsgrundlage (DSGVO Art. 6).

LINDDUN und STRIDE ergänzen sich: STRIDE deckt technische Bedrohungen ab, LINDDUN die Datenschutz-Perspektive.

DREAD-Scoring

DREAD ist ein Bewertungsschema für Bedrohungen. Jede Kategorie wird mit 1 (niedrig), 2 (mittel) oder 3 (hoch) bewertet; der Gesamt-Score ergibt sich als Durchschnitt.

Kategorie	1 (niedrig)	2 (mittel)	3 (hoch)
D - Damage Potential	minimaler Schaden	Datenverlust, Unterbrechung	kompletter System-Kompromiss
R - Reproducibility	selten reproduzierbar	gelegentlich	jederzeit reproduzierbar
E - Exploitability	Experte nötig	erfahrener Angreifer	Script-Kiddie kann es
A - Affected Users	wenige/unwichtige	viele / wichtige	alle Nutzer
D - Discoverability	schwer zu finden	durch Testen auffindbar	öffentlich bekannt

Score-Interpretation: 2,5-3,0 = Kritisch, 1,5-2,4 = Hoch, 1,0-1,4 = Mittel.

Beispiel SQL-Injection im Login-Formular: D=3 (DB-Zugriff), R=3 (deterministisch), E=2 (sqlmap nötig), A=3 (alle Nutzer), D=3 (OWASP bekannt) → Score 2,8 = Kritisch.

MITRE ATT&CK als Threat Modeling Referenz

ATT&CK bietet für das Enterprise-Umfeld (Windows, macOS, Linux, Cloud) über 193 Techniken mit Sub-Techniken, Malware-Gruppen-Profile (welche TTPs nutzen APT28, Lazarus etc.?) sowie direkte Mitigationsempfehlungen pro Technik.

Beispiel für ein ATT&CK-Mapping einer Web-Applikation:

Taktik	Technik	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
Privilege Escalation	T1078 Valid Accounts	MFA, PAM
Collection	T1005 Data from Local System	DLP, Encryption

Der MITRE Navigator (attack.mitre.org/navigator) bietet eine visuelle Heatmap häufig genutzter Techniken und ermöglicht den Export als JSON für den Import in Threat-Modeling-Tools.

Für die Threat-Actor-Zuordnung zum eigenen Sektor: Finanzsektor (Carbanak, Lazarus, FIN7), Gesundheitswesen (APT41, Dark Caracal), KRITIS/Energie (Sandworm, Dragonfly).

Tools und Automatisierung

Microsoft Threat Modeling Tool (kostenlos): STRIDE-basierter DFD-Editor mit automatischer Threat-Generierung aus DFD-Elementen, Reports als Word/PDF/HTML. Einschränkung: Windows-only, keine Collaboration.

OWASP Threat Dragon (Open Source): Web-basiert oder Desktop-App, DFD-Editor, STRIDE-Bedrohungen, GitHub-Integration (Threat Model als JSON im Repo), Team-Collaboration.

IriusRisk (kommerziell): Enterprise-Grade mit JIRA/GitHub-Integration, vordefinierte Threats für Technologien (AWS, Kubernetes etc.), CI/CD-Pipeline-Integration.

Threagile (Code-basiert, Open Source): Threat Model als YAML-Datei, automatische Analyse und PDF-Report, Git-versionierbar, CI/CD-Integration.

# 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

In Agile/Scrum-Projekten findet Threat Modeling in Sprint 0 oder der Design-Phase statt: ein 2-stündiger Workshop mit Dev-Lead, Security Champion und Product Owner, dessen Output Threat-Model-Dokument und Security Stories im Backlog sind.

Kontinuierliche Updates sind bei Architekturänderungen, neuen Abhängigkeiten und nach Incidents (um das Threat Model zu korrigieren) erforderlich.

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

ROI von Threat Modeling: Bugs in der Design-Phase kosten 10x weniger als in der Produktion. Penetrationstests werden kürzer (Scope besser bekannt). Security-Anforderungen sind klar definiert. Compliance-Nachweise für ISO 27001, DSGVO DSFA und BSI IT-Grundschutz werden produziert.

ISO 27001 Relevanz: Threat Models sind Nachweis für Sicherheitsanforderungen in der Entwicklung gemäß A.5.8 (Informationssicherheit im Projektmanagement), A.8.25 (Sicherer Entwicklungslebenszyklus) und A.8.26 (Anforderungen an Anwendungssicherheit).