Threat Modeling ist ein strukturierter Prozess, um Bedrohungen und Sicherheitsrisiken eines Systems frühzeitig zu erkennen. Ein Team betrachtet schützenswerte Werte, Komponenten, Identitäten, Datenflüsse und Vertrauensgrenzen und fragt systematisch: Was kann schiefgehen, wie wahrscheinlich ist es und welche Kontrolle reduziert das Risiko? Besonders wertvoll ist dieser Blick während der Planung, weil eine Änderung am Design meist einfacher ist als eine spätere Reparatur im Betrieb.
Was ist das Ziel von Threat Modeling?
Das Ziel ist nicht, jede denkbare Angriffsidee zu sammeln. Threat Modeling soll die relevanten Annahmen und Risiken eines konkreten Systems sichtbar machen und zu überprüfbaren Entscheidungen führen. Ein gutes Ergebnis beantwortet, welche Assets besonders wichtig sind, über welche Wege sie angegriffen werden könnten, welche Gegenmaßnahmen vorgesehen sind und welche Restrisiken bewusst akzeptiert werden.
Damit verbindet Threat Modeling Architektur, Entwicklung und Security. Entwickler kennen die technischen Abläufe, Fachbereiche verstehen die Auswirkung eines Ausfalls oder Datenverlusts und Sicherheitsexperten bringen typische Angriffsmuster ein. Das Modell ist dadurch mehr als eine Checkliste: Es bildet die tatsächlichen Eigenschaften der Anwendung ab.
Welche Informationen werden benötigt?
| Information | Beispielfragen |
|---|---|
| Assets | Welche Daten, Funktionen oder Zugänge sind besonders schützenswert? |
| Akteure | Welche Benutzer, Administratoren, Fremdsysteme und Angreifer sind relevant? |
| Datenflüsse | Woher kommen Daten, wie werden sie verarbeitet und wohin werden sie übertragen? |
| Vertrauensgrenzen | Wo wechseln Daten zwischen Sicherheitszonen, Konten oder Verantwortungsbereichen? |
| Abhängigkeiten | Welche APIs, Cloud-Dienste, Bibliotheken und Identitätsanbieter werden vorausgesetzt? |
Häufig reicht zunächst ein verständliches Datenflussdiagramm. Es muss nicht jedes technische Detail enthalten, sollte aber externe Schnittstellen, Datenspeicher, Identitäten und Grenzen eindeutig zeigen. Unklare oder widersprüchliche Annahmen sind dabei selbst ein wertvolles Ergebnis.
Wie läuft Threat Modeling ab?
- System abgrenzen: Zweck, kritische Funktionen und betrachtete Komponenten festlegen.
- Architektur darstellen: Datenflüsse, Identitäten, Schnittstellen und Vertrauensgrenzen skizzieren.
- Bedrohungen bestimmen: Für Komponenten und Übergänge konkrete Missbrauchsmöglichkeiten formulieren.
- Risiko bewerten: Auswirkung, Realisierbarkeit, vorhandene Kontrollen und Exposition berücksichtigen.
- Maßnahmen planen: Risiken vermeiden, reduzieren, übertragen oder begründet akzeptieren.
- Umsetzung prüfen: Anforderungen in Tickets und Tests überführen und später verifizieren.
Welche Methoden gibt es?
STRIDE gruppiert Bedrohungen in Spoofing, Manipulation, Abstreitbarkeit, Offenlegung von Informationen, Denial of Service und Rechteausweitung. Die Methode eignet sich gut, um Komponenten und Datenflüsse systematisch zu prüfen. Attack Trees starten dagegen mit einem Angriffsziel und zerlegen mögliche Wege dorthin. Misuse Cases beschreiben aus Sicht eines Angreifers, wie eine legitime Funktion missbraucht werden könnte.
Keine Methode garantiert Vollständigkeit. Entscheidend ist, dass sie zum System und zum Team passt. Bei einer überschaubaren Webanwendung kann eine kompakte STRIDE-Sitzung genügen. Für komplexe Geschäftsprozesse oder besonders attraktive Ziele können Angriffsbäume und Erkenntnisse aus dem MITRE-ATT&CK-Framework zusätzliche Perspektiven liefern.
Wie werden Bedrohungen priorisiert?
Nicht jede gefundene Bedrohung benötigt dieselbe Aufmerksamkeit. Eine sinnvolle Bewertung bezieht die geschäftliche Auswirkung, den möglichen Schaden, die Erreichbarkeit des Systems, notwendige Voraussetzungen und bestehende Kontrollen ein. Eine einfach ausnutzbare Schwachstelle an einer öffentlich erreichbaren Administrationsschnittstelle ist in der Regel dringlicher als ein theoretischer Angriff, der bereits weitreichende interne Rechte voraussetzt. Wichtig ist eine nachvollziehbare Begründung statt einer scheinbar exakten Zahl.
Wann sollte das Modell aktualisiert werden?
Threat Modeling ist kein einmaliges Compliance-Dokument. Das Modell sollte bei neuen Schnittstellen, geänderten Authentifizierungswegen, sensibleren Daten, neuen externen Abhängigkeiten und wesentlichen Architekturänderungen erneut betrachtet werden. Auch Erkenntnisse aus einem Penetrationstest oder einem Sicherheitsvorfall können zeigen, dass Annahmen nicht mehr stimmen. Kleine, regelmäßig aktualisierte Modelle bleiben in der Praxis eher nutzbar als eine selten gepflegte Gesamtdokumentation.
Welche Fehler sollte man vermeiden?
Zu allgemeine Bedrohungen wie „Hacker greift an“ führen kaum zu einer konkreten Maßnahme. Ebenso wenig hilfreich ist ein Modell ohne Verantwortliche oder Nachverfolgung. Weitere typische Fehler sind das Ausblenden technischer Konten, ein zu großer Betrachtungsumfang und Sitzungen, an denen nur das Security-Team teilnimmt. Threat Modeling funktioniert am besten, wenn die Beteiligten das System tatsächlich kennen und aus jedem relevanten Risiko eine Entscheidung, Aufgabe oder dokumentierte Akzeptanz entsteht.
Vielen Dank für dein Feedback! Wir werden es prüfen und unseren Artikel anpassen.