Microsoft Threat Modeling Tool vs. OWASP Threat Dragon: Ein Praxisvergleich entlang des Threat-Modeling-Ablaufs

Wenn du Threat Modeling in deinem Team nicht nur als einmalige Übung sehen willst, sondern als wiederholbaren Teil des Software-Entwicklungsprozesses, dann ist die Tool-Wahl plötzlich keine Nebensache mehr. Threat Modeling, also das strukturierte Identifizieren, Bewerten und Behandeln von Bedrohungen für ein System, ist ein zentraler Bestandteil moderner Softwareentwicklung. Ziel ist es, Schwachstellen frühzeitig zu erkennen und gezielt Maßnahmen umzusetzen.

Wichtig vorweg: Tooling ist nur ein Teil des Ganzen. Das Threat Modeling Manifesto betont bewusst Zusammenarbeit, Systematik und kontinuierliche Verbesserung. Genau deshalb ist ein Vergleich entlang des Ablaufs hilfreicher als eine Feature-Liste. Du kannst direkt abgleichen, wo dich ein Tool im Alltag unterstützt und wo du Prozesse brauchst.

Threat Modeling: Was ist das überhaupt?

Threat Modeling lässt sich auf vier Leitfragen herunterbrechen, die sich wie ein roter Faden durch jeden Ablauf ziehen: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir genug getan? Dabei ist besonders zu beachten, dass diese Fragen immer aus Sicht der Cyber Security gestellt werden. Diese Struktur findest du auch im Threat Modeling Manifesto und sie passt gut zu einem pragmatischen Prozess, den du immer wieder durchlaufen kannst.

In der Praxis ist eine Phasen-Sicht oft einfacher umzusetzen. Auch Microsoft beschreibt das in einem Learn-Modul als Design, Break, Fix, Verify. Konkret bedeutet das, dass du dein System modellierst, Angriffsflächen identifizierst, Maßnahmen einplanst und später überprüfst.

Was du am Ende jeder Runde in der Hand haben willst, ist ein Modell deines Systems als Data Flow Diagram (DFD), eine Threat-Liste mit einer Bewertung der Angriffsflächen, dokumentierte Entscheidungen zu Mitigations und ein Review- bzw. Report-Artefakt. Das OWASP Threat Modeling Cheat Sheet beschreibt diesen Ablauf nochmals und erinnert auch daran, dass es sich nicht um ein einmaliges Event handelt, sondern das Threat Modeling als kontinuierliche Aktivität im Entwicklungsprozess verankert sein sollte.

Schritt 1 – System verstehen und modellieren

In diesem Schritt beantwortest du, woran gearbeitet wird. Du brauchst ein Modell, das Datenflüsse sichtbar macht, Trust Boundaries markiert und die wichtigsten Komponenten benennt. Das muss nicht maximal detailreich sein, aber es muss nützlich sein, damit ihr daraus strukturiert Threats ableiten könnt.

• Actor: Externe oder interne Entität, die mit dem System interagiert (z.B. Nutzer, Service, externes System).
• Process: Verarbeitungseinheit, die Daten empfängt, verarbeitet und weiterleitet (z.B. Anwendung, API, Service).
• Store: Speicherort für Daten, die dauerhaft oder temporär abgelegt werden (z.B. Datenbank, Dateisystem).
• Trust Boundary: Grenze, an der sich das Vertrauensniveau ändert, z.B. zwischen internem Netzwerk und Internet oder zwischen zwei Systemen mit unterschiedlichen Berechtigungen.

Das Microsoft Threat Modeling Tool (TMT) ist hier sehr stark, weil es dich geführt durch die Modellierung bringt und früh auf konsistente DFD-Bausteine setzt. Du wählst beim Start ein Template, zum Beispiel das Azure Template oder die SDL Threat Modeling Knowledge Base, und modellierst dann Flows, Prozesse, Data Stores und Trust Boundaries. Praktisch ist dabei auch, dass TMT dir mehr vorgefertigte Stencils, also Vorlagen für Actor, Process, Store und DataFlow, mitbringt, was zum einen hilft, sein System spezifischer und somit verständlicher zu modellieren. Auf der anderen Seite bestimmen die Stencils bereits, welche Bedrohungen mit Ihnen verbunden sind. Der Getting-Started-Guide in der Microsoft-Dokumentation zeigt diesen Ablauf ziemlich gut.

Was dabei gerne untergeht: TMT unterstützt auch die Erstellung eigener Templates. In so einem Template stecken nicht nur Stencils, sondern auch Kategorien, Threat Properties und die Threats selbst. Wenn dein Team mehrere Produkte derselben Art bewertet, kann sich die Erstellung eigener Templates lohnen, weil du wiederkehrende Muster einmal sauber modellierst und dann in der Breite konsistent anwendest. Als Anfänger würde ich aber nicht mit dem Template starten. Bau erst ein paar Modelle, lerne dabei, welche Bausteine und Properties für euch wirklich funktionieren, und leite daraus später Templates ab. Dann nutzt du sie gezielt, um deine Produktpalette schneller und vergleichbarer zu bewerten.

Mir persönlich fällt in TMT auch das Verbinden der Elemente zur Darstellung der Flows leichter als in OWASP Threat Dragon (TD). Das ist kein KO-Kriterium gegen TD, aber in der Praxis macht es einen Unterschied, wenn du zügig modellieren und die Flows sauber an die richtigen Elemente hängen willst. Ein weiteres Detail, das im Alltag hilft: TMT gibt dir Hinweise, wenn die Modellierung lückenhaft wirkt. Ein typisches Beispiel ist ein Data Store, in den nur Daten hinein fließen, aber aus dem kein Flow heraus geht. Das ist nicht automatisch falsch, aber es ist oft ein Signal, dass dir ein Lesepfad im Diagramm fehlt.

OWASP Threat Dragon (TD) bekommst Du in einer Web- oder Desktop-Variante. In der Web-Variante kannst du das Modell in Git-Repositories auf GitHub ablegen. In der Doku zum Getting started wird dieser Model-as-Data-Ansatz inklusive Pfadstruktur beschrieben. Du kannst aber auch im Modus Local Session arbeiten und Dein Modell in einer lokalen Datei speichern. In der Modellierung stehen Dir weniger Elemente (Stencils in TMT) zur Verfügung, was aber nicht von Nachteil sein muss. Zudem ist das User Interface zumindest für mich an manchen Stellen weniger intuitiv als bei TMT.

Wichtig für die Praxis: Beide Tools unterstützen mehrere Diagramme pro Threat Model. Du kannst also Dein System in einzelne Sichten zerlegen und somit die Diagramme übersichtlich und verständlich halten.

In Threat Dragon hat die Wahl des Diagramms allerdings noch eine zusätzliche Konsequenz: Der Diagrammtyp beeinflusst, welche Threat-Kategorien bzw. Threats dir zur Verfügung stehen und wie Vorschläge pro Element vorgeschlagen und gruppiert werden. Wenn du merkst, dass die Konventionen euer System zu sehr in eine Schablone pressen, ist der Generic-Modus oft der beste Ausweg. In diesem stehen alle Threat-Kategorien zur Verfügung.

Schritt 2 – Threats identifizieren: Kataloge, Auto-Generierung, Kontext

Nachdem das System modelliert ist, kommt die zweite Leitfrage: Was kann schiefgehen? Es geht also darum, die Threats für die einzelnen Elemente im System zu finden. Der typische Fehler ist hier, Threat Modeling als Brainstorming zu verstehen. Brainstorming ist gut, aber ohne Struktur ist es unvollständig. TMT und TD helfen dir, systematisch durch Kategorien zu gehen und nicht nur die offensichtlichen Risiken zu erwischen.

TMT ist sehr stark in der Kategorisierung nach STRIDE. Die Tool-Dokumentation zu Threats und STRIDE zeigt, wie Threats aus Diagramm und Template generiert werden, dabei wird STRIDE pro Element angewandt. TMT legt die Threats automatisch auf Basis der genutzten Stencils an. Du bekommst damit schnell eine konsistente Baseline an Threats, inklusive Kategorien und Priorisierung, und je nach Template auch Vorschläge, die auf (d)ein konkretes Ökosystem zugeschnitten sind und damit eure Maßnahmenauswahl in diese Richtung lenken können.

TD ist flexibler bei den vorgefertigten Kategorien. Abhängig vom Diagrammtyp unterstützt es neben STRIDE auch die Threat Modeling Frameworks LINDDUN, CIA, CIA-DIE und PLOT4ai. Du kannst Threats nach Elementtyp sequenziell durchgehen, und du kannst kontextbasierte Vorschläge erzeugen, die auf Properties des Elements basieren.

Die wichtige Praxisfrage ist meistens nicht, welche Kategorien ein Tool auf dem Papier unterstützt, sondern wie Threats konkret ins Modell kommen. Grob gibt es drei Wege:

• Auto-Generierung aus Modell plus Regelwerk: TMT ist hier sehr stark, weil Threats aus Diagramm und Template abgeleitet werden.
• Guided Elicitation: Du kannst in TD (und teilweise auch in TMT) systematisch durch Elemente und Kategorien geführt werden und die Liste der potentiellen Threats nach und nach durcharbeiten kannst. Guided Elicitation bedeutet, dass das Tool dich Schritt für Schritt durch die relevanten Elemente und Kategorien führt, damit keine Bedrohungskategorie vergessen wird.
• Manuell ergänzen: weil jedes echte System Spezialfälle hat, die kein Katalog perfekt abdeckt.

OWASP Top 10 und ASVS solltest du eher als Referenzen verwenden, nicht als vollständige Threat-Kataloge. Die OWASP Top 10 hilft dir, typische Problemklassen zu benennen und Awareness zu schaffen. Die OWASP ASVS ist dagegen oft der bessere Hebel, wenn du Maßnahmen in überprüfbare Requirements übersetzen willst.

Wenn du ein Threat Model später testen oder validieren willst, sind MITRE-Datenquellen hilfreich. MITRE ATT&CK liefert dir Taktiken und Techniken, also typische adversary behaviors. MITRE CAPEC ist ein Wörterbuch von Attack Patterns und eignet sich gut, um konkrete Testideen abzuleiten.

Wenn du nur einen Startpunkt willst, nimm STRIDE als Baseline und ergänze die anderen, sobald sie relevant werden.

Schritt 3 – Mitigations planen und aktualisieren

Jetzt geht es um die dritte Leitfrage: Was tun wir dagegen? Hier entscheidet sich, ob Threat Modeling eine Papierübung bleibt oder ob es in Engineering-Arbeit übersetzt wird.

TMT bietet für diesen Schritt die Analysis View. In dieser definierst du pro Threat die Mitigations (konkrete Maßnahmen zur Risikoreduzierung, z.B. „Passwort-Hashing mit bcrypt“) und Justifications (Begründungen, warum eine Maßnahme gewählt oder nicht gewählt wurde, z.B. „Nicht relevant, da kein externer Zugriff“), plus einem Status-Workflow wie Not Started, Needs Investigation, Mitigated oder Not Applicable. Beispiele für Mitigations sind etwa „Einsatz von Multi-Faktor-Authentifizierung“ oder „TLS-Verschlüsselung für alle Verbindungen“. Justifications können lauten: „Nicht relevant, da keine personenbezogenen Daten verarbeitet werden“ oder „Mitigation aktuell nicht wirtschaftlich umsetzbar“.

Weitere Details und Beispiele findest du in der Microsoft-Dokumentation zu Mitigations. Bei Selektion des Threats wird zudem das zugehörige Element in deinem Diagramm markiert, was für bessere Verständlichkeit sorgt.

TD arbeitet ähnlich, aber mit anderer Sprache. Du hast Threat-Properties für Mitigations, Status wie Open, Mitigated oder N/A, und du kannst Severity und Scores zur Priorisierung nutzen. Die Details findest du wieder in der Doku zu Threats. TD hilft dir an dieser Stelle auch visuell, denn es hebt die Elemente, bei denen eine Threat-Bewertung noch offen ist, grafisch hervor. Für den Score macht TD keine Vorgabe, wie er ermittelt wird. Es ist daher hilfreich, zu dokumentieren, mit welcher Skala und Bedeutung du hier arbeiten willst.

Die Herausforderung in der Praxis besteht neben der Erstanlage insbesondere in der Wartung. Das Bedrohungsmodell muss aktuell bleiben. Es muss dabei nicht nur mit Deiner Lösung mitwachsen, sondern auch auf externe Ereignisse wie angepasste Bedrohungskataloge oder veröffentlichte CVEs reagieren. Ein pragmatisches Regelwerk zum Review und Neubewerten deines Modells könnte wie folgt aussehen:

1. Keine Architektur-Änderung ohne Threat Review
2. Kein Release ohne Prüfung offener Threats im Modell
3. Kein Security-Incident (z.B. via SBOM Monitoring) ohne Betrachtung im Modell

Schritt 4 – Verify: Review, Qualität, Nachweisbarkeit

Die vierte Leitfrage lautet: Haben wir genug getan? Das ist nicht nur eine Security-Frage, sondern auch eine Frage nach Nachvollziehbarkeit. Kann jemand anderes später nachvollziehen, was ihr modelliert habt, was offen war, was entschieden wurde und warum?

In TMT kannst Du über das Menu Create Full Report einen konsolidierten Bericht erzeugen. Auch TD unterstützt die Erzeugung von Reports und die Speicherung als PDF. Die Reports eignen sich gut für Reviews mit Stakeholdern, insbesondere wenn diese keinen Zugriff auf die Modell-Datei oder das notwendige Werkzeug haben (sollen). Der Report gehört als Nachweis mit in die technische Dokumentation. Da er jederzeit aus dem Modell generiert werden kann, reicht es aber oft aus, das Modell zusammen mit dem Code im Repository abzulegen und zu versionieren.

Unabhängig davon, ob ich das Review im Tool oder auf Basis eines Reports mache, muss ich zeigen können, dass mein System vollständig abgebildet ist, dass alle Threats erfasst und bewertet wurden, dass Mitigations definiert und umgesetzt wurden, dass die Umsetzung auch nachvollzogen und auf Wirksamkeit getestet wurde. Es muss zudem ersichtlich werden, welche Threats nicht mitigiert wurden und warum.

An dieser Stelle sei erneut auf das OWASP Threat Modeling Cheat Sheet verwiesen, welches ähnliche Fragen für Review und Validierung benennt.

Tooling im Alltag: Zusammenarbeit, Erweiterbarkeit, Plattform, Integration

Die Entscheidung zwischen TMT und TD ist im Alltag oft Geschmackssache.

TMT ist sehr gut, wenn du Windows-lastig unterwegs bist. Das Tool ist stark geführt, STRIDE ist direkt eingebaut und du bekommst Reports. Gleichzeitig ist die Zusammenarbeit dateibasiert, d.h. das Modell lässt sich leicht teilen. Aufgrund der Xml-Struktur der Datei ist eine parallele Bearbeitung aber durchaus schwierig.

TD ist besonders stark, wenn dein Team Repo-first arbeitet. Modelle, die bei TD als JSON abgebildet sind, direkt in GitHub ablegen zu können, vereinfacht die Entscheidung zum Ablageort. Außerdem ist es plattformunabhängig, weil es Desktop-Apps für mehrere OS gibt oder als Web-App betrieben werden kann. Zudem ist der Source Code verfügbar, sodass Du auch über Deinen gesamten Supportzeitraum dafür sorgen kannst, das das Tool zur Verfügung steht (siehe auch CRA & Long-Term-Support: Warum Git und Code allein nicht reichen).

Erweiterbarkeit ist bei beiden anders gelöst. TMT ist template-getrieben, mit der Wahl zwischen Azure-Template und SDL Knowledge Base, und mit der Möglichkeit, eigene Templates zu bauen. TD ist kategorie- und diagrammtyp-getrieben, mit Kontextvorschlägen über Properties.

Neben TMT und TD gibt es natürlich noch weitere kommerzielle als auch freie Tools zum Threat Modeling. Für einen Überblick lohnt ein Blick auf Awesome Threat Modeling

Mein pragmatischer Startpunkt ist immer: Nimm das Tool, das am wenigsten Reibung erzeugt. Und dann macht diese Woche das erste Modell, klein genug, um fertig zu werden, aber groß genug, um wirklich Threats zu finden.

Wie sieht euer aktueller Threat-Modeling-Workflow und welche Tools nutzt ihr? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.