Threat Modeling

Was ist Threat Modeling¶

Threat Modeling ist ein systematischer Prozess zur Identifikation von Sicherheitsbedrohungen. Es geht nicht um Intuition oder die Erfahrung einer einzelnen Person — es ist eine strukturierte Methode, die sicherstellt, dass kritische Risiken nicht uebersehen werden.

Warum es wichtig ist¶

Die meisten Sicherheitsvorfaelle nutzen Schwachstellen aus, die beim Design erkennbar waren. SQL Injection, Broken Access Control, Insecure Direct Object References — das sind keine ausgefeilten Zero-Day-Angriffe. Es sind Design-Fehler, die ein Threat Model in Stunden aufdeckt.

Unser Ansatz: STRIDE + DREAD¶

STRIDE — Bedrohungskategorisierung¶

Fuer jede Systemkomponente analysieren wir sechs Kategorien:

• Spoofing — Kann ein Angreifer einen legitimen Benutzer oder Service imitieren? Wie verifizieren wir Identitaet?
• Tampering — Kann ein Angreifer Daten in Transit oder at Rest modifizieren? Ist die Datenintegritaet geschuetzt?
• Repudiation — Kann ein Benutzer eine Aktion abstreiten? Haben wir einen Audit Trail?
• Information Disclosure — Koennen sensible Daten lecken? Fehlermeldungen, Debug-Info, API-Antworten?
• Denial of Service — Kann ein Angreifer einen Service unverfuegbar machen? Rate Limiting, Resource Exhaustion?
• Elevation of Privilege — Kann ein Benutzer Berechtigungen erlangen, die er nicht hat? Horizontale und vertikale Eskalation?

DREAD — Risikopriorisierung¶

Jede identifizierte Bedrohung wird bewertet:

• Damage — Wie gross ist der Schaden? (1-10)
• Reproducibility — Wie leicht laesst sich der Angriff wiederholen? (1-10)
• Exploitability — Wie einfach ist die Schwachstelle auszunutzen? (1-10)
• Affected Users — Wie viele Benutzer sind betroffen? (1-10)
• Discoverability — Wie leicht ist die Schwachstelle zu finden? (1-10)

Der resultierende Score priorisiert, was zuerst angegangen wird. Critical (40-50), High (30-39), Medium (20-29), Low (10-19).

Attack Surface Mapping¶

Data Flow Diagram¶

Wir beginnen mit einer Karte des Systems: wo Daten entstehen, wie sie fliessen, wo sie gespeichert werden. Jede Trust Boundary (der Punkt, an dem sich der Sicherheitskontext aendert) ist dort, wo ein Angreifer nach einer Schwachstelle sucht.

Typische Trust Boundaries: - Internet ↔ Load Balancer (WAF) - Load Balancer ↔ API Gateway - API Gateway ↔ Backend Services - Backend ↔ Datenbank - Service ↔ Service (East-West Traffic) - CI/CD Pipeline ↔ Produktionsumgebung

Supply-Chain-Analyse¶

Die Angriffsflaeche ist nicht nur Ihr Code. Sie umfasst: - Abhaengigkeiten — npm-Pakete, NuGet, PyPI. Bekannte CVEs, Typosquatting, Dependency Confusion. - Container Images — Base Images, Multi-Stage Builds, Schwachstellen-Scanning. - CI/CD Pipeline — Build-Server-Credentials, Artefakt-Integritaet, Deployment Secrets. - Drittanbieter-Integrationen — API-Schluessel, Webhook-Endpunkte, OAuth Flows.

Workshop-Format¶

Tag 1: System Discovery¶

• Architektur-Ueberblick
• Data Flow Diagramme
• Identifikation von Trust Boundaries
• Asset-Inventar (Daten, Services, Infrastruktur)

Tag 2: Bedrohungsidentifikation¶

• STRIDE-Analyse pro Komponente
• Attack Tree-Konstruktion fuer kritische Szenarien
• Supply-Chain-Bedrohungsbewertung
• Business-Logik-Angriffsszenarien

Tag 3: Risikobewertung & Mitigierung¶

• DREAD-Scoring
• Risikopriorisierung
• Mitigierungsdesign
• Backlog-Integration

Output¶

1. Threat-Model-Dokument — Data Flow Diagramme, identifizierte Bedrohungen, DREAD-Scores, vorgeschlagene Mitigierungen
2. Security-Backlog — User Stories fuer Mitigierungs-Implementierung, priorisiert nach Risiko
3. Attack-Surface-Map — Visueller Ueberblick aller Einstiegspunkte und Trust Boundaries
4. Kontinuierlicher Prozess — Wie das Threat Model bei architektonischen Aenderungen aktualisiert wird

Automatisierung¶

Fuer groessere Systeme automatisieren wir Teile des Threat Modelings:

• IaC-Scanning — Terraform, Kubernetes-Manifeste → automatische Identifikation exponierter Services, fehlender Verschluesselung, zu freizuegiger RBAC
• API-Scanning — OpenAPI-Spec → automatische Identifikation fehlender Authentifizierung, Injection Points
• Dependency Scanning — Kontinuierliches Monitoring neuer CVEs in Abhaengigkeiten

Automatisierung ersetzt den Workshop nicht — sie ergaenzt ihn. Sie erkennt bekannte Muster; der Workshop deckt Business-Logik und architektonische Probleme auf.

Technologie und Tools¶

Microsoft Threat Modeling Tool, OWASP Threat Dragon, draw.io fuer DFD, Jira/Azure DevOps fuer Security Backlog, Snyk/Dependabot fuer Dependency Scanning, Trivy fuer Container Scanning, Custom STRIDE Templates.