Threat Modeling für Enterprise-Apps: Risiken erkennen, bevor sie teuer werden

Die meisten Security-Probleme, die ich in Audits finde, hätte man mit zwei Stunden Threat Modeling verhindern können. Keine Penetration-Tests, keine teuren Tools – nur ein Whiteboard, die richtigen Fragen und jemand, der sie stellt. Threat Modeling ist keine Raketenwissenschaft. Es ist strukturiertes Nachdenken über das, was schiefgehen kann.

Warum Threat Modeling?

Security-Bugs in Produktion zu fixen kostet im Schnitt 30x mehr als in der Design-Phase. Das ist keine Marketing-Zahl – das ist meine Erfahrung aus Dutzenden Rescue-Projekten. Ein SQL-Injection-Fix in der Entwicklung: 2 Stunden. Derselbe Fix nach einem Breach: Incident Response, Forensik, Kommunikation, Rechtsabteilung, PR, plus das eigentliche Patchen. Wochen.

Threat Modeling verschiebt Security nach links – in die Phase, wo Änderungen noch billig sind:

Phase	Kosten eines Security-Fixes
Design/Architektur	1x (Baseline)
Entwicklung	5x
Testing	10x
Produktion	30x
Nach Breach	100x+

Diese Eskalation sehe ich in Audits ständig – und sie ist fast immer vermeidbar, wenn man früh sauber denkt.

Die vier Grundfragen

Jedes Threat Model beantwortet vier Fragen:

1. Was bauen wir? – Systemgrenzen, Komponenten, Datenflüsse
2. Was kann schiefgehen? – Bedrohungen identifizieren
3. Was tun wir dagegen? – Mitigationen planen
4. Haben wir gute Arbeit geleistet? – Validierung

Klingt simpel. Ist es auch. Die Kunst liegt darin, die richtigen Leute im Raum zu haben und die richtigen Fragen zu stellen.

Schritt 1: Das System verstehen

Bevor Sie Bedrohungen identifizieren können, brauchen Sie ein Bild des Systems. Datenfluss-Diagramme (DFDs) sind das Standard-Werkzeug:

DFD-Elemente

• Externe Entitäten (Rechtecke): Benutzer, externe Systeme – alles außerhalb Ihrer Kontrolle
• Prozesse (Kreise): Ihre Anwendungslogik, Services, APIs
• Datenspeicher (parallele Linien): Datenbanken, Caches, Dateisysteme
• Datenflüsse (Pfeile): Was fließt wohin? Protokolle, Formate
• Trust Boundaries (gestrichelte Linien): Wo ändert sich das Vertrauensniveau?

┌─────────────┐     HTTPS/JWT      ┌─────────────┐
│   Browser   │ ──────────────────▶│  API Gateway │
│  (Extern)   │                    │   (DMZ)      │
└─────────────┘                    └──────┬──────┘
                                          │
                    - - - - - - - - - - - -│- - - - - - Trust Boundary
                                          │
                                          ▼
                                   ┌─────────────┐
                                   │ Order Service│
                                   │  (Intern)    │
                                   └──────┬──────┘
                                          │
                                          ▼
                                   ═══════════════
                                   ║  PostgreSQL  ║
                                   ═══════════════

Trust Boundaries sind der Schlüssel

Die wichtigsten Stellen im Diagramm sind die Trust Boundaries – dort, wo Daten von einer Vertrauenszone in eine andere wechseln:

• Internet → DMZ
• DMZ → Internes Netzwerk
• Anwendung → Datenbank
• Ihr Code → Third-Party-Library
• Frontend → Backend

An jeder Trust Boundary müssen Sie validieren, authentifizieren, autorisieren. Jede Boundary, die Sie übersehen, ist ein potenzielles Einfallstor.

Schritt 2: STRIDE – Bedrohungen systematisch finden

STRIDE ist ein Akronym, das Ihnen hilft, keine Bedrohungskategorie zu vergessen:

Buchstabe	Bedrohung	Verletztes Prinzip	Beispiel
S	Spoofing	Authentizität	Session Hijacking, gefälschte E-Mails
T	Tampering	Integrität	SQL Injection, Man-in-the-Middle
R	Repudiation	Nachweisbarkeit	Fehlende Audit-Logs, Logs manipulierbar
I	Information Disclosure	Vertraulichkeit	Datenleck, Error-Messages mit Stack Traces
D	Denial of Service	Verfügbarkeit	DDoS, Resource Exhaustion
E	Elevation of Privilege	Autorisierung	Privilege Escalation, IDOR

In Audits sehe ich STRIDE oft „abgehakt" – aber ohne Bezug zu echten Angriffswegen. Das ist Papier-Security. Der Wert entsteht erst, wenn Sie für jede Kategorie konkret fragen: Wie würde ein Angreifer das bei uns ausnutzen?

STRIDE pro Element anwenden

Gehen Sie jedes Element im DFD durch und fragen Sie für jede STRIDE-Kategorie:

Für: API Gateway

[S] Spoofing: Kann jemand sich als legitimer User ausgeben?
    → Prüfen: Token-Validierung, Session-Management

[T] Tampering: Können Requests manipuliert werden?
    → Prüfen: Input-Validierung, HTTPS

[R] Repudiation: Können Actions abgestritten werden?
    → Prüfen: Audit-Logging, Request-IDs

[I] Info Disclosure: Leaken wir sensible Daten?
    → Prüfen: Error-Handling, Response-Headers

[D] DoS: Kann das Gateway überlastet werden?
    → Prüfen: Rate Limiting, Timeouts

[E] Elevation: Kann jemand auf fremde Ressourcen zugreifen?
    → Prüfen: Autorisierung pro Endpoint

Schritt 3: Risiken bewerten

Nicht jede Bedrohung ist gleich kritisch. DREAD ist ein einfaches Scoring-Modell:

• Damage: Wie groß ist der Schaden?
• Reproducibility: Wie leicht reproduzierbar?
• Exploitability: Wie leicht ausnutzbar?
• Affected Users: Wie viele betroffen?
• Discoverability: Wie leicht zu entdecken?

Jede Kategorie 1-10, Summe ergibt Priorität. Pragmatisch: High/Medium/Low reicht oft.

Schritt 4: Mitigationen definieren

Für jede priorisierte Bedrohung dokumentieren Sie die Gegenmaßnahme:

Bedrohung	STRIDE	Risiko	Mitigation	Status
JWT ohne Expiry	S, E	High	Token-Expiry auf 15min, Refresh-Token-Rotation	Offen
SQL Injection in Search	T, I	Critical	Prepared Statements, Input-Validierung	In Arbeit
Fehlende Rate Limits	D	Medium	Rate Limiting im API Gateway	Done
Logs ohne User-ID	R	Medium	Correlation-ID + User-ID in jedem Log	Offen

Wichtig: Jede Mitigation braucht Owner + Deadline – sonst bleibt „Offen" ein Dauerzustand.

Enterprise-spezifische Bedrohungen

In Enterprise-Umgebungen kommen Bedrohungen hinzu, die im Standard-STRIDE untergehen:

Insider Threats

Der größte blinde Fleck. Die meisten Threat Models nehmen externe Angreifer an – aber Insider haben bereits Zugang:

• Entwickler mit Prod-Zugang
• Admins mit Master-Keys
• Support-Mitarbeiter mit Kundenimpersonation
• Auftragnehmer mit VPN-Zugang

Supply Chain Attacks

Ihre Abhängigkeiten sind Teil Ihrer Angriffsfläche:

• NPM/Maven/Composer-Packages
• Docker-Base-Images
• CI/CD-Pipeline-Tools
• SaaS-Integrationen mit API-Keys

# Fragen für Supply Chain Threat Modeling:
- Wer kann unsere Dependencies ändern?
- Wie prüfen wir Integrity? (Lock-Files, Signaturen)
- Welche Berechtigungen haben Third-Party-Actions?
- Wer hat Zugang zu unseren CI/CD-Secrets?

Lateral Movement

In Enterprise-Architekturen mit vielen Services: Was passiert, wenn ein Service kompromittiert wird?

• Service-to-Service-Authentifizierung (mTLS, Service Mesh)
• Network Segmentation
• Secrets-Rotation
• Blast Radius Minimierung

Threat Modeling Workshop durchführen

Ein typischer Workshop dauert 2-4 Stunden:

Wer muss dabei sein?

• Architekt/Tech Lead: Kennt das Gesamtsystem
• Entwickler: Kennen die Implementierungsdetails
• Security-Experte: Stellt die unbequemen Fragen
• Product Owner: Kennt die Business-Kritikalität

Ohne Entwickler wird Threat Modeling akademisch. Ohne Security wird es naiv.

Agenda

1. 30 min: System verstehen, DFD erstellen/aktualisieren
2. 60 min: STRIDE durchgehen, Bedrohungen sammeln
3. 30 min: Priorisieren (High/Medium/Low)
4. 30 min: Mitigationen definieren, Verantwortliche festlegen
5. 15 min: Nächste Schritte, Follow-up-Termin

Dokumentation

Das Ergebnis muss leben – nicht in einem Confluence-Grab verschwinden:

• DFD im Code-Repository (PlantUML, Mermaid)
• Bedrohungen als Issues im Backlog
• Mitigationen in der Definition of Done
• Quartalsmäßige Review-Termine

Tools

• Microsoft Threat Modeling Tool: Kostenlos, STRIDE-basiert, generiert Reports
• OWASP Threat Dragon: Open Source, Web-basiert
• IriusRisk: Enterprise-Tool mit Compliance-Mappings
• Whiteboard + Post-Its: Unterschätzt. Oft das effektivste Tool.

Typische Fehler

1. Einmal und nie wieder

Ein Threat Model, das bei Projektstart erstellt und nie aktualisiert wird, ist wertlos. Jedes neue Feature, jede neue Integration ändert die Angriffsfläche.

Lösung: Threat Modeling als Teil des Design-Reviews für signifikante Changes.

2. Zu abstrakt

"Ein Angreifer könnte Daten stehlen" ist keine nützliche Bedrohung. Ohne konkreten Angriffsvektor keine konkrete Mitigation.

Lösung: Immer fragen: Wie genau? Welcher Endpunkt? Welche Daten? Welche Vorbedingungen?

3. Keine Follow-through

Das schönste Threat Model hilft nichts, wenn die identifizierten Risiken nie gefixt werden.

Lösung: Bedrohungen als Tickets mit Priorität. High-Risk-Items blockieren das Release.

Fazit

Threat Modeling ist keine einmalige Übung, sondern eine Denkweise. Es zwingt Sie, die Perspektive des Angreifers einzunehmen – bevor der echte Angreifer das für Sie tut.

• Früh anfangen: In der Design-Phase, nicht nach dem Release
• Systematisch vorgehen: STRIDE + DFD als Struktur
• Priorisieren: Nicht alles ist gleich kritisch
• Umsetzen: Findings müssen ins Backlog und erledigt werden
• Wiederholen: Bei jeder signifikanten Änderung

Häufige Fragen

Wie oft sollten wir Threat Modeling machen?

Initial bei Projektstart, dann bei jeder größeren Architekturänderung. Minimum: einmal pro Jahr komplettes Review. Bei regulierten Branchen (Finanz, Healthcare) oft quartalsweise.

Brauchen wir einen Security-Experten?

Für die ersten Sessions: ja. Der Wert liegt darin, blinde Flecken aufzudecken, die das Team selbst nicht sieht. Nach ein paar Runden kann das Team es selbst – mit gelegentlichem externen Review.

Wie detailliert muss das DFD sein?

Detailliert genug, um alle Trust Boundaries zu zeigen. Zu detailliert wird unübersichtlich. Faustregel: Wenn es nicht auf ein Whiteboard passt, ist es zu komplex – dann in Teilsysteme aufbrechen.

Was machen wir mit Legacy-Systemen ohne Dokumentation?

Reverse Engineering durch Netzwerk-Traces, Code-Analyse, Entwickler-Interviews. Ist aufwändig, aber genau hier liegen oft die größten Risiken. Legacy ohne Threat Model = tickende Zeitbombe.

---