Threat Modeling in der Praxis: STRIDE, PASTA und Attack Trees

Die meisten Sicherheitslücken entstehen nicht durch schlechten Code - sie entstehen durch schlechte Architektur-Entscheidungen. Wer erst nach dem Deployment über Sicherheit nachdenkt, schreibt teure Patches. Threat Modeling ist die Methode um Sicherheitsrisiken zu erkennen wenn sie noch billig zu beheben sind: im Design.

Was ist Threat Modeling?

Threat Modeling beantwortet vier Grundfragen:

1. Was bauen wir? - System-Diagramm: Komponenten, Datenflüsse, Vertrauensgrenzen
2. Was kann schiefgehen? - Bedrohungsidentifikation: was könnte ein Angreifer tun?
3. Was tun wir dagegen? - Gegenmaßnahmen: Mitigationen, Designänderungen, Akzeptanz
4. Haben wir das gut genug gemacht? - Review: sind alle Bedrohungen adressiert?

Wann durchführen

• Beim Design neuer Features (am wirkungsvollsten!)
• Beim Aufbau neuer Systemkomponenten
• Nach wesentlichen Architekturänderungen
• Regelmäßig für kritische Systeme (jährlich)
• VOR Security-Tests (gibt dem Pentest Fokus)

Output eines Threat Models

• Priorisierte Liste von Bedrohungen
• Konkrete Mitigationsmaßnahmen pro Bedrohung
• Security-Requirements für die Entwicklung
• Grundlage für Penetrationstest-Scope

Methode 1: STRIDE

STRIDE (Microsoft, Adam Shostack) kategorisiert Bedrohungen in sechs Klassen - ein Buchstabe pro Kategorie:

Kategorie	Bedeutung	Beispiel	Gegenmittel
S - Spoofing	Identitätsvorspiegelung	gefälschter JWT-Token, IP-Spoofing, ARP-Spoofing	Authentifizierung, MFA, mTLS, Signaturprüfung
T - Tampering	Manipulation von Daten oder Code	SQL-Injection, Parameter-Manipulation, MITM-Modifikation	Integritätsprüfung, HMAC, TLS, Prepared Statements
R - Repudiation	Ablehnung/Abstreitbarkeit	fehlende Audit-Logs, Log-Manipulation	Signierte Audit-Logs, Zeitstempel, unveränderliche Logs
I - Information Disclosure	Informationsleckage	Error-Messages mit Stack-Trace, unverschlüsselte Verbindung	Verschlüsselung, Minimal-Error-Messages, Zugriffskontrollen
D - Denial of Service	Verfügbarkeitsangriff	SYN-Flood, Resource-Exhaustion, ReDoS	Rate-Limiting, Auto-Scaling, WAF, CDN
E - Elevation of Privilege	Rechteausweitung	Privilege-Escalation, CSRF, Broken Access Control	Least-Privilege, Input-Validierung, Autorisierungsprüfung

STRIDE-Workshop-Prozess

Schritt 1: System-Diagramm erstellen (DFD - Data Flow Diagram)

DFD-Elemente:

• Prozesse (Kreise/Rechtecke): Softwarekomponenten
• Externe Entitäten (Rechtecke): User, externe Systeme
• Datenspeicher (Doppellinien): Datenbanken, Dateien
• Datenflüsse (Pfeile): HTTP, gRPC, SQL, Events
• Vertrauensgrenzen (gestrichelte Linien): DMZ, VPC, Auth-Grenzen

Beispiel E-Commerce-API:

[Browser] ──HTTP──> [API-Gateway] ──HTTP──> [Order-Service]
                                            ──SQL──> [Order-DB]
                    ────────────────────────> [Payment-Service]
                                            ──HTTPS──> [Stripe API]
─ ─ ─ Vertrauensgrenze: Internet / API-Gateway ─ ─ ─
─ ─ ─ Vertrauensgrenze: Microservices / Extern ─ ─ ─

Schritt 2: STRIDE pro Komponente anwenden

Für jeden Datenpfeil + jede Komponente: alle 6 STRIDE-Kategorien prüfen.

Beispiel - HTTP-Pfeil Browser → API-Gateway:

• S: Kann Angreifer gefälschte Identität senden? → JWT-Validierung nötig!
• T: Kann Request manipuliert werden? → HTTPS + Input-Validierung
• R: Werden alle API-Calls geloggt? → Audit-Log-Requirement
• I: Werden Tokens in Logs geschrieben? → Log-Masking
• D: Können viele Requests den Gateway überlasten? → Rate-Limiting
• E: Kann normaler User Admin-Endpoints aufrufen? → RBAC-Prüfung

Schritt 3: Mitigations-Tabelle

Bedrohung	STRIDE	Schwere	Mitigation	Status
JWT-Forging	S	Hoch	RS256, exp validation	OPEN
Log Disclosure	I	Mittel	Log-Masking für Tokens	DONE
Rate Limit Bypass	D	Hoch	Gateway Rate Limiting	OPEN

Methode 2: PASTA

PASTA (Process for Attack Simulation and Threat Analysis) ist ein risikobasierter Ansatz in 7 Schritten - business-impact-orientiert (nicht nur technisch), verbindet Geschäftsrisiken mit technischen Bedrohungen, aufwändiger als STRIDE aber ganzheitlicher.

Stage 1: Define Objectives (Geschäftsziele)

• Was sind die Business-Assets? (Kundendaten, Revenue, Reputation)
• Was sind Compliance-Anforderungen? (DSGVO, PCI-DSS, ISO 27001)
• Was wäre der Worst Case? (Datenpanne, Service-Ausfall, Strafzahlung)

Stage 2: Define Technical Scope

• System-Architektur-Diagramme
• Verwendete Technologien (Frameworks, Libraries, Cloud-Provider)
• Netzwerk-Topologie, Deployment-Umgebung

Stage 3: Application Decomposition

• Alle Komponenten identifizieren
• Datenflüsse kartieren
• Assets und deren Wert klassifizieren

Stage 4: Threat Analysis

Threat Actor Profiling - wer würde angreifen?

• Script Kiddie (niedriges Skill-Level, opportunistisch)
• Cyberkriminelle (motiviert durch finanziellen Gewinn)
• Insider (privilegierter Zugang)
• Nation-State-Akteur (hochspezialisiert, gezielt)

→ ATT&CK-Framework: welche TTPs passen?

Stage 5: Vulnerability Analysis

• SAST/DAST-Ergebnisse einfließen lassen
• CVE-Datenbank für verwendete Komponenten
• Konfigurationsschwächen

Stage 6: Attack Modeling

• Konkrete Angriffspfade modellieren
• Attack Trees für kritische Szenarien

Stage 7: Risk/Impact Analysis

• CVSS-Scoring für jede Bedrohung
• Business-Impact × Likelihood = Risk Score
• Priorisierte Mitigation-Roadmap

PASTA vs. STRIDE

Methode	Ansatz	Aufwand	Empfehlung
STRIDE	schnell, technisch fokussiert, per-Komponente	gering	Feature-Teams
PASTA	langsamer, business-aligned, ganzheitlich	hoch	Enterprise-Architecture-Reviews

Methode 3: Attack Trees

Attack Trees (Bruce Schneier): Angriffsziel als Wurzel, Wege zum Ziel als Äste.

Notation:

• Wurzel: Angriffsziel (z.B. “Admin-Account übernehmen”)
• AND-Knoten: ALLE Unterziele müssen erfüllt sein
• OR-Knoten: EINER der Wege genügt

Beispiel - Attack Tree: “Kundendaten exfiltrieren”

[Kundendaten exfiltrieren]
├── OR ─┬─ [Direkter DB-Zugriff]
│       │   AND ┬─ [DB-Port von Internet erreichbar]
│       │       └─ [Gültige DB-Credentials]
│       │           OR ┬─ [Default-Credentials]
│       │              ├─ [Credential-Leak aus Code-Repo]
│       │              └─ [SQL-Injection → DB-User]
│       │
│       ├─ [App-Level Datenleck]
│       │   OR ┬─ [IDOR: Fremde User-Daten abrufbar]
│       │      ├─ [API-Key-Leak in Error-Messages]
│       │      └─ [JWT-Bypass: claims manipulieren]
│       │
│       └─ [Admin-Zugang + Daten-Export]
│           AND ┬─ [Admin-Account kompromittiert]
│               │   OR ┬─ [Phishing + MFA-Bypass]
│               │      └─ [VPN-Brute-Force]
│               └─ [Export-Funktion nutzen]

Analyse

• Welche Äste haben die niedrigsten Kosten/Aufwand für Angreifer?
• Welche Mitigationen eliminieren die meisten Äste?
• CVSS-Scoring: welcher Ast hat höchste Ausnutzbarkeit?

Quantifizierung

Pro Blatt-Knoten schätzen:

• Difficulty: 1 (trivial) bis 10 (sehr schwer)
• Likelihood: % Chance dass Angreifer diesen Weg versucht
• Impact: 1-10 wenn erfolgreich

Berechnung:

• AND: Gesamt-Difficulty = Summe der Äste
• OR: Gesamt-Difficulty = Minimum der Äste (der einfachste Weg)

Threat Modeling Workshop Durchführen

Workshop-Setup (2-4 Stunden)

Teilnehmer (4-8 Personen ideal):

• Architect/Tech Lead (versteht System-Design)
• Security Engineer (kennt Angriffstechniken)
• Product Owner (kennt Business-Risiken)
• Senior Developer (kennt Implementierungsdetails)
• Optional: Pentesters als externe Perspektive

Tools:

Tool	Beschreibung
OWASP Threat Dragon	kostenlos, Web-App: DFD-Diagramme + automatische STRIDE-Generierung, JSON-Export für Git
Microsoft Threat Modeling Tool	kostenlos, Windows: Stencils für Azure, Web, Mobile
draw.io / Miro	für einfache DFDs im Team
Jira/Linear	für Mitigations als Tickets

Workshop-Ablauf

Phase 1 (30 Min): System-Diagramm zeichnen

• Gemeinsam DFD auf Whiteboard/Miro
• ALLE Datenflüsse, ALLE Komponenten, ALLE Vertrauensgrenzen
• Vorbild: kein Fluss darf undokumentiert bleiben

Phase 2 (60-90 Min): Bedrohungen identifizieren

• STRIDE pro Datenfluss und Komponente durchgehen
• “Was wenn…”-Fragen: Was wenn dieser JWT gefälscht wird?
• Brainstorming ohne Selbstzensur
• Alle Bedrohungen aufschreiben (auch vermeintlich absurde)

Phase 3 (30-45 Min): Priorisieren und Mitigationen

• Schwere × Likelihood → Risk Score
• Top 5-10 Bedrohungen: konkrete Maßnahmen definieren
• Als User Stories / Tickets formulieren
• Wer ist verantwortlich? Bis wann?

Phase 4 (15 Min): Review

• Haben wir alle Vertrauensgrenzen betrachtet?
• Gibt es externe Systeme die wir vergessen haben?
• Sind alle Mitigationen realistisch umsetzbar?

Häufige Fehler bei Threat Modeling Workshops

• Zu spät: System ist schon implementiert, hohe Änderungskosten
• Zu technisch: Business-Impact wird nicht bedacht
• Zu perfektionistisch: vollständig statt praktisch
• Keine Follow-ups: Findings landen im Nirgendwo
• Nur Sicherheitsteam: Entwickler müssen involviert sein!

Integration in den Entwicklungsprozess

Definition of Done (DoD) erweitern

Für Features mit Security-Relevanz:

• Threat Model erstellt
• Bedrohungen in Backlog als Security-Stories
• Kritische Mitigationen als Blocker vor Release

Security Design Review Checkliste

Vor jedem Architecture Review:

• DFD aktuell?
• Alle neuen Datenflüsse geprüft?
• Alle neuen Vertrauensgrenzen identifiziert?
• Alle Third-Party-Integrationen berücksichtigt?
• Compliance-Anforderungen berücksichtigt?

Threat Model Versionierung

• DFD + Mitigationsliste in Git (neben Code!)
• Bei jedem Major-Release: Threat Model Review
• Änderungen an Threat Model: PR-Prozess (Review!)
• OWASP Threat Dragon: JSON-Export für Git

Verbindung zu Pentests

Threat Model → Pentest-Scope!

• Tester wissen was das Team als kritisch bewertet
• Attack Trees → Pentest-Szenarien ableiten
• Gefundene Schwachstellen gegen Threat Model prüfen: War die Schwachstelle im Model? → Wenn nicht: Model aktualisieren!

Metriken

• Anzahl Threat Models pro Quartal (Prozess-Adoption)
• Verhältnis: Threats identifiziert vs. als Tickets umgesetzt
• Pentests die Threats aus dem Model bestätigen vs. neue Threats

---

Threat Modeling ist keine einmalige Aktivität - es ist ein kontinuierlicher Prozess der mit dem System wächst. Teams die regelmäßig Threat Modeling betreiben, entdecken Sicherheitslücken früher, priorisieren Sicherheitsmaßnahmen besser und kommunizieren Risiken klarer. AWARE7 begleitet Entwicklungsteams bei der Einführung von Threat Modeling als Teil des Security-Engineering-Programms.

Secure Development Workshop anfragen | Penetrationstest