Ein effektives Threat-Modeling folgt einem strikt schematischen Ablauf in fünf Schritten. Dieser dient dazu, keine wichtigen Dinge innerhalb der Bedrohungsanalyse zu übersehen. In der konkreten Anwendung beinhaltet diese Analyse meist weitere detaillierte und zum Teil aufwendige Maßnahmen. Die grundsätzliche Vorgehensweise beim Threat-Modeling ist jedoch in jedem Falle gleich und läuft wie im folgt ab.
Schritt 1: Wie sieht die Entwicklung aus?
Zunächst skizzieren die Entwickler:innen Sinn und Einsatzzweck ihrer Anwendung. Anschließend geht es um die Frage, wie die Software konkret aussehen soll. Im Rahmen des Threat-Modeling geht es zunächst um die Darstellung der Software-Architektur mithilfe eines technischen Diagramms.
In der Anwendungsentwicklung kommen dabei meistens Datenflussdiagramme zum Einsatz. Mit diesen können die an der Risikoanalyse beteiligten Personen Schnittstellen und Datenflüsse visualisieren. Bedrohungen entstehen meistens dort, wo vorhandene Daten „fließen“, also von einer Instanz zu einer anderen geschickt oder von dieser angefordert werden.
Bei einer typischen Internetanwendung beispielsweise greifen User:innen über das Netz mittels der Applikation auf einen Proxy-Server zu. Dort lagern die Daten in einer Datenbank, die die Anwender:innen verwenden, verändern, abspeichern und gegebenenfalls versenden.
Um bei einem solchen Standardprozess mögliche Schwachstellen aufzudecken, sollten am ersten Schritt sowohl die Architekt:innen der Anwendungsinfrastruktur als auch Entwickler:innen und Systemadministrator:innen beteiligt sein. Erst durch deren unterschiedlichen Perspektiven auf den Aufbau der Anwendung entsteht ein Diagramm, das die benötigten Prozesse korrekt abbildet. Dies ist wichtig für die folgenden Schritte des Threat-Modelings.
Schritt 2: Was kann passieren?
Aufbauend auf dem Diagramm der Anwendung erfolgen im nächsten Schritt mögliche Szenarien, denen die Architektur ausgesetzt sein kann. Mithilfe von Annahmen grenzt dieser Schritt des Threat-Modelings mögliche Bedrohungen ein.
Grundlegende Fragen können zum Beispiel sein: Sind Bedrohungen beim Einsatz bestimmter Gerätekategorien auszuschließen? Sorgen aktuelle Betriebssysteme für den Ausschluss bestimmter Gefahren?
Aufbauend auf grundlegenden Fragen zum Einsatz einer Anwendung können theoretisch unendlich viele Detailprobleme überprüft werden. Beispiele bei einer Webanwendung sind:
Ist die Identität des Web-Servers der Benutzer:innen korrekt?
Können Benutzer:innen auch die Infrastruktur hinter dem Frontend sehen?
Können Dritte auf den Datentransfer zwischen Webanwendung und Proxy-Server zugreifen?
Verkraftet die Web-Applikation einen hohen Workload, etwa bei einem Online-Shop?
Sind User:innen nur zu Dingen berechtigt, die für sie vorgesehen sind?
Diese Liste kann je nach Anwendung viele weitere Fragen nach sich ziehen. Um allerdings keine wichtigen Dinge innerhalb dieses Prozesses zu übersehen, haben Entwickler:innen bei Microsoft die sogenannte „STRIDE-Methode“ etabliert. Damit entstehen Kategorien für die oben beispielhaft vorgestellten Fragen, die ein strukturiertes Vorgehen ermöglichen.
Üblicherweise folgt dieses Vorgehen demnach dem folgenden Prozess:
S = Spoofing (Identitätsverschleierung)
T = Tampering (Manipulation)
R = Repudiation (Verleugnung der Urheberschaft)
I = Information Disclosure (Datenpannen)
D = Denial of Service (Verweigerung des Dienstes)
E = Elevation of Privilege (Ausweitung der Rechte)
Jedwede Schnittstelle muss also bei der Überprüfung diesen sechs bei Angriffen üblichen Methoden standhalten. Ist dies nicht der Fall, liegt eine Bedrohung vor.