Threat Modeling

Threat Modeling heißt auf Deutsch etwa « Bedrohungen durchspielen ». Ein Team setzt sich hin und fragt sich: Wer könnte unser System angreifen? Was hätte diese Person davon? Und an welcher Stelle wäre der Angriff am leichtesten? Die Antworten schreibt man auf, sortiert sie nach Gefährlichkeit und entscheidet dann, wogegen man sich schützt. Wichtig ist der Zeitpunkt: Das passiert idealerweise, bevor die Software gebaut wird, nicht erst nach dem ersten Schaden.

Warum Raten teurer ist als Nachdenken

Sicherheit kostet Geld, Zeit und Bequemlichkeit. Man kann nicht alles gleichzeitig absichern. Ohne eine geordnete Analyse entscheidet oft das Bauchgefühl, und Bauchgefühl liegt bei Sicherheit häufig daneben. Teams bauen dann aufwendige Schutzmechanismen an einer Stelle ein, an der nie jemand angreift, und lassen die offene Tür daneben offen.

Dazu kommt der Kostenfaktor. Ein Denkfehler im Entwurf lässt sich am Whiteboard in einer halben Stunde beheben. Derselbe Fehler in einer laufenden Anwendung mit Millionen Nutzern kostet Wochen, weil man Daten migrieren, Schnittstellen ändern und alte Versionen ablösen muss. Wird der Fehler erst durch einen echten Einbruch entdeckt, kommen Meldepflichten, Bußgelder und Vertrauensverlust dazu.

Bei KI-Systemen ist das Thema in den letzten Jahren deutlich wichtiger geworden. Ein Sprachmodell, das E-Mails liest und selbstständig Aktionen ausführt, hat Angriffsflächen, die klassische Software nicht kennt. Wer solche Systeme ohne vorherige Bedrohungsanalyse ins Netz stellt, entdeckt die Lücken erst durch die Angreifer.

Vier Fragen, ein Diagramm, eine Prioritätenliste

In der Praxis läuft Threat Modeling meist über vier Fragen. Erstens: Was bauen wir überhaupt? Dazu zeichnet das Team ein einfaches Schaubild mit allen Bausteinen, Datenwegen und Außengrenzen. Zweitens: Was kann schiefgehen? Drittens: Was tun wir dagegen? Viertens: Haben wir gut genug gearbeitet?

Für die zweite Frage gibt es Checklisten, damit niemand die naheliegenden Angriffe übersieht. Die bekannteste heißt STRIDE und nennt sechs Kategorien: sich als jemand anderes ausgeben, Daten unbemerkt verändern, eine Tat später abstreiten, vertrauliche Informationen abgreifen, ein System durch Überlastung lahmlegen und sich mehr Rechte verschaffen als erlaubt. Man geht das Diagramm Baustein für Baustein durch und prüft jede Kategorie.

Danach wird sortiert. Jede gefundene Bedrohung bekommt eine grobe Einschätzung: Wie wahrscheinlich ist sie, und wie groß wäre der Schaden? Nur was oben landet, wird abgesichert. Der Rest wird bewusst akzeptiert und dokumentiert. Genau das unterscheidet Threat Modeling von einem Penetrationstest: Der Penetrationstest sucht echte Lücken in fertiger Software, das Threat Model sucht Denkfehler im Entwurf.

Vom Bankenserver bis zum KI-Assistenten

Banken, Krankenhäuser und Behörden betreiben Threat Modeling seit Jahren, oft weil Aufsichtsbehörden es verlangen. In der Softwarebranche gehört es bei großen Anbietern zum festen Ablauf jedes neuen Produkts. Microsoft hat das Verfahren in den 2000er-Jahren stark geprägt und stellt bis heute ein kostenloses Werkzeug dafür bereit.

In den Tech-News taucht der Begriff derzeit vor allem im Zusammenhang mit KI-Agenten auf. Das sind Programme, die ein Sprachmodell nutzen, um selbstständig Aufgaben zu erledigen, etwa im Web zu suchen oder Dateien zu bearbeiten. Ein typisches Angriffsszenario: Auf einer Webseite steht ein versteckter Text, der dem Assistenten neue Anweisungen gibt. Solche Angriffe findet man nur, wenn man vorher systematisch überlegt hat, welche Daten das System von außen einliest.

Ein verbreiteter Irrtum ist, Threat Modeling sei ein einmaliges Dokument für den Aktenschrank. Sinnvoll ist es nur, wenn es mit dem System mitwächst. Kommt eine neue Schnittstelle dazu, ändert sich die Angriffsfläche, und das Modell muss angepasst werden.