Threat Modeling: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Threat Modeling ist keine theoretische Vorübung und kein Dokument, das nach einem Workshop in einem SharePoint-Ordner verschwindet. In einer belastbaren Sicherheitsorganisation ist es die Arbeitsgrundlage dafür, welche Angriffe realistisch sind, welche Systeme zuerst geschützt werden müssen, welche Telemetrie fehlt und welche Purple-Team-Übungen überhaupt sinnvoll sind. Ohne Bedrohungsmodellierung wird Purple Teaming schnell zu einer Sammlung isolierter Tests: einzelne TTPs werden ausgeführt, Alerts werden geprüft, aber der Zusammenhang zwischen Geschäftsprozess, Angreiferziel, technischer Angriffsfläche und Verteidigungsfähigkeit bleibt unscharf.

Im Kontext von Purple Teaming verbindet Threat Modeling drei Ebenen: die geschäftliche Relevanz eines Assets, die technische Realisierbarkeit eines Angriffs und die operative Nachweisbarkeit durch Logs, Detection und Response. Genau dort entsteht der eigentliche Mehrwert. Ein gutes Modell beantwortet nicht nur die Frage, ob ein Angriff möglich ist, sondern auch, wie wahrscheinlich er in der eigenen Umgebung ist, welche Vorbedingungen erfüllt sein müssen, welche Spuren entstehen und an welcher Stelle Blue Team, SOC oder Detection Engineering eingreifen können.

Viele Teams verwechseln Threat Modeling mit einer pauschalen Risikoanalyse. Das ist zu grob. Eine Risikoanalyse sagt oft, dass ein Domain Controller kritisch ist. Ein brauchbares Bedrohungsmodell geht deutlich tiefer: Welche Identitäten können ihn erreichen? Welche Administrationspfade existieren? Welche Legacy-Protokolle sind aktiv? Welche Service Accounts haben übermäßige Rechte? Welche Telemetrie landet im SIEM? Welche EDR-Regeln greifen bei Credential Dumping, Kerberoasting oder Remote Service Creation? Erst aus dieser Tiefe entsteht ein verwertbarer Testplan.

Threat Modeling ist damit eng mit Und Mitre Attack verknüpft, darf aber nicht auf ATT&CK-Mapping reduziert werden. ATT&CK beschreibt Angreiferverhalten. Das Modell muss zusätzlich die Eigenheiten der Umgebung abbilden: Netzsegmentierung, IAM-Struktur, Cloud-Trust-Beziehungen, Admin-Workstations, Backup-Wege, Third-Party-Zugänge, Build-Pipelines und vorhandene Sicherheitskontrollen. Erst die Kombination aus TTP-Katalog und Umgebungsrealität macht das Modell belastbar.

In reifen Teams ist Threat Modeling kein einmaliges Projekt, sondern Teil eines wiederholbaren Workflow. Neue Anwendungen, geänderte Trust-Beziehungen, Migrationsprojekte, Cloud-Einführungen oder neue EDR-Funktionen verändern das Bedrohungsbild. Wer das Modell nicht nachzieht, testet an der Realität vorbei. Wer es sauber pflegt, priorisiert Purple-Team-Aktivitäten deutlich präziser und spart Zeit bei der Auswahl von Szenarien, Telemetrie und Erfolgskriterien.

Ein brauchbares Threat Model beginnt nicht mit Angriffstechniken, sondern mit Schutzobjekten und Abhängigkeiten. Zuerst werden die Systeme identifiziert, deren Ausfall, Manipulation oder Kompromittierung operative oder regulatorische Folgen hätte. Dazu gehören nicht nur offensichtliche Kronjuwelen wie Identitätsdienste, ERP-Systeme oder Produktionssteuerung, sondern auch indirekte Schlüsselsysteme: CI/CD-Runner, Secrets-Management, MDM, Backup-Infrastruktur, Jump Hosts, API-Gateways und zentrale Logging-Pipelines.

Danach folgt die Modellierung der Beziehungen. Genau hier scheitern viele Teams. Ein einzelnes Asset ist selten das eigentliche Problem; kritisch wird die Kette. Ein kompromittierter Entwickler-Endpoint kann über gespeicherte Tokens Zugriff auf Git, Artefakt-Registry und Deployment-Pipeline eröffnen. Ein schwach gehärteter Helpdesk-Account kann über privilegierte Passwort-Resets den Weg zu Tier-0-Systemen ebnen. Ein öffentlich erreichbarer Webdienst ist nicht nur wegen RCE relevant, sondern wegen möglicher Seitwärtsbewegung über Service Principals, Datenbank-Credentials oder interne APIs.

Ein belastbares Modell beschreibt daher Angriffspfade statt isolierter Schwachstellen. Ein Angriffspfad besteht aus Einstieg, Berechtigungsausweitung, Bewegung, Zielerreichung und Persistenz oder Exfiltration. Für jede Stufe werden Vorbedingungen, technische Möglichkeiten, vorhandene Kontrollen und beobachtbare Spuren dokumentiert. Das Ergebnis ist kein abstraktes Diagramm, sondern eine testbare Hypothese: Wenn ein Angreifer über Phishing einen Standard-User kompromittiert, kann er mit hoher Wahrscheinlichkeit über OAuth-Consent-Missbrauch, schwache Conditional-Access-Regeln und unzureichende Audit-Tiefe auf M365-Daten zugreifen, ohne frühzeitig erkannt zu werden.

Praktisch hat sich eine Struktur bewährt, die pro Angriffspfad mindestens folgende Fragen beantwortet:

• Welches Ziel verfolgt der Angreifer konkret, etwa Datendiebstahl, Identitätsübernahme, Sabotage oder unbemerkte Persistenz?
• Welche Systeme, Identitäten, Protokolle und Vertrauensbeziehungen sind für diesen Pfad relevant?
• Welche TTPs sind realistisch, welche Kontrollen existieren bereits und welche Telemetrie belegt Erfolg oder Misserfolg?

Diese Denkweise verhindert einen typischen Fehler: Teams sammeln Schwachstellenlisten, aber keine operativen Szenarien. Ein offener SMB-Port, ein veralteter Agent oder ein zu breites IAM-Role-Binding sind für sich genommen noch kein priorisierter Purple-Team-Use-Case. Erst wenn klar ist, wie daraus ein realistischer Pfad zu einem geschäftskritischen Ziel entsteht, lässt sich Aufwand gegen Nutzen abwägen.

Für die Modellierung ist es sinnvoll, technische und fachliche Perspektiven zusammenzubringen. Architektur, Betrieb, IAM, Netzwerk, Cloud, Detection Engineering und Incident Response sehen jeweils andere Teile des Problems. Genau deshalb ist Threat Modeling in der Praxis eng mit Collaboration verbunden. Wer nur mit dem Security-Team modelliert, übersieht oft reale Betriebswege, Ausnahmen, Legacy-Abhängigkeiten und Schattenprozesse, die Angreifer später ausnutzen.

Es gibt nicht die eine Methode, die für jede Umgebung passt. STRIDE ist stark, wenn Anwendungen, Datenflüsse und Vertrauensgrenzen modelliert werden. MITRE ATT&CK ist stark, wenn Angreiferverhalten, Detection und Testfälle operationalisiert werden sollen. Die Kill Chain hilft, Kampagnenlogik und Phasenübergänge zu verstehen. Architekturzentrierte Modelle sind unverzichtbar, wenn hybride Infrastrukturen, Cloud-Identitäten oder OT-Netze betrachtet werden. Reife Teams kombinieren diese Ansätze, statt sich dogmatisch an ein Framework zu klammern.

STRIDE eignet sich besonders für neue Anwendungen, APIs und Plattformdienste. Dort lassen sich Bedrohungen entlang von Datenflüssen und Vertrauensgrenzen systematisch erfassen: Spoofing bei schwacher Authentisierung, Tampering bei ungeschützten Nachrichten, Repudiation bei fehlender Nachvollziehbarkeit, Information Disclosure bei überbreiten API-Antworten, Denial of Service bei fehlender Ressourcenbegrenzung und Elevation of Privilege bei fehlerhaften Rollenmodellen. Für Purple Teaming reicht diese Sicht allein aber nicht aus, weil sie noch nicht beschreibt, wie ein realer Angreifer operativ vorgeht und welche TTPs getestet werden sollen.

Genau dort kommt ATT&CK ins Spiel. Wenn ein Modell zeigt, dass privilegierte Cloud-Identitäten, Remote-Management-Protokolle und schwache Service-Account-Hygiene kritisch sind, lässt sich das auf konkrete Techniken abbilden: Token Theft, Valid Accounts, Remote Services, Scheduled Task, Command and Scripting Interpreter, Credential Access oder Discovery-Techniken. Das Mapping ist besonders wertvoll, wenn es direkt in Und Detection Engineering und Testpläne überführt wird.

Wichtig ist, ATT&CK nicht als Checkliste zu missbrauchen. Nicht jede Technik ist für jede Umgebung relevant. Ein Linux-lastiger Kubernetes-Stack hat andere Prioritäten als ein klassisches Windows-AD mit M365-Hybridbetrieb. Ein OT-Netz mit Engineering-Workstations, Historian und Fernwartung hat andere Angriffspfade als ein SaaS-Unternehmen mit SSO, GitOps und Cloud Workloads. Methoden müssen an die Architektur angepasst werden, nicht umgekehrt.

Ein praxistauglicher Ansatz ist die Kombination aus vier Blickwinkeln: Geschäftsprozess, Architektur, Angreiferverhalten und Nachweisbarkeit. Der Geschäftsprozess definiert, was geschützt werden muss. Die Architektur zeigt, wo Vertrauen und Übergänge liegen. Das Angreiferverhalten beschreibt realistische TTPs. Die Nachweisbarkeit prüft, ob Logs, EDR, Netzwerkdaten und Alarmierungslogik ausreichen. Genau diese vier Ebenen verhindern, dass Threat Modeling zu einer rein akademischen Übung wird.

In Workshops ist es sinnvoll, nicht mit Methodennamen zu starten, sondern mit einer Leitfrage: Welcher Angreifer mit welchem Ziel würde über welchen Pfad in dieser Umgebung am wahrscheinlichsten Erfolg haben? Erst danach wird entschieden, ob STRIDE-Elemente, ATT&CK-Mapping oder Architekturdiagramme die beste Form sind, um die Erkenntnisse festzuhalten. Das Ergebnis muss für Tests, Detection und Priorisierung nutzbar sein, nicht methodisch elegant aussehen.

Der häufigste operative Fehler ist ein Bruch zwischen Modell und Umsetzung. Es wird sauber analysiert, aber die Erkenntnisse landen nicht in konkreten Purple-Team-Aktivitäten. Ein sauberer Workflow schließt diese Lücke. Er beginnt mit der Auswahl eines priorisierten Angriffspfads, übersetzt diesen in testbare Annahmen, definiert Telemetrie und Erfolgskriterien und endet mit einer Rückführung der Ergebnisse ins Modell.

Ein Beispiel: Das Modell zeigt, dass privilegierte Service Accounts in einer Windows-Umgebung breit verteilt sind, Passwortrotation unregelmäßig erfolgt und mehrere Management-Server Remote Service Creation erlauben. Daraus entsteht nicht einfach der Test „psexec ausführen“. Stattdessen werden Hypothesen formuliert: Welche Konten sind realistisch kompromittierbar? Welche Hosts sind als Pivot-Systeme geeignet? Welche Events müssen bei Service-Erstellung, Logon-Typen, SCM-Zugriff und Prozessketten sichtbar sein? Welche EDR-Regeln sollen anschlagen, welche nicht? Welche Abweichungen sind in Admin-Fenstern legitim?

Ein belastbarer Workflow enthält daher immer eine Übersetzungsschicht zwischen Modell und Test. Diese Übersetzung umfasst Scope, Annahmen, Sicherheitsgrenzen, Simulationsgrad, erwartete Artefakte und Abbruchkriterien. Gerade im Purple Teaming ist das entscheidend, weil Tests nicht nur Angriffe nachstellen, sondern gleichzeitig die Verteidigung validieren. Wer diesen Schritt überspringt, produziert oft unklare Ergebnisse: Der Angriff war erfolgreich, aber niemand weiß, ob das an fehlender Detection, an falscher Log-Konfiguration oder an einem unrealistischen Testdesign lag.

Praktisch lässt sich der Ablauf in wenigen, klaren Schritten organisieren:

• Angriffspfad aus dem Modell auswählen und in konkrete Hypothesen, Vorbedingungen und Zielsysteme zerlegen.
• Benötigte Telemetrie, erwartete Events, Detection-Logik und Response-Erwartungen vor dem Test festlegen.
• Ergebnisse nach dem Test in Modell, Detection-Backlog, Härtungsmaßnahmen und Folgeübungen zurückführen.

Dieser Kreislauf ist eng mit Prozess und Iteration verbunden. Ein Angriffspfad wird selten nach einem einzigen Durchlauf vollständig verstanden. Oft zeigt erst der erste Test, dass Logs fehlen, Zeitstempel nicht synchron sind, EDR-Telemetrie auf bestimmten Servern deaktiviert ist oder Admin-Ausnahmen die Erkennung verwässern. Genau diese Erkenntnisse müssen zurück ins Modell, sonst bleibt es statisch und verliert schnell an Wert.

Saubere Workflows definieren außerdem Rollen. Wer moderiert? Wer dokumentiert? Wer führt die Simulation aus? Wer beobachtet im SIEM? Wer entscheidet bei unerwarteten Seiteneffekten? Wer priorisiert Nacharbeiten? Ohne diese Klarheit wird Threat Modeling zwar diskutiert, aber nicht operationalisiert. In reifen Umgebungen ist der Übergang vom Modell zur Übung so standardisiert, dass aus einem priorisierten Angriffspfad innerhalb kurzer Zeit ein reproduzierbarer Purple-Team-Test entsteht.

Die meisten Schwächen im Threat Modeling sind keine Methodenfehler, sondern Denkfehler. Besonders verbreitet ist die Annahme, dass bekannte Schwachstellen automatisch die wichtigsten Risiken darstellen. In der Praxis sind Fehlkonfigurationen, Vertrauensbeziehungen, überprivilegierte Identitäten und blinde Flecken in der Telemetrie oft gefährlicher als einzelne CVEs. Ein ungepatchter Dienst ist sichtbar und messbar. Ein schlecht verstandener Admin-Pfad oder ein zu breites Cloud-Role-Binding bleibt dagegen lange unentdeckt und wird deshalb häufig unterschätzt.

Ein weiterer Fehler ist die Modellierung auf falscher Abstraktionsebene. Zu grob bedeutet: „Active Directory ist kritisch.“ Zu fein bedeutet: Hunderte Einzelbedrohungen ohne Priorisierung. Beides ist unbrauchbar. Das Modell muss so granular sein, dass daraus konkrete Tests und Detection-Anforderungen entstehen, aber so kompakt, dass Entscheidungen möglich bleiben. Gute Modelle arbeiten deshalb mit Angriffspfaden, nicht mit endlosen Listen.

Besonders problematisch ist die Trennung von Architektur und Betrieb. Diagramme zeigen oft Soll-Zustände, nicht Ist-Zustände. In realen Umgebungen existieren temporäre Firewall-Ausnahmen, Legacy-Authentisierung, lokale Admin-Konten, Schatten-APIs, manuelle Betriebswege und Drittanbieterzugänge. Wenn das Modell nur auf Architekturfolien basiert, werden genau die Pfade übersehen, die Angreifer später nutzen. Deshalb müssen Betriebsdaten, IAM-Realität, Logging-Status und tatsächliche Kommunikationsbeziehungen in die Analyse einfließen.

Häufig scheitert Threat Modeling auch an fehlender Priorisierung. Alles wird als kritisch markiert, wodurch am Ende nichts priorisiert ist. Ein brauchbares Modell bewertet nicht nur Schadenspotenzial, sondern auch Angreifbarkeit, Vorbedingungen, vorhandene Kontrollen, Entdeckbarkeit und operative Relevanz. Ein theoretisch schwerwiegender Pfad mit hohen Hürden und guter Detection kann für die nächste Purple-Team-Runde weniger wichtig sein als ein mittelgroßer Pfad mit schwacher Telemetrie und hoher Realisierbarkeit.

Typische Fehlmuster in der Praxis sind:

• Es werden Bedrohungen beschrieben, aber keine testbaren Hypothesen, Erfolgskriterien oder Beobachtungspunkte definiert.
• Das Modell basiert auf Annahmen über Logging und Detection, ohne die tatsächliche Telemetrie im SIEM oder EDR zu verifizieren.
• Nach Übungen werden Erkenntnisse nicht zurückgeführt, sodass das Modell veraltet und künftige Priorisierung verfälscht.

Ein weiterer teurer Fehler ist die fehlende Trennung zwischen Angreiferrealismus und Tool-Fixierung. Teams planen Tests um Werkzeuge herum statt um Angriffspfade. Dann wird etwa „Mimikatz testen“ oder „Cobalt Strike simulieren“ als Ziel formuliert. Das ist zu kurz gedacht. Entscheidend ist nicht das Tool, sondern welche Fähigkeit des Angreifers geprüft wird: Kann ein Angreifer Anmeldedaten auslesen? Kann er sich lateral bewegen? Kann er Cloud-Tokens missbrauchen? Kann er Daten exfiltrieren, ohne aufzufallen? Werkzeuge sind austauschbar, Pfade und Fähigkeiten nicht.

Wer diese Fehler vermeiden will, sollte Threat Modeling eng mit Fehler, Lessons Learned und realen Übungsergebnissen verknüpfen. Ein Modell ist nur dann wertvoll, wenn es durch Praxis korrigiert wird. Alles andere bleibt Papier.

Ein klassisches Beispiel für Threat Modeling im Purple Teaming ist eine hybride Windows-Umgebung mit Active Directory, M365, zentralem EDR und SIEM. Das geschäftliche Ziel des Angreifers kann unterschiedlich sein: Zugriff auf sensible Dateifreigaben, Übernahme privilegierter Konten, Manipulation von Gruppenrichtlinien oder unbemerkte Persistenz in Tier-0-nahen Systemen. Das Modell beginnt mit den Schutzobjekten: Domain Controller, PKI, ADFS oder Entra Connect, Admin-Workstations, Jump Hosts, Backup-Server, Management-Server und hochprivilegierte Gruppen.

Danach werden realistische Einstiege betrachtet. Ein Standard-User-Konto durch Phishing, ein kompromittierter VPN-Zugang, ein lokaler Admin auf einem schlecht gehärteten Server oder ein Helpdesk-Konto mit erweiterten Rechten sind typische Startpunkte. Entscheidend ist nun die Frage, welche Pfade von dort aus tatsächlich existieren. Gibt es lokale Administratorrechte auf mehreren Systemen? Werden Service Accounts interaktiv genutzt? Sind Kerberos-Delegationen sauber eingeschränkt? Existieren alte Scheduled Tasks mit eingebetteten Credentials? Können Admins von unsicheren Workstations aus auf kritische Systeme zugreifen?

Ein gutes Modell beschreibt nicht nur den Pfad, sondern auch die Verteidigungslage. Beispiel Credential Access: Welche LSASS-Schutzmechanismen sind aktiv? Welche EDR-Sensoren laufen auf Servern? Werden Sysmon-Events zentral gesammelt? Gibt es Regeln für verdächtige Handle-Zugriffe, MiniDump-Erstellung, Prozessketten oder signaturlose Speicherzugriffe? Werden 4624-, 4672-, 4688- und Service-Control-Manager-Ereignisse konsistent erfasst? Ohne diese Fragen bleibt unklar, ob ein späterer Purple-Team-Test überhaupt aussagekräftig ist.

Ein möglicher Angriffspfad könnte so aussehen: kompromittierter Benutzer → Passwortspray gegen schlecht überwachte Service Accounts → Zugriff auf Management-Server → Remote Service Creation auf File-Server → Credential Material auslesen → privilegiertes Konto missbrauchen → Zugriff auf Domain-nahe Systeme. Für jede Stufe werden Vorbedingungen, mögliche TTPs, erwartete Spuren und vorhandene Kontrollen dokumentiert. Daraus entsteht ein Testplan, der nicht nur Exploitation, sondern auch Detection und Reaktionszeit bewertet.

In der Praxis zeigt sich oft, dass nicht die erste Kompromittierung das größte Problem ist, sondern die unsichtbaren Übergänge. Lateral Movement über legitime Admin-Tools, WMI, PowerShell Remoting oder geplante Tasks erzeugt häufig weniger Aufmerksamkeit als klassische Malware-Indikatoren. Genau deshalb ist die Verbindung zu Und Threat Detection und Und Log Analyse so wichtig. Das Modell muss festhalten, welche legitimen Betriebsprozesse von Angreiferverhalten missbraucht werden können und wie sich beides sauber trennen lässt.

Ein reifes Team würde diesen Pfad nicht nur einmal testen, sondern in Varianten. Einmal mit offensichtlichen Tools, einmal mit Living-off-the-Land-Techniken, einmal mit reduziertem Rauschen, einmal mit Fokus auf Identitätsartefakte. Erst durch diese Varianten wird sichtbar, ob Detection robust ist oder nur auf einzelne Werkzeuge reagiert.

In Cloud- und SaaS-Umgebungen scheitert Threat Modeling oft daran, dass klassische Netzgrenzen überschätzt werden. Der eigentliche Angriffsraum liegt meist in Identitäten, Rollen, Tokens, API-Berechtigungen und Automatisierungsbeziehungen. Ein kompromittierter Entwickler-Account mit Zugriff auf CI/CD, Container-Registry und Cloud-Subscription kann gefährlicher sein als ein einzelner exponierter Host. Das Modell muss daher Identitätsflüsse und Vertrauensbeziehungen in den Mittelpunkt stellen.

Ein typischer Fehler ist die isolierte Betrachtung einzelner Plattformen. M365, Azure, AWS, GitHub, Jira, Slack und IdP werden getrennt bewertet, obwohl Angreifer genau die Übergänge zwischen diesen Systemen nutzen. Ein OAuth-Token aus einer SaaS-Anwendung kann Zugriff auf Daten oder Workflows eröffnen, die in einem anderen System weiterverwendet werden. Ein Service Principal mit zu breiten Rechten kann aus einer Pipeline heraus Infrastruktur verändern. Ein kompromittiertes Repository kann Secrets, Deployments und Artefakte beeinflussen. Das Bedrohungsmodell muss diese Ketten sichtbar machen.

Praktisch beginnt die Modellierung mit Fragen wie: Welche Identitäten sind menschlich, welche maschinell? Wo werden Tokens gespeichert? Welche Rollen sind dauerhaft statt just-in-time vergeben? Welche Federation-Beziehungen existieren? Welche Conditional-Access-Regeln lassen Ausnahmen zu? Welche Audit-Logs sind aktiviert und wie lange verfügbar? Welche Aktionen sind in CloudTrail, Entra Audit, Sign-In Logs oder SaaS-Admin-Logs tatsächlich sichtbar? Ohne diese Basis bleibt jede Purple-Team-Übung in der Cloud unvollständig.

Ein realistischer Angriffspfad könnte über ein kompromittiertes Entwicklerkonto starten. Von dort aus werden gespeicherte CLI-Credentials oder Browser-Tokens missbraucht, anschließend Pipeline-Secrets ausgelesen, ein Build manipuliert oder ein Service Principal mit übermäßigen Rechten verwendet. Das Ziel kann Datendiebstahl, Persistenz über neue App-Registrierungen oder die unbemerkte Veränderung von Infrastruktur sein. Das Modell muss für jede Stufe festhalten, welche API-Aufrufe, Rollenänderungen, Token-Nutzungen und Policy-Verletzungen sichtbar sein sollten.

Gerade in Cloud-Umgebungen ist die Verbindung zu Und Threat Hunting zentral. Viele Angriffe sind nicht durch einzelne harte Signaturen erkennbar, sondern durch Verhaltensmuster: ungewöhnliche Token-Nutzung, neue Consent Grants, seltene Regionen, atypische API-Sequenzen, plötzliche Rollenänderungen oder Service-Principal-Aktivität außerhalb normaler Deployments. Ein gutes Threat Model liefert die Hypothesen, nach denen später gejagt wird.

Wer Cloud-Threat-Modeling ernst nimmt, modelliert außerdem Kontrollversagen. Nicht nur „Kann ein Angreifer X tun?“, sondern auch „Welche Schutzmaßnahme hätte das verhindern oder sichtbar machen müssen, und warum würde sie hier versagen?“ Diese Sicht ist besonders wertvoll, wenn Purple-Team-Übungen nicht nur Angriffe simulieren, sondern Architektur- und Governance-Lücken offenlegen sollen.

Ein Threat Model ohne Telemetriebezug ist für Purple Teaming nur halb brauchbar. Es beschreibt dann zwar Risiken, aber nicht, ob diese Risiken beobachtbar sind. Genau deshalb muss jedes priorisierte Szenario mit einer Telemetrie-Matrix verknüpft werden. Für jeden Angriffsschritt wird festgelegt, welche Datenquellen verfügbar sind, welche Felder relevant sind, welche Korrelationen möglich sind und welche Lücken bestehen. Erst dann lässt sich entscheiden, ob ein Test Detection validiert oder nur Logging-Defizite offenlegt.

Diese Verknüpfung beginnt bei den Datenquellen: Endpoint-Telemetrie, Authentifizierungslogs, Prozessdaten, Netzwerkverbindungen, Proxy-Logs, DNS, Cloud-Audit, IAM-Änderungen, E-Mail-Signale, Container-Runtime-Events oder OT-spezifische Protokolldaten. Danach folgt die Frage nach Qualität und Kontext. Werden Events vollständig geliefert? Sind Hostnamen, Benutzer, Prozesspfade und Parent-Child-Beziehungen konsistent? Gibt es Zeitdrift? Werden Felder normalisiert? Sind Aufbewahrungszeiten ausreichend? Viele Detection-Probleme sind keine Regelprobleme, sondern Datenprobleme.

Ein sauberer Ansatz arbeitet pro Angriffspfad mit Beobachtungspunkten. Beispiel: Bei lateralem Zugriff über Remote Services sind nicht nur Prozessstarts relevant, sondern auch Service-Erstellung, Logon-Typen, Zielhost-Kontext, Quellidentität, ungewöhnliche Admin-Pfade und zeitliche Nähe zu Credential-Access-Aktivitäten. Bei Cloud-Missbrauch sind nicht nur Login-Events wichtig, sondern Token-Arten, App-IDs, Rollenänderungen, neue Federation-Objekte oder API-Aufrufe außerhalb normaler Deployment-Fenster.

Threat Modeling wird dadurch zu einer Brücke zwischen Architektur und Messbarkeit. Es definiert, welche Signale für welchen Pfad zwingend vorhanden sein müssen. Fehlen diese Signale, ist das selbst ein priorisierter Befund. In vielen Umgebungen ist genau das der größte Mehrwert: Nicht die Erkenntnis, dass ein Angriff theoretisch möglich ist, sondern dass seine kritischen Zwischenschritte heute nicht sauber sichtbar wären.

Für die operative Umsetzung ist die Verzahnung mit Und Siem, EDR und Alarmierungslogik entscheidend. Detection-Regeln sollten nicht losgelöst entwickelt werden, sondern direkt aus priorisierten Angriffspfaden entstehen. Ein Modell, das Credential Theft, Token-Missbrauch und Privilege Escalation als Top-Risiken ausweist, muss sich in konkreten Use Cases, Korrelationen und Triage-Hinweisen widerspiegeln. Sonst bleibt Detection reaktiv und generisch.

Messbarkeit bedeutet außerdem, Erfolgskriterien vorab zu definieren. Wurde der Angriff erkannt? In welcher Phase? Mit welcher Qualität? Gab es Kontext für Triage? War die Alarmierung handhabbar oder nur laut? Konnte das SOC den Pfad rekonstruieren? Wurden Folgeaktionen sichtbar? Diese Fragen gehören bereits ins Threat Model, weil sie bestimmen, welche Übungen sinnvoll sind und welche Datenquellen zuerst verbessert werden müssen.

Threat Modeling scheitert oft nicht an Technik, sondern an schlechter Dokumentation. Entweder wird zu wenig festgehalten, sodass Erkenntnisse verloren gehen, oder es entstehen überladene Artefakte, die niemand pflegt. Ziel ist eine Form der Dokumentation, die für Security Engineering, SOC, Architektur und Management gleichzeitig nutzbar ist. Das gelingt nur, wenn zwischen Kernmodell, Testableitungen und Maßnahmen sauber getrennt wird.

Das Kernmodell beschreibt Schutzobjekte, Vertrauensgrenzen, Angriffspfade, Annahmen und Priorität. Die Testableitung übersetzt priorisierte Pfade in konkrete Purple-Team-Szenarien, Telemetrieanforderungen und Erfolgskriterien. Die Maßnahmenliste enthält Härtung, Logging, Detection, Prozessänderungen und offene Risiken. Diese Trennung verhindert, dass operative Details das Modell unlesbar machen oder strategische Aussagen in Ticket-Listen untergehen.

Priorisierung sollte nachvollziehbar und wiederholbar sein. Sinnvoll ist eine Bewertung entlang von Geschäftsauswirkung, Angreifbarkeit, Vorbedingungen, Reichweite des Pfads, Qualität vorhandener Kontrollen und Sichtbarkeit in der Telemetrie. Ein Pfad mit moderater Auswirkung, aber hoher Realisierbarkeit und schwacher Detection kann operativ dringender sein als ein theoretisch katastrophaler Pfad mit starken Hürden. Genau diese Differenzierung fehlt in vielen Programmen.

Governance bedeutet dabei nicht, jedes Modell durch mehrere Gremien zu schleusen. Entscheidend ist ein klarer Eigentümer pro Modell oder Domäne, ein definierter Review-Zyklus und ein Trigger für Aktualisierungen. Solche Trigger sind etwa Architekturänderungen, neue Internet-Exponierung, Migrationsprojekte, neue Drittanbieteranbindungen, größere Incidents oder Ergebnisse aus Purple-Team-Übungen. Ohne Trigger veralten Modelle schleichend.

Dokumentation muss außerdem anschlussfähig sein. Wenn ein Angriffspfad priorisiert wird, sollte daraus direkt ein Eintrag in Playbook, Dokumentation oder Reporting entstehen können. Ebenso sollten Lessons Learned aus Übungen wieder auf das Modell zurückwirken. Diese Rückkopplung ist der Unterschied zwischen lebendiger Bedrohungsmodellierung und statischer Compliance-Ablage.

Ein praxistaugliches Minimalformat pro Angriffspfad umfasst Ziel, Startpunkt, Vorbedingungen, betroffene Assets, relevante TTPs, vorhandene Kontrollen, benötigte Telemetrie, erwartete Detection, Teststatus, offene Lücken und nächste Maßnahmen. Mehr ist oft nicht nötig. Weniger führt meist dazu, dass Tests und Nacharbeiten nicht sauber anschließen.

Threat Modeling entfaltet seinen Wert erst dann vollständig, wenn es nicht als Einzelaktivität, sondern als dauerhafte Sicherheitsdisziplin betrieben wird. In unreifen Umgebungen wird modelliert, wenn ein Audit ansteht oder ein Projekt gestartet wird. In reifen Umgebungen ist Bedrohungsmodellierung Teil von Architekturentscheidungen, Purple-Team-Planung, Detection-Priorisierung, Incident-Nachbereitung und Change-Prozessen. Dadurch entsteht ein gemeinsames Lagebild, das technische Teams tatsächlich nutzen können.

Der Reifegrad steigt, wenn Modelle regelmäßig mit realen Beobachtungen abgeglichen werden. Incidents, Near Misses, Threat-Intel-Hinweise, neue TTPs, Architekturänderungen und Ergebnisse aus Übungen liefern laufend Material zur Korrektur. Ein Modell, das nie widerlegt wird, ist meist zu abstrakt. Ein gutes Modell wird ständig geschärft: Annahmen werden bestätigt oder verworfen, Pfade werden neu priorisiert, Detection wird ergänzt, Härtung wird angepasst.

Besonders wirksam ist die Kopplung an konkrete Kennzahlen, ohne in Metrik-Theater zu verfallen. Relevant sind nicht bloß die Anzahl modellierter Systeme oder durchgeführter Workshops, sondern operative Fragen: Für wie viele priorisierte Angriffspfade existieren testbare Hypothesen? Für wie viele liegen belastbare Detection-Use-Cases vor? Wie viele kritische Pfade wurden in den letzten Zyklen praktisch validiert? Wie viele Telemetrielücken wurden geschlossen? Wie oft wurden Modelle nach Architekturänderungen aktualisiert? Solche Kennzahlen zeigen, ob das Programm tatsächlich wirksam ist.

Threat Modeling ist außerdem ein starkes Mittel, um Diskussionen zwischen Red, Blue, Engineering und Management zu versachlichen. Statt abstrakt über „mehr Sicherheit“ zu sprechen, wird über konkrete Pfade, Kontrollen und Nachweisbarkeit gesprochen. Das verbessert Entscheidungen über Härtung, Logging, Segmentierung, IAM und Investitionen. Gerade im Vergleich zu rein punktuellen Tests liefert Bedrohungsmodellierung den Kontext, warum bestimmte Maßnahmen Vorrang haben. Wer die Unterschiede zwischen Teamrollen besser einordnen will, findet ergänzende Perspektiven unter Purple Team Vs Red Team Vs Blue Team.

Am Ende ist ein gutes Threat Model kein Selbstzweck. Es ist ein Arbeitsinstrument, das Angriffsrealität, Verteidigungsfähigkeit und technische Umsetzung miteinander verbindet. Wenn daraus priorisierte Szenarien, bessere Detection, präzisere Hunts, sauberere Übungen und nachvollziehbare Entscheidungen entstehen, erfüllt es seinen Zweck. Wenn es nur Risiken beschreibt, aber keine Handlungen auslöst, ist es zu schwach oder zu weit von der operativen Realität entfernt.

Genau deshalb gehört Threat Modeling in jede ernsthafte Strategie für Purple Teaming: nicht als Pflichtdokument, sondern als Mechanismus, um aus Wissen über Systeme, Angreifer und Telemetrie konkrete Verteidigungsfähigkeit zu machen.