KI-gestützte Bedrohungsmodellierung & sichere Entwurfsprüfung

Bedrohungsmodellierung ist die günstigste Sicherheitsaktivität und die, die am häufigsten ausgelassen wird, weil sie knappe Expertinnen und Experten braucht und nach dem ersten Workshop veraltet. LLMs können Architekturdokumente und Diagramme lesen, STRIDE- oder LINDDUN-Bedrohungsmodelle entwerfen, Gegenmaßnahmen vorschlagen und bei Änderungen am Entwurf erneut laufen. Die Fachleute wechseln vom Autor vor dem leeren Blatt zum Prüfer, sodass jeder wesentliche Entwurf ein erstes Modell erhält, bevor Code existiert.

Problem & Nutzen

• Heute: Bedrohungsmodellierung findet in Workshops weniger Sicherheitsarchitekten statt, wird in Folien oder Tabellen dokumentiert und selten aktualisiert. Die meisten Teams modellieren gar nicht; die Entwicklung ist schneller, als das Sicherheitsteam prüfen kann.
• KI-Nutzen: ein Modellentwurf in Minuten statt Tagen, gleichmäßige Abdeckung eines Bedrohungskatalogs, Neubewertung bei jeder Änderung des Entwurfs (Pull Request auf eine Architekturdatei) und Abdeckung KI-spezifischer Bedrohungen (Prompt-Injection, Werkzeugmissbrauch, Data Poisoning), die klassische Checklisten übersehen.
• Regulatorischer Sog: Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verlangt von Herstellern von Produkten mit digitalen Elementen, Entwurf und Entwicklung auf eine Cybersicherheits-Risikobewertung zu stützen (Art. 13, Anhang I); die Hauptpflichten gelten ab dem 11. Dezember 2027 [1]. NIS2 (Richtlinie (EU) 2022/2555, Art. 21) verlangt von erfassten Einrichtungen risikobasierte Maßnahmen, darunter sichere Entwicklung [2]. Ein lebendes Bedrohungsmodell ist für beides ein naheliegender Nachweis.
• Qualität der Belege: Akademische Auswertungen KI-gestützter Werkzeuge stellen fest, dass sie viele Bedrohungen manueller Referenzmodelle wiederfinden, aber Assets erfinden können, die im System nicht vorkommen; sie eignen sich daher noch nicht als eigenständiger Ersatz für Fachleute [3][4]. Ein belastbarer, veröffentlichter Prozentwert für Zeitersparnis wird hier nicht genannt.

Varianten

• Produktsicherheit (CRA): Hersteller von Hardware/Software modellieren Geräte und Cloud-Backends.
• Prüfung interner Anwendungen: Eingang beim Architekturgremium; die KI liest die Entwurfsdokumente vorab.
• Modellierung agentischer und LLM-Anwendungen: Agenten, Werkzeuge, Speicher und MCP-Server als Assets, mit agentenspezifischen Frameworks (ASTRIDE, CSA MAESTRO, OWASP-Hinweise zu Agenten) [4][5].
• Modellierung von Datenschutzbedrohungen: LINDDUN für Datenschutz durch Technikgestaltung nach DSGVO und als Eingabe für die DSFA.
• Cloud-/IaC-Prüfung: das Datenflussmodell direkt aus Terraform- oder Kubernetes-Dateien ableiten.
• KMU: ein schlanker, checklistengetriebener Assistent, den die Entwicklungsleitung statt eines Sicherheitsarchitekten betreibt.

So funktioniert es

1. Entwurfsartefakte (Dokumente, Diagramme, User Stories, IaC)
2. Extraktion (VLM liest Diagramm
3. Komponenten, Datenflüsse, Vertrauensgrenzen als strukturiertes JSON)
4. Mensch bestätigt/korrigiert das Systemmodell [HITL 1]
5. Bedrohungserzeugung (STRIDE je Element / LINDDUN / agentenspezifische Kategorien; RAG über Kataloge)
6. Angriffsbäume & Missbrauchsfälle; Zuordnung zu CAPEC, ATT&CK, ATLAS, CWE
7. Risikobewertung und Maßnahmenvorschläge (Kontrollen, Anforderungen aus ASVS / NIS2 / CRA Anhang I)
8. Prüfung durch Sicherheitsfachleute, annehmen/ablehnen/anpassen [HITL 2]
9. Tickets im Backlog + Modell als Code gespeichert (z. B. OWASP pytm, Threagile, Threat-Dragon-JSON)
10. Auslöser bei Entwurfsänderung (PR-Diff auf Architekturdateien)
11. Delta-Bewertung

• Zuerst das Systemmodell: der wichtigste Schritt. Fehler bei extrahierten Komponenten setzen sich in jeder Bedrohung fort, deshalb bestätigt ein Mensch das Modell, bevor Bedrohungen erzeugt werden.
• Verankerung: Abruf über kuratierte Kataloge (STRIDE, CAPEC, ATLAS, OWASP LLM Top 10) und die eigene Kontrollbibliothek der Organisation reduziert erfundene Bedrohungen; jede Bedrohung muss eine Komponente benennen.
• Bedrohungsmodell als Code ermöglicht Diffs und Reviews in der Versionsverwaltung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Fachleute geben Risikobewertungen und akzeptierte Risiken frei; die KI schließt nie eine Bedrohung.

Datenaufbereitung

Die Eingaben sind Architekturbeschreibungen, Diagramme, User Stories und Infrastructure-as-Code. Sie liegen in Wikis (Confluence, SharePoint), Zeichenwerkzeugen (draw.io, Visio, PowerPoint), im Git-Repository und manchmal nur auf Fotos von Whiteboards oder in den Köpfen der Beteiligten.

Typische Lücken: Diagramme existieren nur als Bilder oder veraltete Folien, es sind keine Vertrauensgrenzen oder Datenklassifizierungen eingezeichnet, User Stories enthalten keine Sicherheitsanforderungen, das Wissen über Altsysteme ist verstreut, und Dokumente auf Dateiablagen haben einen unklaren Aktualitätsstand.

Schritte der Aufbereitung: (1) Diagramme als Diagramm-als-Code (Mermaid, Structurizr, draw.io-XML) neben dem Code ablegen (PREP-014); (2) Datenklassen und Vertrauensgrenzen in den Modellen kennzeichnen (PREP-019); (3) die Kontrollbibliothek der Organisation und frühere Bedrohungsmodelle als RAG-Quelle sammeln (PREP-013, PREP-016); (4) alte Visio- oder PDF-Dokumentation per OCR erfassen und konvertieren (PREP-006, PREP-007); (5) ein Glossar der Komponentennamen festlegen (PREP-015); (6) einige geprüfte Referenzmodelle als Bewertungssatz aufbauen (PREP-018).

Werkzeuge: Git, draw.io, Mermaid, Paperless-ngx oder eine beliebige OCR für alte PDFs. Grober Aufwandsanteil: etwa 30 Prozent, vor allem die einmalige Arbeit, das Systemmodell zu dokumentieren, die auch über diesen Anwendungsfall hinaus nützlich ist. Siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• smb: B, weil wenige KMU einen Sicherheitsarchitekten haben und ein schlankes Skript oder ein Workflow, der ein Cloud-LLM über die eigenen Entwurfsdokumente aufruft, die spezialisierten Produkte zur Bedrohungsmodellierung schlägt, die ein Sicherheitsteam voraussetzen.
• enterprise: C, weil Architekturdiagramme, Infrastrukturcode und bekannte Schwachstellen Geschäftsgeheimnisse sind und ein selbst betriebenes Modell auf der Hardware der gemeinsamen KI-Plattform sie im Haus hält.
• developer: B, weil Cloud-KI-Dienste plus offene Werkzeuge wie OWASP pytm, Threagile oder Threat Dragon sich mit geringem Aufwand in Pull-Request-Abläufe einbinden lassen.

Weg A — Kaufen

• IriusRisk (Spanien/EU-verwurzelt; Plattform zur Bedrohungsmodellierung mit KI-gestützter Modellerstellung und Inhalten mit CRA-Bezug), ThreatModeler, Microsoft Threat Modeling Tool (kostenlos, ohne KI), SD Elements (Security Compass), Apiiro (AI Threat Modeling aus Entwurfsdokumenten), Cycode und ähnliche ASPM-Werkzeuge (Funktionen für Entwurfsrisiken unterscheiden sich und sind vom Anbieter angegeben). Klären Sie die aktuellen KI-Funktionen mit dem Anbieter.
• A wählen, wenn: viele Teams beteiligt sind und Sie Governance, Workflow, Berichte und Prüfpfad sowie Integration mit Jira und CI brauchen.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Modelle: ein starkes Reasoning-LLM plus ein multimodales Modell für Diagramme (Claude, Gemini, GPT, Mistral in EU-Regionen; Mistral ist ein EU-Anbieter). Nutzen Sie strukturierte Ausgaben gegen ein Schema (Komponenten, Flüsse, Vertrauensgrenzen, Bedrohungen).
• Orchestrierung: eine kleine Pipeline in der CI; Auslöser sind Änderungen an docs/architecture/** oder an IaC; das Bedrohungs-Delta als PR-Kommentar posten und Tickets anlegen.
• Ausgangspunkt: STRIDE GPT, Open Source, unterstützt mehrere Anbieter und agentische Codebasis-Analyse mit Zuordnung zu OWASP-Agenten und MITRE ATT&CK/ATLAS [3].
• B wählen, wenn: Sie ein Plattform- oder Security-Engineering-Team haben und die Entwurfsdokumente vertraulich sind, die Verarbeitung in der Cloud unter einem AVV mit EU-Region aber akzeptabel ist.

Weg C — Selbst betreiben

• Modelle: Open-Weight-Reasoning-/Instruct-Modelle, bereitgestellt mit vLLM oder Ollama, z. B. aus den Familien Qwen3, gpt-oss, Llama, Mistral; ein VLM wie Qwen-VL für Diagramme. Architekturdokumente gehören zum sensibelsten geistigen Eigentum, daher ist lokale Inferenz hier ein echtes Argument.
• Stack: STRIDE GPT mit lokalem Modell, OWASP pytm oder Threagile für Modell-als-Code, ein Vektorspeicher über die Kataloge, n8n oder CI-Jobs.
• Hardware: HW3 für Modelle mit Reasoning-Niveau (~30-120B); HW2 reicht für kleinere Modelle bei mehr menschlicher Korrektur.

Weg D — Eigenes Training

Selten gerechtfertigt. Möglich: Feintuning auf früheren geprüften Bedrohungsmodellen einer Organisation, um deren Taxonomie und Risikoskalen zu treffen; dafür braucht es Hunderte freigegebener Modelle, die nur wenige Organisationen haben. RAG über frühere Reviews erreicht meist den Großteil des Nutzens.

Stand der Technik (2026)

• Agentenspezifische Erweiterungen von STRIDE: ASTRIDE ergänzt eine Kategorie für Angriffe auf KI-Agenten (Prompt- Injection, unsicherer Werkzeugaufruf) und nutzt VLMs plus einen LLM-Reasoning-Schritt auf Architektur- diagrammen [4]. STRIDE-AI (Preprint 2026) verbindet STRIDE mit dem NIST AI RMF und den OWASP LLM Top 10 [6]. CSA MAESTRO bietet ein Schichtenmodell für agentische Systeme [5].
• Von Diagramm zu Modell mit VLMs funktioniert bei sauberen Diagrammen; unordentliche Whiteboard-Fotos und Diagramme ohne Vertrauensgrenzen verschlechtern die Ergebnisse.
• Grenzen und Fehlerbilder: erfundene Komponenten, generische Bedrohungen („Angreifer stiehlt Daten“), übersehene Bedrohungen der Geschäftslogik und systemübergreifende Bedrohungen, uneinheitliche Risikobewertung zwischen Läufen und trügerische Sicherheit durch eine professionell wirkende Ausgabe. Gegenmaßnahmen: vom Menschen bestätigte Systemmodelle, Nennung der Komponenten, wiederholte Läufe und Freigabe durch Fachleute. Die Modellqualität hängt von der Qualität der Eingabedokumentation ab.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: Reasoning-LLM + VLM + RAG wie in SEC-010 (Leitplanken), SEC-014 (KI-Red-Teaming), SEC-004 (Code-Scanning), CODE-006 (Erzeugung von Architekturdokumentation).
• Vorgelagert/nachgelagert: Das Bedrohungsmodell speist SEC-007 (Testumfang für Pentests), SEC-014 (Red-Team-Szenarien für LLM-Anwendungen), SEC-009 (Compliance-Nachweise für NIS2/CRA) und SEC-022 (Dokumentation von KI-Systemen und Risikoklassifizierung). SEC-013 liefert das Inventar der zu modellierenden KI-Agenten. CODE-003 prüft später Code gegen die hier definierten Gegenmaßnahmen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für die Einführung; Lizenzen pro Arbeitsplatz oder pro Anwendung.
• Weg B: 2-6 Wochen für einen in die CI integrierten Prototyp; die Token-Kosten sind gering (eine Entwurfsprüfung umfasst einige zehntausend Token); die Hauptkosten sind der Prüfaufwand der Fachleute sowie die Pflege von Prompts und Katalogen.
• Weg C: 1-3 Monate inkl. GPU-Server und Bewertung.
• Kennzahlen: Anteil neuer Entwürfe mit Bedrohungsmodell vor der Umsetzung; Änderungsquote durch Fachleute (Bedrohungen akzeptiert gegenüber abgelehnt gegenüber erfunden); in Tickets überführte und geschlossene Maßnahmen; Zeit von der Entwurfsänderung bis zum aktualisierten Modell; Befunde in der Entwurfsphase gegenüber später im Pentest gefundenen (SEC-007); Vollständigkeit der Prüfnachweise für CRA/NIS2.

Menschen & Veränderung

Das Projekt leitet die Leitung Sicherheit oder Architektur; Entwickler und Product Owner sind die täglichen Nutzer und müssen das extrahierte Systemmodell bestätigen. Die IT stellt den Repository-Zugriff bereit, die Geschäftsleitung fördert das Thema, und Datenverantwortliche geben die Dokumentation kritischer Systeme frei. Beziehen Sie die oder den Informationssicherheitsbeauftragte(n) für die Klassifizierung der Entwurfsdokumente ein.

Betriebsrat: im Normalfall nein, weil das Werkzeug Systeme analysiert, nicht Personen, und das Ergebnis nicht zur Bewertung von Einzelnen genutzt wird. Prüfen Sie erneut, wenn Ergebnisse mit der Leistung einzelner Entwickler verknüpft oder Commits je Person ausgewertet werden; dann kann § 87 Abs. 1 Nr. 6 BetrVG greifen. Informieren Sie den Betriebsrat dennoch über die Einführung, da § 90 Abs. 1 Nr. 3 BetrVG geplante KI-gestützte Arbeitsverfahren erfasst (GUIDE-004).

Datenschutz: in der Regel keine personenbezogenen Daten; enthalten Entwürfe reale Flüsse personenbezogener Daten, ist die oder der Datenschutzbeauftragte einzubinden, und mit jedem Cloud-Anbieter ist ein AVV zu schließen (GUIDE-005). Entwurfsdokumente sind vertraulich, daher muss die KI-Richtlinie festlegen, welches Werkzeug zugelassen ist (GUIDE-007).

KI-Kompetenz: Art. 4 der KI-Verordnung (AI Act) verlangt, dass Arbeitgeber die KI-Kompetenz der Beschäftigten fördern; halten Sie einen kurzen Workshop dazu, KI-erzeugte Bedrohungen kritisch zu prüfen (GUIDE-006). Führen Sie einen Pilot an einem neuen Entwurf mit einem erfahrenen Sicherheitsprüfer durch. Typische Sorge: „Die KI erzeugt nur Rauschen oder ersetzt Sicherheitsfachleute.“ Begegnen Sie ihr, indem Sie akzeptierte und abgelehnte Bedrohungen messen und klarstellen, dass Fachleute Risikobewertungen freigeben und die KI nie eine Bedrohung schließt (GUIDE-009).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko. Ein Assistent zur Entwurfsprüfung ist keine Nutzung nach Anhang III; KI-Kompetenz (Art. 4) gilt. Modelliert er ein KI-System, kann das Ergebnis die Pflichten zu Risikomanagement (Art. 9) und Cybersicherheit (Art. 15) eines Hochrisiko-Systems unterstützen, das Werkzeug selbst bleibt aber minimal.
• DSGVO: Entwürfe enthalten selten personenbezogene Daten, aber Wikis und User Stories können Namen und Kundendaten enthalten; minimieren und schwärzen Sie vor dem Senden an externe APIs. Beschreiben Modelle Datenflüsse personenbezogener Daten, kann die LINDDUN-Ausgabe in die DSFA (Art. 35 DSGVO) einfließen.
• CRA und NIS2: Das Bedrohungsmodell belegt keine Compliance; Hersteller bleiben für Risikobewertung, Dokumentation und Konformität verantwortlich. Bewahren Sie von Menschen freigegebene Fassungen als technische Dokumentation auf.
• Vertraulichkeit: Architekturdokumente und Schwachstellen sind besonders schützenswerte Informationen; nutzen Sie einen AVV, kein Training mit den Eingaben, EU-Region oder Selbstbetrieb und beschränken Sie den Zugriff auf die Ergebnisse.
• Prompt-Injection: Aus Wikis eingelesene Dokumente können Anweisungen enthalten; behandeln Sie Eingaben als nicht vertrauenswürdig, geben Sie der Pipeline nur Lesezugriff und lassen Sie Tickets nie autonom schließen.
• Übermäßiges Vertrauen: Automatisierungsbias; verlangen Sie namentlich benannte Prüfer bei Hochrisiko-Systemen.

Erste Schritte

1. Wählen Sie einen anstehenden Systementwurf und schreiben Sie seine Architektur als Diagramm-als-Code oder strukturierten Text.
2. Führen Sie STRIDE GPT oder einen einfachen Prompt mit Ihrem eigenen Schema aus; vergleichen Sie das Ergebnis mit einem manuellen Workshop.
3. Messen Sie erfundene und übersehene Bedrohungen; passen Sie Prompts an, ergänzen Sie RAG über Kataloge und bestehen Sie auf Nennung der Komponenten.
4. Fügen Sie einen CI-Auslöser für Architekturdateien hinzu und übernehmen Sie akzeptierte Maßnahmen ins Backlog.
5. Erweitern Sie auf LLM-/Agentenanwendungen mit agentenspezifischen Kategorien und verknüpfen Sie mit den Tests aus SEC-014.

Quellen

1. Regulation (EU) 2024/2847 (Cyber Resilience Act) - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Directive (EU) 2022/2555 (NIS2) - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
3. STRIDE GPT (PyPI/GitHub, open source) - https://pypi.org/p/stride-gpt
4. ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications - https://arxiv.org/html/2512.04785v1
5. Cloud Security Alliance - Agentic AI Threat Modeling Framework: MAESTRO - https://cloudsecurityalliance.org/articles/agentic-ai-threat-modeling-framework-maestro
6. STRIDE-AI: A Threat Modeling Framework for Generative AI Security Assessment - https://arxiv.org/abs/2605.17163
7. Aalborg University thesis comparing IriusRisk, ThreatCanvas and STRIDE GPT - https://projekter.aau.dk/projekter/files/782834690/thesis_threats_and_ai.pdf
8. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. Apiiro — Introducing AI Threat Modeling (vendor blog) — https://apiiro.com/blog/introducing-ai-threat-modeling/