Kapitel 2 — Bedrohungsmodellierung für LLM-Systeme

Zweiter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel nimmt Shostacks vier Fragen, STRIDE, PASTA und MITRE ATLAS und wendet sie auf ein System an, dessen mächtigste Komponente jede Eingabe als potenziell instruktiv liest.

Warum es dieses Kapitel gibt

Kapitel 1 hat argumentiert, dass KI-Sicherheit strukturell anders ist. Kapitel 2 gibt diesem Unterschied operative Form. Adam Shostacks vier Fragen — woran arbeiten wir, was kann schiefgehen, was tun wir dagegen, haben wir gute Arbeit geleistet — sind für jedes System dieselben, aber die Diagramme, Asset-Inventare und Angreiferkataloge, die sie beantworten, sehen anders aus, wenn das fragliche System eine Prompt-Konstruktions-Logik, eine Retrieval-Pipeline, ein Werkzeug-Register und eine probabilistische Funktion enthält, die abgerufene Inhalte auf Augenhöhe mit den Anweisungen der Entwicklerin behandelt. Das Kapitel walkt die Frameworks — STRIDE, PASTA, MITRE ATLAS, NIST AI 100-2 — und produziert die Arbeitsvorlage eines LLM-Bedrohungsmodells, auf die spätere Kapitel immer wieder zurückverweisen.

In einem Satz: Das Bedrohungsmodell für ein LLM-System ist dieselbe Disziplin wie für jedes andere System, aber es muss mit einem Diagramm beginnen, das Prompt-Konstruktion, Retrieval, Werkzeuge und Output-Behandlung als getrennte Komponenten sichtbar macht — denn „eine Box mit der Aufschrift LLM" verbirgt den größten Teil der sicherheitsrelevanten Struktur.

2.1 Frameworks passen sich an, Diagramme dürfen nicht faul bleiben

STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — bildet sich überraschend gut auf LLM-Systeme ab. Spoofing wird zu Identitätsangriffen auf die API oder Nutzer-Impersonation. Tampering wird zu Prompt-Injection, Trainingsdaten-Vergiftung und Retrieval-Index-Manipulation. Repudiation wird zum Streit darüber, wer welchen Prompt geschickt und wer welche Ausgabe erzeugt hat. Information Disclosure wird zu Trainingsdaten-Extraktion, System-Prompt-Leck und mandantenübergreifender Preisgabe. Denial of Service wird zu OWASPs LLM10 — unbegrenzter Konsum durch teure Prompts und Token-Fluten. Elevation of Privilege wird zur Werkzeug-Grenze: ein Nutzer, der das Modell dazu bringt, ein privilegiertes Werkzeug zu rufen, erbt dessen Privilegien. PASTA legt Geschäftskontext und Angreifer-Simulation darüber, für Teams, die bereits Red-Team-Arbeit leisten. Beide Frameworks setzen ein Datenfluss-Diagramm voraus, das die Komponenten trennt, an denen die Überwachungsfrage hängt. Für LLM-Systeme sollte das Diagramm immer die Prompt-Konstruktionslogik, die Retrieval-Pipeline, das Werkzeugregister, den Modellaufruf, den Output-Behandlungspfad und den Logging-Pfad voneinander trennen.

2.2 Assets, die in konventionellen Inventaren nicht vorkommen

Ein Bedrohungsmodell ist nur so gut wie sein Asset-Inventar. LLM-Systeme führen Kategorien ein, die Teams unbekannt sind, deren bisherige Arbeit auf konventionellen Anwendungen lag. Das Modell selbst hat mehrere Teil-Assets — die Gewichte (eine mehrere Gigabyte große Binärdatei, die erhebliche Trainingsinvestitionen repräsentiert), das dokumentierte Verhalten (System-Prompt, Sicherheitspolitik, Alignment-Training) und die Reputation (ein öffentliches Versagen schädigt das Produkt unabhängig von jeder technischen Kompromittierung). Die Datenkategorie umfasst Trainingsdaten, Fine-Tuning-Daten, Retrieval-Korpora, Nutzereingaben und Ausgaben; jede hat eigene Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit. Der Prompt selbst ist nun ein Asset — das geistige Eigentum vieler Produkte lebt in einem System-Prompt, der über Monate verfeinert wurde, und OWASPs 2025er-Liste nennt System-Prompt-Leaks explizit als LLM07. Infrastruktur umfasst den Inferenz-Stack, den Vector Store, die Werkzeugschnittstellen und die Credentials, die alles zusammenbinden. Logs sind ein Asset, weil sie der forensische Beleg sind, und Assets zweiter Ordnung — Modellreputation, regulatorischer Stand, Kundenvertrauen — hängen davon ab, dass die primären den Verkehrskontakt überleben.

2.3 Angreifer haben spezifische Anreize

Ein Bedrohungsmodell, das gleichmäßig gegen alles schützt, schützt gegen nichts. Das Angreiferinventar muss spezifisch sein. Neugierige Nutzer probieren das System aus, um zu sehen, was es tut — sie nutzen Techniken aus sozialen Medien, ihr Volumen ist hoch, ihr individueller Schaden je Vorfall gering, ihr kumulativer Effekt auf die wahrgenommene Sicherheit des Systems aber erheblich. Böswillige Nutzer beabsichtigen konkreten Schaden — Inhalte extrahieren, die das System verweigern sollte; Daten anderer Nutzer oder den System-Prompt stehlen; das System zur Dritten-Angriff nutzen, über verfasste Phishing-Nachrichten oder generierte Malware. Wettbewerber extrahieren das Modell (Kapitel 8) oder den System-Prompt, um eigene Entwicklungskosten zu senken. Insider operieren von innerhalb der Vertrauensgrenze. Nationalstaatliche Akteure kombinieren Modellangriffe mit dem breiteren Handwerkszeug, und ihre Ziele sind meist Organisationen, nicht das Modell direkt. Automatisierte Agenten — selbst LLMs, teils von anderen Angreifern gesteuert — sind die neueste Kategorie und die, mit der sich Kapitel 17 befasst. Jede Angreiferkategorie hat andere Fähigkeiten, andere Anreize und andere Erkennungsprofile, und die Mitigationen, die die Kosten gegen die eine erhöhen, wirken möglicherweise nicht gegen die andere.

Wert, das festzuhalten: Bei API-basierten LLM-Deployments liegen große Teile dessen, was das Sicherheitsteam „Anwendungslogik" nennt — das Verhalten des Modells — jenseits einer vertraglichen Grenze, die das Team nicht inspizieren kann. Das Bedrohungsmodell muss diese Asymmetrie anerkennen, statt so zu tun, als wäre das Modell nur eine weitere Komponente.

Was Kapitel 2 vorbereitet

Die hier entwickelte Vorlage — einseitige Systembeschreibung, Datenflussdiagramm mit Vertrauensgrenzen, Asset-Inventar, Angreiferkatalog, Bedrohungsaufzählung nach STRIDE, Mitigations-Mapping, Restrisiko-Register — ist der Rahmen, den der Rest des Buches ausfüllt. Kapitel 3 erweitert die Asset-Kategorie „Daten" um ihre volle Struktur — Trainingsdatenrisiken, Memorisation und Extraktion, Handhabung sensibler Eingaben, Verschlüsselung und Aufbewahrung. Kapitel 4 nimmt Prompt-Injection auf, die STRIDEs Tampering-Kategorie bereits als dominante Bedrohung gegen die Prompt-Konstruktions-Komponente benannt hat. Die Kapitel 5 und 6 entwickeln die Mitigationen für Prompt-Injection auf den Input-, Output- und RAG-Schichten. Spätere Kapitel greifen dieselbe Vorlage wieder auf — Kapitel 11 für Observability, Kapitel 12 für Identität —, aber das hier eingeführte Asset-Inventar und der Angreiferkatalog sind das, was jene Kapitel erweitern.

Als Nächstes — Kapitel 3: Datensicherheit und Datenschutz. Trainingsdatenrisiken, Memorisation und Extraktion, die Samsung- und Garante-Vorfälle sowie die Verschlüsselungs-, Isolations- und Aufbewahrungsdisziplin, die Datensicherheit in LLM-Systemen verlangt.

Möchtest du das ganze Bild? Das Buchkapitel enthält die lauffähigen Beispiele für Datenflussdiagramme, das Schritt-für-Schritt-Bedrohungsregister für einen RAG-gestützten Support-Assistenten, die vollständigen STRIDE- und PASTA-Mapping-Tabellen und die „In Plain English"-Sidebars, die dieser Artikel nur zusammenfasst. LLM Primer VII auf Amazon →