Threat Modeling als wiederkehrender Prozess: vom Workshop zum Sicherheits-Backlog

Marcel Rieger

Managing Director, Cyber Risk

Viele Entwicklungsteams haben schon einmal einen Threat-Modeling-Workshop gemacht. Danach gab es ein schönes Diagramm im Wiki und eine Liste möglicher Angriffe, und dann passierte nichts mehr. Ein halbes Jahr später hat sich die Architektur geändert, das Modell nicht. Dieser Artikel beschreibt, wie Sie Threat Modeling so aufsetzen, dass es bei jeder relevanten Änderung mitläuft, Maßnahmen im normalen Backlog landen und das Ergebnis als Nachweis für Ihre Risikobewertung nach dem Cyber Resilience Act taugt.

Was Threat Modeling leisten soll

Das Threat Modeling Manifesto, verfasst von einer Gruppe erfahrener Praktiker, beschreibt Threat Modeling als Analyse von Darstellungen eines Systems, um Sicherheits- und Datenschutzprobleme sichtbar zu machen. Es fasst die Methode in vier Fragen: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir gut genug gearbeitet? Unter den Werten des Manifests steht ausdrücklich die fortlaufende Verfeinerung statt einer einmaligen Lieferung.

Threat Modeling ist damit weder ein Penetrationstest noch ein Compliance-Dokument. Ein Pentest findet Fehler in fertigem Code. Threat Modeling findet Schwächen im Entwurf, bevor Code entsteht, und sein Ergebnis sind Entscheidungen und Arbeitspakete.

Warum der CRA das Thema verschärft

Die Cyberresilienz-Verordnung (EU) 2024/2847 verlangt in Artikel 13 von Herstellern eine Bewertung der Cybersicherheitsrisiken ihres Produkts. Das Ergebnis muss in Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung berücksichtigt werden. Die Bewertung wird dokumentiert, während des Unterstützungszeitraums gegebenenfalls aktualisiert und Teil der technischen Dokumentation. Die Pflichten gelten ab dem 11. Dezember 2027.

Den Begriff Threat Modeling verwendet die Verordnung nicht. Für den Teil der Risikobewertung, der Architektur und Schnittstellen betrifft, ist ein gepflegtes Bedrohungsmodell aber der praktikabelste Weg. Das BSI zeigt in Teil 1 seiner Technischen Richtlinie TR-03183 an einem Beispiel, wie eine solche Analyse mit einem Datenflussdiagramm und Vertrauensgrenzen aussehen kann. Die Richtlinie ist nicht verbindlich, aber für Hersteller ohne eingespielten Prozess eine gute Vorlage.

Wer Komponenten für die Industrie entwickelt, kennt die Anforderung womöglich schon aus IEC 62443-4-1. Dort ist ein produktspezifisches Bedrohungsmodell eine eigene Anforderung im Entwicklungsprozess.

Der Ablauf einer Sitzung

Modellieren Sie nie das ganze Produkt auf einmal. Eine Sitzung behandelt ein Feature, eine Komponente oder eine Schnittstelle und dauert 90 bis 120 Minuten. Dabei sind der Architekt oder die leitende Entwicklerin, der Product Owner, jemand aus Betrieb oder Infrastruktur und eine Person aus der Security, die moderiert.

1. Zeichnen Sie ein Datenflussdiagramm mit Komponenten, Datenspeichern, externen Akteuren, Datenflüssen und Vertrauensgrenzen. Eine Vertrauensgrenze liegt überall dort, wo Daten von einem Bereich in einen anderen mit anderem Schutzniveau wechseln, etwa vom Internet ins Backend oder vom Servicetechniker auf die Steuerung.
2. Gehen Sie jedes Element und jeden Fluss über eine Vertrauensgrenze mit STRIDE durch. Die sechs Kategorien stehen für das Vortäuschen einer Identität, Manipulation, Abstreiten von Aktionen, Preisgabe von Informationen, Störung der Verfügbarkeit und Erhöhung von Rechten.
3. Bewerten Sie jede Bedrohung mit der Skala, die Ihr Risikomanagement ohnehin verwendet, zum Beispiel drei Stufen für Eintrittswahrscheinlichkeit und Auswirkung. Aufwendige Punktesysteme kosten in der Sitzung viel Zeit und bringen wenig. CVSS eignet sich hier nicht, es bewertet Schwachstellen, keine Entwurfsrisiken.
4. Legen Sie für jede relevante Bedrohung fest, was passiert: eine Maßnahme, eine bewusste Akzeptanz mit Verantwortlichem oder die Übertragung an einen anderen Bereich.

Am Ende der Sitzung steht kein Bericht, sondern eine Liste von Entscheidungen mit Namen dahinter.

Vom Bedrohungskatalog zum Backlog

Der häufigste Fehler nach dem Workshop: Die Maßnahmen landen in einem separaten Dokument der Security und nicht dort, wo das Team plant. Schreiben Sie jede Maßnahme als Eintrag ins normale Backlog, mit prüfbaren Akzeptanzkriterien und einem Verweis auf die Bedrohung. „Sichere Authentifizierung“ ist kein Backlog-Eintrag. „Zugriffstoken der Service-App laufen nach 15 Minuten ab, Refresh nur mit gebundenem Gerät“ ist einer.

Unterscheiden Sie dabei drei Arten von Ergebnissen. Anforderungen an neuen Code gehören in Story und Definition of Done. Schwächen in bestehendem Code sind Schwachstellen und laufen mit Frist durch Ihr Schwachstellenmanagement. Bewusst akzeptierte Risiken kommen ins Risikoregister, mit Verantwortlichem und Wiedervorlagedatum.

So entsteht eine Kette von der Bedrohung über die Maßnahme und den Test bis zum Release. Diese Kette ist der Nachweis, den Auditoren und Marktüberwachung sehen wollen, und sie entsteht nebenbei, wenn die Verweise sauber gepflegt werden. Wie Anforderungen, Tests und Nachweise in der Produktsicherheit zusammenhängen, beschreibt Product Security: Requirements, Tests, Evidence.

Wann das Modell aktualisiert wird

Ein Bedrohungsmodell veraltet nicht nach Kalender, sondern mit Änderungen. Die TR-03183-1 nennt als Anlässe für die Aktualisierung der Risikobewertung unter anderem sicherheitsrelevante Produktupdates, neu bekannte Schwachstellen und neue Angriffsmethoden, und sie empfiehlt zusätzlich regelmäßige Überprüfungen. In der Entwicklung übersetzen wir das in konkrete Auslöser:

• Eine neue externe Schnittstelle oder API kommt hinzu.
• Authentifizierung oder Berechtigungen ändern sich.
• Das Produkt verarbeitet eine neue Kategorie von Daten, etwa personenbezogene oder Produktionsdaten.
• Eine neue Fremdkomponente oder ein Cloud-Dienst erhält Zugriff auf Daten.
• Das Betriebsmodell ändert sich, zum Beispiel von der lokalen Installation zur Cloud.
• Ein Sicherheitsvorfall oder eine relevante Schwachstelle betrifft das Produkt oder eine eingebundene Komponente.

Damit die Auslöser nicht vergessen werden, gehört eine Frage in die Definition of Ready jeder Story: Verändert diese Story eine Vertrauensgrenze oder einen der Punkte oben? Wenn ja, folgt eine Delta-Sitzung von 30 bis 60 Minuten, die nur den geänderten Teil des Modells betrachtet. Zusätzlich lohnt eine vollständige Durchsicht pro Produkt einmal im Jahr.

Halten Sie das Modell versioniert und nah am Code. Werkzeuge wie OWASP Threat Dragon oder das kostenlose Microsoft Threat Modeling Tool speichern Modelle als Dateien, die neben dem Quellcode im Repository liegen können. Dann ist auch nachvollziehbar, welcher Stand des Modells zu welchem Release gehörte.

Rollen und realistischer Aufwand

In den ersten Sitzungen moderiert die Security oder ein externer Berater. Parallel bilden Sie in jedem Team ein bis zwei Security Champions aus, die später selbst moderieren. Die Entscheidung über Maßnahmen und Akzeptanzen trifft der Product Owner, größere Restrisiken gehen an Produktmanagement oder Geschäftsführung.

Für ein bestehendes Produkt sollten Sie zum Start mit zwei bis drei halbtägigen Sitzungen rechnen, um die wichtigsten Komponenten abzudecken. Danach entsteht der Aufwand vor allem in den Delta-Sitzungen. Typische Stolpersteine sind ein Modell, das die Security allein erstellt, Bedrohungen ohne Verantwortlichen und fehlende Auslöser, weshalb das Modell nach zwei Releases niemand mehr anschaut.

Wo Threat Modeling im gesamten Entwicklungsprozess sitzt, neben Sicherheitsanforderungen, Tests und Release-Gates, zeigt Secure SDLC: Controls, Gates, Metrics. Für die Komponenten, die Sie nicht selbst schreiben, ist SBOM und Dependency-Scanning das Gegenstück.

Der erste Schritt in Ihrem Unternehmen

Wählen Sie die Komponente mit den meisten Schnittstellen nach außen, etwa das Kundenportal oder den Fernwartungszugang einer Maschine. Planen Sie zwei Stunden mit den genannten Rollen, zeichnen Sie das Datenflussdiagramm und gehen Sie die Flüsse über Vertrauensgrenzen mit STRIDE durch. Wenn danach fünf bis zehn konkrete Einträge im Backlog stehen und die Auslöserfrage in der Definition of Ready verankert ist, haben Sie den Prozess gestartet. Wie diese Arbeit in die CRA-Vorbereitung insgesamt passt, beschreibt CRA Readiness: Secure-by-Design und Vulnerability Handling.