Threat Modeling als praktische Methode

Threat Modeling als praktische Methode

0:00 Bis hierhin haben wir viel über Haltung und Vorarbeit gesprochen: Sicherheit gehört in den Entwurf, und man muss wissen, was man schützt und vor wem. Jetzt kommt die Methode, die das zusammenführt. Threat Modeling hat einen Ruf, der ihm schadet — es klingt nach schweren Werkzeugen, Zertifikaten und einem Spezialisten, den man einfliegen lässt. Das ist es nicht.

0:20 Im Kern ist es ein strukturiertes Gespräch am Whiteboard, für das ein Team ein paar Stunden braucht. Was es liefert, ist die Antwort auf die einfachste und unbequemste Frage der Softwareentwicklung: Was kann hier eigentlich schiefgehen?

Threat Modeling als praktische Methode

0:34 Wir gehen den Weg der Methode entlang. Zuerst der Systemkontext — was bauen wir hier überhaupt? Dann das Datenflussdiagramm mit Komponenten, Flüssen und Vertrauensgrenzen. Danach die Angriffsfläche, also alle Punkte, an denen jemand mit dem System reden kann. Mit STRIDE bekommen wir ein Raster, um systematisch nach Bedrohungen zu suchen, statt uns auf Einfälle zu verlassen.

0:57 Und zum Schluss die Priorisierung, denn gefunden ist noch nicht behoben. Vier Dinge nehmen Sie aus diesem Kapitel mit. Erstens Threat Modeling als strukturierte Frage statt als Zeremonie — zwei Fragen tragen die halbe Methode: Was bauen wir, und was kann schiefgehen? Zweitens den Weg vom Systembild über die Datenflüsse zu den Vertrauensgrenzen; das klingt technisch, ist aber vor allem eine Übung im Sichtbarmachen von Annahmen.

1:22 Drittens STRIDE als Denkraster, das Ihnen Kategorien vorgibt, damit Sie nicht nur die Bedrohungen finden, an die Sie ohnehin schon gedacht hätten. Und viertens die Priorisierung: begründet statt aus dem Bauch, denn Ihr Budget ist endlich.

Threat Modeling und Systemkontext

1:36 Fangen wir mit dem Rahmen an. Bevor man ein System bedrohen kann, muss man sich darüber einig sein, was man eigentlich gebaut hat — und Sie werden überrascht sein, wie oft genau darüber im Team keine Einigkeit herrscht. In fast jedem Threat-Modeling-Workshop gibt es diesen Moment, in dem zwei Leute dasselbe System sehr unterschiedlich beschreiben.

1:56 Allein diesen Moment herbeizuführen, rechtfertigt den Aufwand schon. Threat Modeling ist das strukturierte Durchdenken eines Entwurfs entlang von vier Fragen: Was bauen wir? Was kann schiefgehen? Was tun wir dagegen? Und haben wir gut genug gearbeitet? Diese Schlichtheit ist Absicht — die vier Fragen stammen von Adam Shostack und haben sich gerade deshalb durchgesetzt, weil man sie sich merken kann.

2:20 Der Vergleich, der hier trägt: Es ist wie die Sicherheitsbesprechung vor einer Bergtour. Man geht die Route ab, bevor man losläuft, und fragt an jeder Stelle, was dort passieren könnte. Niemand braucht dafür ein Zertifikat — nur die Bereitschaft, unbequeme Fragen zu stellen, solange es noch billig ist. Der offensichtliche Nutzen: Threat Modeling findet Entwurfsfehler, bevor Code existiert — und wir haben in Kapitel 1 gesehen, wie viel das an Kosten spart.

2:47 Der weniger offensichtliche ist mir fast wichtiger: Es macht implizite Annahmen über Vertrauen sichtbar. In jedem Team gibt es Sätze wie "das kommt ja aus unserem eigenen Service" — und niemand hat je geprüft, ob das stimmt. Dazu kommt die Priorisierung: Sie erfahren, wo Sicherheitsaufwand tatsächlich wirkt. Und schließlich der soziale Effekt, der in keiner Metrik auftaucht: Nach einem gemeinsamen Threat-Modeling-Workshop hat das Team ein geteiltes Bild vom eigenen System.

3:15 Allein das ist die Stunden wert. Fünf Schritte, die den Bogen dieses Kapitels beschreiben. Erst halten Sie fest, was das System tut und wofür es da ist. Dann zeichnen Sie es — Komponenten, Datenflüsse, Grenzen. Im dritten Schritt gehen Sie mit STRIDE Element für Element durch und suchen Bedrohungen. Viertens leiten Sie Gegenmaßnahmen ab und bringen sie in eine Reihenfolge.

3:38 Der fünfte Schritt wird am häufigsten übersprungen und ist doch entscheidend: das Ergebnis überprüfen und aktuell halten. Ein Threat Model von vor zwei Jahren beschreibt ein System, das es so nicht mehr gibt. Und noch ein Hinweis zur Entlastung: Ein leichtgewichtiges Diagramm genügt als Ausgangspunkt. Whiteboard und Foto reichen völlig.

Komponenten, Datenflüsse und Trust Boundaries

3:59 Damit zum Herzstück der Methode: dem Datenflussdiagramm. Es ist bewusst simpel gehalten — und gerade deshalb funktioniert es auch in einer Runde, in der nicht alle Architekturdiagramme lesen. Vier Symbole, ein paar Pfeile, eine gestrichelte Linie: Mehr braucht es nicht, damit Produktverantwortliche, Entwicklung und Betrieb über dasselbe Bild reden.

4:19 Und genau diese gemeinsame Sicht ist die Voraussetzung dafür, dass die Bedrohungssuche gleich funktioniert. Ein Datenflussdiagramm zeigt vier Arten von Dingen: Prozesse, Datenspeicher, externe Akteure und die Flüsse dazwischen. Mehr Notation brauchen Sie nicht. Der eigentlich wichtige Begriff ist die Trust Boundary — die Linie, an der sich das Vertrauensniveau ändert. Ein Bild: Es ist die Grenzkontrolle am Flughafen.

4:45 Innerhalb des Sicherheits- bereichs gelten andere Regeln als davor, und genau an der Übergangsstelle wird geprüft. In der Software ist es dasselbe: An dieser Linie lauern die interessanten Bedrohungen, weil dort Daten aus einer weniger vertrauenswürdigen Zone in eine vertrauenswürdigere übertreten. Wo keine Grenze eingezeichnet ist, gibt es meist trotzdem eine — sie ist nur unbewacht.

5:08 Warum steht das Diagramm so im Zentrum? Weil sich Bedrohungen an Vertrauensgrenzen konzentrieren — wer die Grenzen kennt, weiß, wo er hinschauen muss, und muss nicht das ganze System gleichmäßig misstrauisch betrachten. Zweitens zeigen Datenflüsse sehr konkret, wo Eingaben validiert werden müssen: an jedem Pfeil, der eine Grenze überquert.

5:28 Und drittens, der eigentliche Erkenntnisgewinn: Explizite Grenzen entlarven implizites Vertrauen. Sobald Sie die Linie zeichnen müssen, kommt die Frage auf den Tisch, warum dieser Dienst jenem eigentlich glaubt. Diese Frage laut zu stellen ist oft schon der halbe Ertrag des Workshops. Die Skizze zeigt den einfachsten denkbaren Fall: ein Browser, ein API-Server, eine Datenbank — und mittendrin eine gestrichelte Linie. Genau diese Linie ist die Botschaft.

5:56 Alles rechts von ihr vertraut dem Browser nicht, und zwar aus einem handfesten Grund: Der Browser läuft auf einem fremden Gerät, das Ihnen nicht gehört. Jede Prüfung, die dort stattfindet, kann umgangen werden. Worauf es hier ankommt, ist nicht die Notation — malen Sie Kästen und Pfeile, wie Sie wollen. Es ist die Gewohnheit, an jeder solchen Linie zwei Fragen zu stellen: Wer darf hier was, und wird die hereinkommende Eingabe geprüft?

6:21 Wenn Sie das konsequent tun, haben Sie einen Großteil der typischen Lücken schon abgedeckt. Drei Fallen beim Zeichnen. Die erste kennen wir schon: das interne Netz pauschal als vertrauenswürdig behandeln — im Diagramm sieht man das daran, dass zwischen internen Diensten keine einzige Grenze eingezeichnet ist. Die zweite ist tückischer: vergessene Datenflüsse zu Drittdiensten.

6:44 Analyse-Werkzeuge, Zahlungsdienstleister, Log-Aggregatoren — sie tauchen selten im Architekturbild auf, obwohl über sie regelmäßig Daten das Haus verlassen. Und die dritte ist eine Frage der Pflege: Ein Diagramm, das einmal gezeichnet und nie aktualisiert wurde, ist schlimmer als keins. Es erzeugt Sicherheit über einen Systemzustand, den es längst nicht mehr gibt.

Attack Surface

7:07 Von den Grenzen zur Fläche. Wenn wir wissen, wo die Übergänge sind, lohnt der Blick darauf, wie viele Türen es insgesamt gibt — und ob wir wirklich alle brauchen. Diese zweite Frage ist die interessantere, denn sie führt zu der einzigen Sicherheitsmaßnahme, die nichts kostet und dauerhaft wirkt: etwas wegzulassen. In gewachsenen Systemen ist da erfahrungsgemäß einiges zu holen.

7:29 Die Attack Surface, die Angriffsfläche, ist die Summe aller Punkte, an denen jemand mit Ihrem System interagieren kann: Endpunkte, Eingabefelder, Schnittstellen, offene Ports, aber auch Abhängigkeiten. Der letzte Punkt wird gern übersehen — jede Bibliothek, die Sie einbinden, vergrößert die Fläche, obwohl Sie ihren Code nie gesehen haben.

7:48 Das Bild dazu ist naheliegend: Ein Haus mit zwanzig Fenstern ist schwerer zu sichern als eines mit vieren, unabhängig davon, wie gut die einzelnen Fenster schließen. Und ein Fenster, das man zumauert, muss man nie wieder prüfen. Das ist der Grund, warum Reduktion in der Sicherheit fast immer die effizienteste Maßnahme ist.

8:07 Die Argumente sind angenehm handfest. Eine kleinere Angriffsfläche bedeutet schlicht weniger, was Sie verteidigen, überwachen und aktuell halten müssen — dauerhaft, nicht nur einmalig. Ungenutzte Endpunkte und Features sind dabei besonders ärgerlich: Sie tragen kein Risiko mit Gegenwert, weil ihnen kein Nutzen gegenübersteht.

8:26 Sie sind einfach da, oft aus einem Projekt, das nie fertig wurde. Und der dritte Punkt ist die Voraussetzung für alles andere: Sie können nur härten, was Sie kennen. Deshalb ist die erste Übung meist eine Bestandsaufnahme — und die fördert in gewachsenen Systemen regelmäßig Dinge zutage, von denen niemand mehr wusste, dass es sie gibt.

8:46 Beachten Sie, dass die rechte Spalte keine Maßnahmen enthält, sondern Fragen. Das ist Absicht. Sie sollen nicht eine Liste abarbeiten, sondern für jedes Element prüfen, ob es überhaupt bleiben muss. Öffentliche Endpunkte: Wird jeder wirklich gebraucht, oder stammt einer aus einem alten Client? Eingaben und Uploads: Wird serverseitig validiert — serverseitig, weil alles im Browser umgehbar ist. Ports und Dienste: Muss das nach außen, oder reicht intern?

9:15 Abhängigkeiten: aktuell und minimal? Die Fußzeile fasst das Prinzip in einem Satz zusammen, den man sich merken sollte: Was nicht existiert, kann nicht angegriffen werden. Löschen ist die billigste Sicherheitsmaßnahme.

Einführung in STRIDE

9:29 Wir wissen jetzt, wo wir suchen müssen. Bleibt die Frage, wonach. Genau dafür gibt es STRIDE — ein Raster, das verhindert, dass Sie nur die Bedrohungen finden, die Ihnen ohnehin einfallen. Denn das ist die eigentliche Schwäche des freien Brainstormings: Es fördert zuverlässig zutage, was das Team schon einmal erlebt hat, und übersieht ebenso zuverlässig alles andere.

9:51 Ein Raster zwingt zu den unbequemen Fragen. STRIDE ist ein Akronym für sechs Bedrohungskategorien. Sein Wert liegt weniger in den Kategorien selbst als in der Systematik: Sie gehen jedes Element Ihres Diagramms durch und fragen für alle sechs, ob hier etwas schiefgehen kann. Der Unterschied zum spontanen Brainstorming ist erheblich. Ohne Raster findet ein Team, was es kennt — und das sind meist die Bedrohungen aus dem letzten Vorfall.

10:17 Mit Raster kommen auch die unbequemen Kategorien dran, an die niemand von selbst gedacht hätte. Es ist wie eine Checkliste im Cockpit: nicht, weil Piloten vergesslich sind, sondern weil Systematik unter Zeitdruck schlägt, was man im Kopf hat. Die eigentliche Eleganz steckt in der rechten Spalte. Jede Bedrohungskategorie ist die Verletzung genau eines Schutzziels — Spoofing greift die Authentizität an, Tampering die Integrität, und so weiter.

10:43 Das ist kein Zufall, sondern Konstruktionsprinzip, und für Sie praktisch: Sobald Sie eine Bedrohung einer Kategorie zuordnen, wissen Sie auch, in welche Richtung die Gegenmaßnahme geht. Gegen Spoofing hilft Authentifizierung, gegen Tampering Integritätsschutz, gegen Repudiation nachvollziehbare Protokollierung. Die Kategorie ist also nicht nur ein Etikett, sie ist bereits ein Fingerzeig auf die Lösung.

11:06 Gehen Sie deshalb je Element und je Datenfluss alle sechs durch — auch die, die zunächst absurd wirken. Jetzt wenden Sie das an, und zwar auf die Skizze von vorhin: Browser, API, Datenbank. Nehmen Sie sich jedes Element einzeln vor und arbeiten Sie die sechs Kategorien ab. Ziel ist mindestens eine konkrete Bedrohung je Element, mit passender Zuordnung.

11:27 Konkret heißt dabei wirklich konkret — nicht "Manipulation möglich", sondern was genau jemand manipulieren würde und mit welcher Folge. Lassen Sie sich nicht davon abschrecken, dass für manche Elemente eine Kategorie nicht recht passen will; das ist normal und selbst eine Erkenntnis. Wichtig ist, dass Sie die Frage gestellt haben, statt sie zu überspringen.

Bedrohungen priorisieren

11:49 Nach einem guten Workshop haben Sie eine lange Liste — und genau da beginnt oft die Lähmung. Der letzte Schritt bringt Ordnung hinein, damit aus der Liste Arbeit wird und nicht Frust. Denn eine unpriorisierte Bedrohungsliste hat eine unangenehme Eigenschaft: Sie erzeugt schlechtes Gewissen, aber keine Handlung. Mit einer begründeten Reihenfolge haben Sie dagegen etwas, das sich in eine Planung übersetzen lässt.

12:13 Priorisierung ordnet die gefundenen Bedrohungen nach Risiko, grob verstanden als Kombination aus Eintrittswahrscheinlichkeit und möglicher Auswirkung. Das Wort "grob" ist hier ernst gemeint: Es geht nicht um Nachkommastellen, sondern um eine nachvollziehbare Reihenfolge. Der Zweck ist nüchtern — Ihre Ressourcen sind endlich, und ohne Priorisierung passiert erfahrungsgemäß eines von zwei Dingen: Entweder wird abgearbeitet, was am einfachsten ist, oder es wird gar nichts abgearbeitet, weil die Liste erdrückend wirkt.

12:41 Beides ist schlechter, als bewusst zu entscheiden, was zuerst drankommt und was bewusst liegen bleibt. Diese Vier-Felder-Matrix ist absichtlich grob. Zwei Achsen, zwei Stufen — mehr braucht es meist nicht, um im Team zu einer belastbaren Reihenfolge zu kommen, und weniger Stufen erspart Ihnen endlose Diskussionen über die Frage, ob etwas nun "mittel" oder "mittel bis hoch" ist.

13:04 Interessant sind vor allem die beiden Diagonalfelder: Was selten passiert, aber katastrophal wäre, verdient dieselbe Aufmerksamkeit wie das, was häufig passiert und wenig kostet. Und der Satz in der Fußzeile ist der wichtigste dieser Folie: Restrisiken werden bewusst akzeptiert und dokumentiert. Ein bewusst akzeptiertes Risiko ist eine Entscheidung.

13:24 Ein vergessenes ist ein Versäumnis. In der zweiten Übung bringen Sie die Bedrohungen, die Sie eben gefunden haben, in eine Reihenfolge: kritisch, mittel, niedrig — und benennen die Top drei. Das Einstufen selbst geht schneller, als Sie denken; die Diskussion darüber ist der eigentliche Wert. Achten Sie besonders auf den zweiten Teil des Hinweises: Benennen Sie auch die Restrisiken, also das, was Sie bewusst nicht angehen.

13:49 Diese Liste ist im Projektalltag oft die nützlichere, weil sie Ihnen später erlaubt zu sagen: Wir haben darüber nachgedacht, und wir haben uns aus diesen Gründen dagegen entschieden. Das ist ein völlig anderer Satz als "das ist uns nicht aufgefallen". Halten wir fest: Threat Modeling beantwortet vier Fragen entlang eines Systembilds — mehr Methode braucht es im Kern nicht.

14:10 Trust Boundaries und Attack Surface zeigen, wo Bedrohungen sitzen, nämlich an den Übergängen und an den Türen. STRIDE liefert das Raster, damit die Suche systematisch statt zufällig wird, und die Priorisierung liefert die Reihenfolge, in der Sie arbeiten. Was Sie jetzt haben, ist eine begründete Liste von Bedrohungen. Was Ihnen noch fehlt, sind gute Antworten darauf — und die kommen im nächsten Kapitel in Form von Prinzipien, die den Gegenmaßnahmen Struktur geben.

Fragen & Ausblick

14:37 Kapitel 4 nimmt sich die Prinzipien sicherer Softwarearchitektur vor — Least Privilege, Defense in Depth und die anderen Klassiker, die aus einzelnen Maßnahmen ein System machen. Die Vorlagen für Datenflussdiagramme und die STRIDE-Tabelle liegen in der Freigabe; nehmen Sie sie ruhig mit ins eigene Projekt, dafür sind sie gedacht.

14:57 Ein erster Threat-Modeling-Workshop im eigenen Team gelingt erfahrungsgemäß besser, als man erwartet — probieren Sie es. Fragen jetzt gern, sonst erreichen Sie uns unter info@HCO.de.