Threat Modeling

Threat Modeling im Überblick

Threat Modeling identifiziert systematisch, was schiefgehen kann – bevor es passiert.

STRIDE Framework:

Technisch betrachtet

Ablauf des Threat Modeling

1. Scope definieren
   └── Was modellieren wir?

2. Diagramm erstellen
   └── Datenflüsse, Trust Boundaries

3. Bedrohungen identifizieren
   └── STRIDE pro Komponente

4. Risiken bewerten
   └── Wahrscheinlichkeit × Impact

5. Mitigationen planen
   └── Gegenmaßnahmen definieren

Beispiel: ML-API

Bedrohungen für ML-Inference-API:

1. Spoofing: Gefälschte API-Keys
   → Mitigation: JWT mit kurzer Laufzeit

2. Tampering: Manipulierte Inputs
   → Mitigation: Input Validation

3. Info Disclosure: Model Extraction
   → Mitigation: Rate Limiting, Output-Rounding

4. DoS: Teure Inference-Requests
   → Mitigation: Request-Limits, Timeouts

Weitere Methoden neben STRIDE

STRIDE ist der bekannteste, aber nicht der einzige Ansatz:

Für den Einstieg reichen oft die vier Kernfragen des Threat-Modeling-Manifests: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? Haben wir gute Arbeit geleistet?

Threat Modeling für LLM-Anwendungen

KI-Systeme erweitern die klassische Angriffsfläche um eigene Bedrohungsklassen. Wer eine LLM-Anwendung modelliert, sollte mindestens diese Vektoren durchspielen:

• Prompt Injection: Manipulierte Eingaben oder Inhalte aus externen Quellen (Webseiten, Dokumente, E-Mails) überschreiben die Anweisungen des Systems – die wichtigste neue Trust Boundary verläuft zwischen vertrauenswürdigem System-Prompt und nicht vertrauenswürdigem Kontext.
• Datenabfluss über Ausgaben: Das Modell gibt vertrauliche Inhalte aus dem Kontext preis – etwa RAG-Dokumente, auf die der Nutzer keinen Zugriff haben dürfte.
• Exzessive Agenten-Rechte: Ein Agent mit Tool-Zugriff wird durch Injection zu unerwünschten Aktionen verleitet. Mitigation: Least Privilege, menschliche Freigabe für kritische Operationen, Sandboxing.
• Poisoning der Wissensbasis: Manipulierte Dokumente in RAG-Speichern oder Fine-Tuning-Daten verändern das Systemverhalten.
• Kosten-DoS: Absichtlich teure Anfragen (lange Kontexte, viele Aufrufe) treiben die Inferenzkosten – Rate Limiting und Budgets sind hier Sicherheitskontrollen.

Als Referenz für KI-spezifische Bedrohungen haben sich unter anderem die OWASP-Übersichten zu LLM-Risiken sowie MITRE ATLAS etabliert.

Typische Stolperfallen

Abgrenzung zu verwandten Begriffen

• Risk Assessment bewertet Risiken oft auf Organisationsebene – Threat Modeling arbeitet konkret am System- und Architekturdesign.
• Penetration Testing prüft ein fertiges System empirisch auf Schwachstellen; Threat Modeling findet Designfehler, bevor sie gebaut werden. Ideal ist die Kombination: Das Threat Model liefert Testhypothesen für den Pentest.
• Security Review ist meist eine punktuelle Prüfung von Code oder Konfiguration – Threat Modeling betrachtet das Gesamtsystem inklusive Datenflüssen und Vertrauensgrenzen.