GlossarSichere EntwicklungRisiko

Threat Modeling

Threat Modeling ist die strukturierte Suche nach dem, was in einem System schiefgehen kann, bevor es gebaut wird. Vier Fragen, STRIDE, Angriffsbäume und der Pentest.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

Threat Modeling ist eine strukturierte Analyse des Systemdesigns, die Assets, Vertrauensgrenzen, mögliche Angreifer und ihre Bedrohungen identifiziert und daraus Gegenmaßnahmen und Testfälle ableitet. Es beantwortet vier Fragen: Was bauen wir, was kann schiefgehen, was tun wir dagegen, haben wir es gut gemacht. Methoden wie STRIDE und Angriffsbäume geben Struktur; im Automotive-Bereich ist die formalisierte Variante die TARA der ISO/SAE 21434.

Was ist Threat Modeling?

Threat Modeling ist die Praxis, ein System von der Angreiferseite zu betrachten, bevor der Angreifer es tut. Das Threat Modeling Manifesto fasst es in vier Fragen zusammen: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir es gut genug gemacht?

Das Arbeitsmaterial ist ein Modell des Systems, meist ein Datenflussdiagramm mit Prozessen, Datenspeichern, externen Entitäten, Datenflüssen und Vertrauensgrenzen. Für jedes Element und jede Grenze fragst du, was ein Angreifer tun könnte. STRIDE liefert sechs Kategorien zum Abprüfen: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege. Angriffsbäume nehmen ein Angreiferziel und zerlegen es in die Schritte und Alternativen, die dorthin führen. Das Ergebnis ist eine Liste von Bedrohungen mit Schweregrad, die beschlossenen Gegenmaßnahmen und die offenen Punkte, die zu Anforderungen und Testfällen werden.

Wo ist es definiert?

Einen einzelnen Standard gibt es nicht; mehrere Organisationen beschreiben die Praxis. OWASP pflegt das Threat Modeling Cheat Sheet und die Community-Seite mit Methoden und Werkzeugen. Microsoft dokumentiert STRIDE und sein Threat Modeling Tool. Das Threat Modeling Manifesto (2020) hält die von Praktikern vereinbarten Werte und Prinzipien fest. In regulierten Domänen ist die Praxis formalisiert: ISO/SAE 21434 Kapitel 15 macht daraus die TARA mit festen Bewertungsskalen für Straßenfahrzeuge; IEC 62443-3-2 verlangt eine Risikobewertung je Zone und Conduit für Industriesysteme; der Cyber Resilience Act verlangt in Artikel 13, dass Hersteller eine Cybersicherheits-Risikobewertung durchführen und als Teil der technischen Dokumentation pflegen.

Was es in der Praxis bedeutet

Ein Threat Model zahlt sich zweimal aus. Im Design beseitigt es ganze Klassen von Findings zum Preis einer Whiteboard-Sitzung: Schlüssel, die nie auf dem Gerät hätten liegen dürfen, eine Admin-Schnittstelle, die nie zum Netz zeigen sollte, eine Vertrauensbeziehung zwischen zwei Steuergeräten, die niemand hinterfragt hat. Vor einem Penetrationstest wird es zum Testplan: Der Tester greift zuerst die Pfade an, die das Modell als kritisch einstuft, und prüft, ob die Gegenmaßnahmen, die das Modell behauptet, tatsächlich existieren.

In unseren Steuergeräte- und IoT-Projekten ist die zweite Verwendung die häufige. Für eine Infotainment-Plattform listete das Modell die TEE, die aus unprivilegierten Apps erreichbaren Kernel-Treiber, DoIP und SOME/IP als kritische Grenzen, und die Fuzzing-Kampagne folgte dieser Liste. Für ein ESP32-Kommunikationsmodul identifizierte das Modell das geteilte MQTT-Zugangsdatum als Single Point of Failure für die gesamte Flotte, bevor ein Test gelaufen war. Die besten Threat Models, die wir sehen, sind kurz, von den Leuten gezeichnet, die das System gebaut haben, und werden bei Designänderungen aktualisiert.

Häufige Missverständnisse

Threat Modeling ist kein Tool-Lauf und kein Compliance-Dokument. Eine generierte Liste von 300 generischen Bedrohungen ist weniger nützlich als 20 spezifische mit benannten Verantwortlichen. Fertig ist es auch nicht, wenn die Liste existiert: Die Frage “haben wir es gut gemacht” braucht Verifikation, und da kommen Code Review, Fuzzing und Penetrationstest ins Spiel. Ersetzen tut es sie nicht. Ein Modell sagt, was über das System wahr sein sollte; ein Test zeigt, ob es das ist.

FAQ

Häufig gestellte Fragen

Wann sollten wir Threat Modeling machen?

Sobald es eine Architektur zu zeichnen gibt, und erneut, wenn sie sich wesentlich ändert: eine neue Schnittstelle, eine neue Vertrauensgrenze, ein neues Deployment-Modell. Ein Threat Model nach der Auslieferung hat immer noch Wert als Testplan für einen Penetrationstest, aber die günstigen Fixes (den Schlüssel nicht dort ablegen, den Port nicht nach außen führen) sind dann vorbei.

Welche Methode: STRIDE, PASTA, Angriffsbäume?

Die Methode ist weniger wichtig, als es mit den richtigen Leuten und einem präzisen Diagramm zu machen. STRIDE ist eine gute Checkliste pro Datenfluss für Softwaresysteme. Angriffsbäume zeigen besser, wie sich mehrere Schwächen kombinieren, und genau das zählt bei Embedded-Produkten. Für Fahrzeuge schreibt ISO/SAE 21434 die TARA-Struktur vor. Wir kombinieren meist ein Datenflussdiagramm, STRIDE je Grenze und Angriffsbäume für die Top-Risiken.

Braucht man Quellcode oder die Hardware für ein Threat Model?

Nein. Ein Threat Model arbeitet auf dem Design: Architekturdiagramme, Schnittstellenbeschreibungen, Deployment und die Liste der Assets. Code und Hardware kommen ins Spiel, wenn das Threat Model verifiziert wird, im Code Review oder im Penetrationstest. Deshalb ist ein Threat Model auch ein guter erster Schritt vor jedem Test: Es sagt dem Tester, wo er die Zeit investieren soll.

Quellen

Passende Seiten

← Glossar