Threat Modeling ist kein Diagramm – sondern der Moment, in dem Security-Entscheidungen entstehen

Threat Modeling scheitert selten an Methoden.

Es scheitert daran, dass niemand das gleiche System im Kopf hat.

Threat Modeling ist kein Diagramm.
Es ist eine Entscheidung.

Und genau deshalb scheitert Bedrohungsmodellierung (engl. Threat Modeling) in vielen Projekten nicht an fehlenden Tools oder Frameworks, sondern daran, dass es kein gemeinsames Bild des Systems gibt.

Phil Sturm ist Co-Founder der Security Game Changer GmbH und beschäftigt sich seit vielen Jahren mit Secure by Design, Security-Strategie und Security-Prozessen. In seiner täglichen Beratung unterstützt er Unternehmen mit Bedrohungsmodellierung und der praktischen Umsetzung von Shift-Left-Security in komplexen IT-Landschaften.

Warum Bedrohungsmodellierung im ersten Moment wie Rocket Science wirkt

Wenn Menschen “Bedrohungsmodellierung” hören, denken viele an formale Methoden, perfekte Architekturunterlagen und lange Workshops. In der Praxis startet ein Projekt jedoch häufig anders:

• Es gibt fragmentiertes Kopfwissen über Systeme, Schnittstellen und Verantwortlichkeiten.
• Projektleitung, IT, Fachbereich und Security meinen “das gleiche System”, aber mit unterschiedlichen mentalen Modellen.
• Und niemand hat “mal eben” eine Visualisierung, die Security-Entscheidungen wirklich trägt.

Das ist kein Organisationsproblem – es ist eine typische Eigenschaft komplexer IT-Landschaften.

Mein pragmatischer Einstieg: ein Systemmodell statt “perfekter Architektur”

Ein Systemmodell ist eine gemeinsame, bewusst vereinfachte Sicht auf ein Vorhaben: Was gehört dazu, was hängt zusammen und was ist für Entscheidungen relevant.

Die fachlichen und technischen Details übersetze ich im Gespräch in die passende Form, je nach Kontext z. B. als Datenflussdiagramm, Sequenzsicht oder Bausteinsicht. Für Projektleitung und Fachbereich heißt das: kein Methodenballast, sondern Wissen teilen und schnell sehen, ob alle vom gleichen System sprechen.¹²

Beispielhafte Mini-Ansicht eines Systemmodells: In realen Projekten sind Systemmodelle in der Regel deutlich umfangreicher und werden iterativ mit allen relevanten Schnittstellen, Annahmen und Vertrauensgrenzen verfeinert.

“Zero Vorlaufzeit”: Systemmodellierung live im Gespräch

Seit Jahren arbeite ich (gemeinsam mit meinem Co-Founder) mit einem Muster, das viele Projekte entlastet:

Wir modellieren live im Termin – während das Gespräch über Ziele, Scope und Integrationen ohnehin läuft.

Dabei gilt:

• Keine Vorbereitungspflicht für den Fachbereich oder die Projektleitung.
• Bestehende Dokumentation ist willkommen, aber kein Gatekeeper.
• Wir persistieren den Zwischenstand sofort, damit daraus ein “Laufzettel” wird, mit dem weitere Stakeholder schnell abgeholt werden können.³

Warum das funktioniert: Bedrohungsmodellierung braucht zunächst ein geteiltes Verständnis des Systems (Datenflüsse, Trust Boundaries, Interaktionen). Diese Sichtbarkeit ist bereits ein zentraler Mehrwert, unabhängig davon, ob man in einem späteren Schritt tief in Bedrohungen und Gegenmaßnahmen einsteigt.²

Der Aha-Moment

In vielen Terminen gibt es einen Moment, der das Gespräch auf ein anderes Niveau hebt.

Ab etwa der Hälfte des Termins teile ich meinen Bildschirm und frage:

“Meint ihr in etwa so etwas?”

Aus vagen Beschreibungen werden plötzlich präzise Korrekturen.

Nicht mehr:
“Ich glaube, da hängt noch irgendwas dran …”

Sondern:
“Bitte ergänze hier noch das System X.”
“Dieser Flow geht eigentlich über Y.”
“Diese Vertrauensgrenze liegt anders.”

Genau hier greift die Methode: Durch strukturierte Moderation entsteht aus dem laufenden Austausch fast automatisch ein belastbarer Erstentwurf, den wir anschließend gemeinsam schärfen. Für die Stakeholder bleibt der Fokus auf dem, was sie am besten können: ihr Wissen teilen und Entscheidungen einordnen.

Ab hier wird’s zur Entscheidung

Ein Systemmodell ist zunächst nur ein Protokoll.

Der eigentliche Wert entsteht erst, wenn Teams daraus Entscheidungen ableiten, solange Design noch beweglich ist:

• Was ist in scope / out of scope?
• Wo liegen die Trust Boundaries und was bedeutet das für AuthN/AuthZ, Validierung, Logging oder Resilienz?
• Welche Annahmen machen wir – und dokumentieren sie?
• Welche Risiken akzeptieren wir bewusst und welche ändern wir jetzt im Design?

Diese Brücke zur Entscheidung ist auch der Grund, warum Threat Modeling in etablierten Security-Engineering-Ansätzen als Methode zur Gestaltung des Designs und zur Risikoreduktion verstanden wird.²

Shift Left anschaulich erklärt: die Kuchen-Metapher

Shift Left lässt sich gut ohne Rechenfaktoren erklären: Stell dir Software wie einen Kuchen vor – in der Design-Phase legst du Zutaten, Rezept und Backform fest (Architektur, Trust Boundaries, sichere Defaults).

Wenn hier etwas grundlegend falsch ist, „backt“ es sich ins System ein; später ist es selten nur ein Patch, sondern oft Re-Design, Regression, Rollout-Risiko, Betriebsaufwand bis hin zu Incident- und Kundenfolgen.

Ob die Literatur dafür nun sehr hohe oder „nur“ moderate Kostensprünge behauptet, ist umstritten. Belastbar bleibt: Späte Findings werden typischerweise organisatorisch und wirtschaftlich deutlich teurer – abhängig von Kontext, Unternehmen und System.

Und die Folgekosten liegen oft außerhalb des Projektblicks, aber nicht außerhalb des Blicks eurer Kunden. Damit ist Shift Left vor allem eine Frage von Nachhaltigkeit und Security-ROI.

Kurzer Reality-Check, bevor ein IT-Projekt teuer wird

Wenn du gerade ein Projekt startest und das Gefühl hast, es fehlt das gemeinsame Bild:

Ausblick (ohne Versprechen)

Wenn ich merke, dass das Thema Interesse auslöst, schreibe ich gern weiter über Themen wie:

• Informationsobjekte und Sicherheitsziele (Vertraulichkeit / Integrität / Verfügbarkeit) und warum Systemmodellierung nicht automatisch Risikomodellierung ist
• Bedrohungen identifizieren – Frameworks, aber praxisnah
• Gegenmaßnahmen: risikoorientiert, projekt- und landschaftsspezifisch statt „Control-Friedhof“
• Was man mit einem gepflegten Systemmodell im Projektverlauf sonst noch alles beschleunigen und die Qualität und Maturität steigern kann

Transparenz- und Rechtshinweise

Generischer Fachbeitrag, keine Rückschlüsse auf Dritte:
Diese Beitragsserie beschreibt generische methodische Ansätze und fachliche Erfahrungswerte zur Bedrohungsmodellierung. Etwaige Ähnlichkeiten zu realen Umgebungen, Architekturen oder Projektkonstellationen sind zufällig und erlauben keine Rückschlüsse auf konkrete Organisationen, deren interne Systeme oder Sicherheitslagen.

Externe Links:
Verlinkte Quellen sind als externe Quellen zu verstehen. Inhalte können sich nach Veröffentlichung ändern. Wir machen uns Inhalte externer Seiten nicht zu eigen. Hinweise auf problematische Inhalte nehmen wir ernst – Links werden dann geprüft und ggf. entfernt.

Keine Rechtsberatung / keine Gewähr:
Dieser Beitrag dient der Information und stellt keine Rechtsberatung dar. Er ersetzt keine individuelle Bewertung deines Projekts.

Marken & Produktnamen:
Alle genannten Marken, Produkt- und Firmennamen gehören den jeweiligen Rechteinhabern. Die Nennung erfolgt ausschließlich zur Einordnung und Beschreibung.

Quellen