Sicherheitslücken entstehen selten dort, wo man sie sucht. Viele sind Entwurfsfehler — falsche Annahmen darüber, wem man vertraut. Threat Modeling setzt genau da an: strukturiertes Durchdenken eines Entwurfs entlang von vier Fragen. Was bauen wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir gut genug gearbeitet?
Das Diagramm darf schlicht sein
Ausgangspunkt ist ein Datenflussdiagramm: Prozesse, Datenspeicher, externe Akteure, die Flüsse dazwischen. Kein Architekturkunstwerk — eine Skizze Browser → API → Datenbank reicht, um anzufangen.
Interessant wird sie durch die Trust Boundaries: die Linien, an denen sich das Vertrauensniveau ändert. Dort sitzen die Bedrohungen, weil dort Eingaben ankommen, denen man nicht trauen darf. Der häufigste Fehler in der Praxis ist banal und teuer: das interne Netz pauschal als vertrauenswürdig behandeln.
Sechs Kategorien statt spontaner Einfälle
STRIDE liefert das Raster — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Jede Kategorie zielt auf ein Schutzziel, von Authentizität bis Autorisierung. Man geht sie je Element und je Datenfluss durch, statt zu hoffen, dass einem im Meeting das Richtige einfällt.
Nicht alles gleich behandeln
Was gefunden wird, wird eingeordnet: Risiko grob als Wahrscheinlichkeit mal Auswirkung, daraus eine Reihenfolge. Ebenso wichtig ist der zweite Teil davon — Restrisiken, die man bewusst akzeptiert, gehören benannt und dokumentiert. Verwandt damit ist die Attack Surface: Jeder öffentliche Endpunkt, jeder Upload, jede Abhängigkeit ist eine Tür. Was nicht existiert, kann nicht angegriffen werden.
Mehr dazu im Seminar
Datenflussdiagramm, STRIDE am konkreten Beispiel und die Priorisierung zeigt das Modul Threat Modeling als praktische Methode — inklusive Video und Kapitelübersicht.
Zum Nachschlagen gibt es die STRIDE-Kategorien, die Risikomatrix und die Prinzipien gesammelt auf einer Seite: Security by Design — Cheat Sheet.