Ein Entwicklungsteam kann ein Feature in einer Stunde per Threat Modeling analysieren, wenn es vier Fragen in der richtigen Reihenfolge beantwortet und am Ende Tickets statt eines Dokuments in der Hand hat. Die Fragen stammen aus dem Threat Modeling Manifesto: Woran arbeiten wir? Was kann schiefgehen? Was unternehmen wir dagegen? Haben wir gute Arbeit geleistet? Einen Security Architect braucht es dafür nicht, denn die Arbeit hängt nicht vom angeborenen Talent einer einzelnen Person ab.
Die Stunde auf einen Blick
| Minuten | Frage | Ergebnis |
|---|---|---|
| Vorab | - | Eine Person entwirft das Datenflussdiagramm |
| 0-10 | Woran arbeiten wir? | Korrigiertes Diagramm, nummerierte Entry Points |
| 10-30 | Was kann schiefgehen? | Bedrohungsliste, gruppiert nach STRIDE-Kategorien |
| 30-45 | Was unternehmen wir dagegen? | Eine Reaktion auf jede Bedrohung |
| 45-55 | Tickets und Tests | Pro Maßnahme ein Ticket und ein Test |
| 55-60 | Haben wir gute Arbeit geleistet? | Vollständigkeitsprüfung |
Vor der Session
Wählen Sie ein einzelnes Feature, nicht ein ganzes Produkt. Probleme im Design zu finden ist deutlich effizienter, als Schwachstellen in der Produktion zu beheben. Führen Sie die Session daher durch, bevor die Umsetzung beginnt.
Laden Sie einen Entwickler, den Anforderungsverantwortlichen und, falls Infrastruktur betroffen ist, jemanden aus dem Betrieb ein. Eine dieser Personen bringt den Entwurf eines Datenflussdiagramms mit, erstellt in einem Tool, dessen Dateien das Team später bearbeiten kann.
Minute 0-10: Woran arbeiten wir?
Die Gruppe korrigiert den Entwurf. Das OWASP Threat Modeling Cheat Sheet verlangt einen klaren Überblick über Trust Boundaries, Datenflüsse, Datenspeicher, Prozesse und externe Entitäten, die häufig mögliche Angriffspunkte darstellen. Prüfen Sie, dass jedes dieser Elemente auf dem Diagramm zu finden ist.
Falls einige Teilnehmende nicht technisch versiert sind, sammeln Sie die Datenflüsse lieber per Brainstorming am Whiteboard, statt auf DFD-Notation zu beharren.
Nummerieren Sie die Entry Points direkt mit, bei verschachtelten Einstiegspunkten in der Major.Minor-Notation (1, 1.2, 1.2.1), wie es auch die OWASP-Seite zum Community-Prozess tut, und markieren Sie ebenso die Exit Points. Eine Fehlermeldung auf einer Login-Seite kann Angriffe über den zugehörigen Entry Point ermöglichen, etwa Account Harvesting („Benutzername nicht gefunden“) oder SQL Injection (über SQL-Exception-Fehler).
Minute 10-30: Was kann schiefgehen?
Beginnen Sie bei einem technischen Design mit STRIDE. Gehen Sie jede Komponente, jeden Datenfluss und jede Trust Boundary anhand der sechs Kategorien durch und notieren Sie zu jeder Bedrohung, welche Entry-Point-ID sie berührt.
| Kategorie | Verletzt | Beispiel |
|---|---|---|
| Spoofing | Authentifizierung | Gestohlenes Authentifizierungstoken wird genutzt, um einen Benutzer zu imitieren |
| Tampering | Integrität | Unbeabsichtigte Datenbankänderungen über die Anwendung |
| Repudiation | Zurechenbarkeit | Logs werden manipuliert, um Aktionen zu verschleiern |
| Information Disclosure | Vertraulichkeit | Daten werden aus einer Datenbank mit Benutzerkonten extrahiert |
| Denial of Service | Verfügbarkeit | Benutzer wird durch viele fehlgeschlagene Anmeldeversuche ausgesperrt |
| Elevation of Privileges | Autorisierung | Ein manipuliertes JWT ändert die Rolle |
Bei einer Geschäftsregel ergänzen Sie Misuse Cases: Aktionen, die in falscher Reihenfolge, wiederholt, parallel oder für ein unbeabsichtigtes Ergebnis ausgeführt werden. Für ein mehrstufiges Angriffsziel nutzen Sie einen Attack Tree. Fügen Sie keine Techniken hinzu, nur um gründlich zu wirken. Begründen Sie, warum jede passt und was sie nicht abdeckt.
Eintrittswahrscheinlichkeit mal Schadenshöhe klingt sauber, doch beides lässt sich schwer schätzen, und das Produkt ignoriert die Kosten der Behebung. In einer Stunde genügt eine grobe Einstufung pro Bedrohung in hoch, mittel oder niedrig.
Ein durchgespieltes Beispiel: Passwort-Reset
Nehmen wir einen Passwort-Reset. Das Diagramm zeigt den Browser, die Webanwendung, die Benutzerdatenbank und einen Mailservice, mit einer Trust Boundary zwischen Internet und Anwendung. Die Reset-Anfrage ist Entry Point 3, der per E-Mail verschickte Link 3.1 (beispielhafte IDs).
Die Gruppe findet vier Bedrohungen. Ein Reset-Link funktioniert für jemand anderen als den Inhaber (Spoofing). Eine Meldung „Kein Konto mit dieser Adresse“ verrät, wer registriert ist (Information Disclosure). Reset-Ereignisse werden nicht protokolliert (Repudiation). Jemand löst wiederholt Resets gegen ein Opfer aus (Denial of Service).
Minute 30-45: Was unternehmen wir dagegen?
Jede Bedrohung erhält eine von vier Reaktionen:
- Mitigate (abschwächen): die Wahrscheinlichkeit senken, dass die Bedrohung eintritt.
- Eliminate (beseitigen): das Feature oder die Komponente entfernen, die sie verursacht.
- Transfer (übertragen): die vertragliche oder finanzielle Verantwortung auf eine andere Partei verlagern.
- Accept (akzeptieren): nichts unternehmen, weil die anderen Optionen nicht zu den geschäftlichen Rahmenbedingungen passen.
Ein Transfer senkt weder Eintrittswahrscheinlichkeit noch Schaden. Halten Sie deshalb fest, wer die verbleibenden Kontrollen und das Restrisiko verantwortet. Bei akzeptierten Bedrohungen dokumentieren Sie, wer das Risiko akzeptiert hat und warum.
Minute 45-55: Tickets und Tests
Überführen Sie jede vereinbarte Maßnahme in eine Anforderung, die ein Entwickler direkt aufgreifen kann. Eine Zeile pro Bedrohung genügt:
| Threat-ID | STRIDE | Ticket | Test |
|---|---|---|---|
| 3.1-S | Spoofing | Reset-Links einmalig verwendbar und kurzlebig machen | Ein benutzter oder abgelaufener Link wird abgelehnt |
| 3-I | Information Disclosure | Für jede Adresse eine einheitliche Antwort zurückgeben | Bekannte und unbekannte Adressen erhalten identische Antworten |
| 3-R | Repudiation | Jede Reset-Anfrage protokollieren | Ein Reset-Versuch erscheint im Log |
Die Testspalte macht das Modell zu mehr als einem Diagramm. Jede Maßnahme braucht eine Prüfung, die fehlschlägt, wenn die Kontrolle fehlt. Abuse Cases lassen sich direkt übersetzen: die Anfrage wiederholen (Replay), die Schritte in falscher Reihenfolge senden, zwei Anfragen gleichzeitig abschicken. Legen Sie die Tickets im eigenen Backlog des Features ab und nehmen Sie die Threat-ID in den Titel auf.
Minute 55-60: Haben wir gute Arbeit geleistet?
Beginnen Sie mit einer einfachen Prüfung: Gibt es Unterlagen, die ein Diagramm, eine Bedrohungsliste und eine Kontrollliste belegen? Fehlt eines davon, ist die Session nicht abgeschlossen. Bestätigen Sie, dass jede Bedrohung eine Reaktion hat, dass jede Maßnahme beschreibt, wie das Team sie umsetzt, und dass akzeptierte Risiken ihre Begründung enthalten.
Halten Sie das Modell danach aktuell. Aktualisieren Sie es zusammen mit dem System, und wenn sich das Design ändert, wiederholen Sie nur die betroffenen Teile.
Der Einstieg
- Wählen Sie ein anstehendes Feature und reservieren Sie eine Stunde mit einem Entwickler, dem Anforderungsverantwortlichen und jemandem aus dem Betrieb.
- Lassen Sie eine Person das Datenflussdiagramm mit eingezeichneten Trust Boundaries entwerfen. Die Gruppe korrigiert es und nummeriert in den ersten zehn Minuten die Entry Points.
- Gehen Sie 20 Minuten lang mit STRIDE jede Komponente und jeden Datenfluss durch und notieren Sie bei jeder Bedrohung die ID des betroffenen Entry Points.
- Weisen Sie jeder Bedrohung eine Reaktion zu, halten Sie fest, wer akzeptierte oder übertragene Risiken verantwortet, und erstellen Sie dann pro Maßnahme ein Ticket und einen Test.
- Legen Sie Diagramm, Bedrohungsliste und Kontrollliste bei der Dokumentation des Features ab. Wenn Sie eine externe Sicht auf das erste Modell wünschen, kann unser Beratungsangebot es prüfen, und die erfassten Bedrohungen eignen sich gut als Scope für einen späteren Penetrationstest.
