Threat Modeling: Angriffe antizipieren, bevor Code entsteht

Die meisten modernen Ansätze folgen dem Vier-Fragen-Rahmen von Adam Shostack („Threat Modeling: Designing for Security“, 2014): Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir gute Arbeit geleistet? Die vier Fragen strukturieren den Prozess in Systemmodellierung, Bedrohungsidentifikation, Maßnahmenableitung und Validierung – unabhängig davon, welche Methode im Einzelnen zum Einsatz kommt. Das Threat Modeling Manifesto definiert Threat Modeling entsprechend als Analyse von Repräsentationen eines Systems, um Bedenken hinsichtlich seiner Sicherheits- und Datenschutzeigenschaften herauszuarbeiten. Entscheidend ist der Perspektivwechsel: nicht prüfen, ob Anforderungen erfüllt sind, sondern systematisch fragen, was ein Angreifer mit dem Entwurf anfangen könnte.

STRIDE – 1999 von Loren Kohnfelder und Praerit Garg bei Microsoft formuliert und später Kernelement des Microsoft Security Development Lifecycle – kategorisiert Bedrohungen in sechs Klassen, die jeweils ein Schutzziel verletzen: Spoofing (Authentifizierung), Tampering (Integrität), Repudiation (Nicht-Abstreitbarkeit), Information Disclosure (Vertraulichkeit), Denial of Service (Verfügbarkeit) und Elevation of Privilege (Autorisierung). PASTA (Process for Attack Simulation and Threat Analysis; UcedaVélez/Morana, 2015) arbeitet dagegen risikozentriert: In sieben Stufen – von der Definition der Ziele über technischen Scope, Dekomposition, Bedrohungs- und Schwachstellenanalyse bis zu Angriffsmodellierung und Risiko-/Auswirkungsanalyse – verbindet die Methode simulierte Angriffe mit ihrer Geschäftsauswirkung. Attack Trees (Bruce Schneier, 1999) modellieren ein Angriffsziel als Wurzelknoten und zerlegen es über UND/ODER-Verknüpfungen in konkrete Angriffspfade, die sich etwa nach Kosten oder Erfolgswahrscheinlichkeit bewerten lassen. In der Praxis ergänzen sich die Ansätze: STRIDE für die systematische Breite, PASTA für die Risikoperspektive, Attack Trees für die Tiefenanalyse einzelner Szenarien.

Grundlage fast jeder Analyse ist ein Datenflussdiagramm (DFD): Externe Entitäten, Prozesse, Datenspeicher und Datenflüsse bilden das System ab, Vertrauensgrenzen markieren die Übergänge zwischen Zonen unterschiedlichen Vertrauens – etwa zwischen Internet und Backend oder zwischen Anwendung und Datenbank. An diesen Grenzen konzentrieren sich Bedrohungen, weshalb sie der natürliche Ausgangspunkt der systematischen Durchsprache sind. Bei komplexen Systemen sind mehrere Diagramme in unterschiedlicher Detailtiefe üblich: ein Überblick über das Gesamtsystem, ergänzt um Detailsichten auf kritische Komponenten. Das Diagramm bleibt dabei Mittel zum Zweck – ein Modell, das die Diskussion im Team trägt, ist wichtiger als perfekte Vollständigkeit.

2020 veröffentlichte eine Gruppe von 15 Fachleuten aus Praxis und Forschung das Threat Modeling Manifesto, bewusst angelehnt an das Agile Manifest. Es formuliert fünf Werte, unter anderem: eine Kultur des Findens und Behebens von Designproblemen statt Checkbox-Compliance, Menschen und Zusammenarbeit über Prozesse, Methoden und Werkzeuge sowie kontinuierliche Verfeinerung statt einmaliger Lieferung. Vier Prinzipien konkretisieren die Umsetzung – etwa, dass frühe und häufige Analyse Sicherheit und Datenschutz verbessert und dass Threat Modeling zu den Entwicklungspraktiken und Iterationen des Teams passen muss. Ergänzend benennt das Manifest förderliche Muster wie systematisches Vorgehen und vielfältige Blickwinkel sowie Anti-Patterns wie den „Hero Threat Modeler“ oder das Streben nach der perfekten Repräsentation.

Mit OWASP Threat Dragon steht ein freies Modellierungswerkzeug mit OWASP-Production-Status bereit, das als Web- und Desktop-Anwendung Diagramme erstellt und Bedrohungen unter anderem nach STRIDE, LINDDUN und PLOT4ai dokumentiert (aktuelle Version 2.6.2, Mai 2026); etabliert ist daneben das Microsoft Threat Modeling Tool. Einen anderen Weg geht OWASP pytm (Lab-Projekt): Die Architektur wird als Python-Code beschrieben, daraus generiert das Framework Datenflussdiagramme, Sequenzdiagramme und Bedrohungsreports. Dieses Threat-Modeling-as-Code macht Modelle versionierbar, im Code-Review prüfbar und in CI/CD-Pipelines automatisierbar – Architektur und Bedrohungsmodell durchlaufen denselben Änderungsprozess. Automatisierung ersetzt dabei nicht die gemeinsame Analyse im Team, sie skaliert sie: Generierte Bedrohungslisten sind Ausgangspunkt, nicht Endergebnis.

Das NIST Secure Software Development Framework (SP 800-218, Version 1.1) macht Bedrohungsmodellierung zum festen Bestandteil sicherer Entwicklung: Task PW.1.1 fordert Formen der Risikomodellierung – ausdrücklich etwa Threat Modeling, Attack Modeling oder Attack-Surface-Mapping – zur Bewertung des Sicherheitsrisikos einer Software. In agilen Teams funktioniert das nicht als einmaliger Großworkshop, sondern inkrementell: Sicherheitsrelevante Features, neue Schnittstellen oder Architekturänderungen lösen eine fokussierte Analyse aus, deren Ergebnisse ins Backlog fließen; als Kriterium in der Definition of Done verankert, wird die Bedrohungsanalyse zum Regelfall statt zur Ausnahme. Genau das fordert auch das Manifest: frühe und häufige Analyse, angepasst an die Iterationen des Teams. Für agentische KI-Systeme greifen klassische Methoden allerdings zu kurz – hierfür hat die Cloud Security Alliance 2025 mit MAESTRO ein eigenes, siebenschichtiges Framework vorgelegt, das wir in unserem Wissensbeitrag zu MAESTRO im Themenfeld Agentic-AI-Security vertiefen.