KI Threat Modeling

Stellen Sie sich vor: Ihre Firma integriert einen KI-Assistenten um Kundenanfragen zu vereinfachen. Doch über Nacht wird eben dieser zum Werkzeug für Datendiebstahl. Eine einzige clever formulierte Anfrage genügt, und plötzlich exfiltriert ein Angreifer Kundendaten. In den Logs finden Sie folgenden Prompt der an Ihren KI-Assistenten gesendet wurde:

Sie sind Opfer eines Prompt Injection-Angriffs geworden. Als Resultat hat der Angreifer alle Ihre Kundendaten exfiltriert. Sie müssen jetzt diesen Sicherheitsvorfall analysieren, die Sicherheitslücke beheben und schließlich auch Ihre Kund*innen informieren. Ein langwieriger und kostspieliger Prozess. Das Schlimmste? Dieser Vorfall hätte vermieden werden können – lange bevor eine Zeile Code geschrieben wurde. 

Ein zentrales Prinzip in der sicheren Entwicklung von Software lautet: Je später ein Fehler entdeckt wird, desto teurer wird seine Behebung, insbesondere bei Sicherheitslücken. Ganze Klassen an Sicherheitslücken können vermieden werden, wenn die richtigen Entscheidungen in der Software-Architektur getroffen werden. Genau hier setzt Threat Modeling an: Entwicklungsteams identifizieren Risiken schon bevor eine Zeile Code geschrieben wird, indem sie die Systemarchitektur auf potenzielle Angriffsvektoren analysieren. 

KI wird immer häufiger in Anwendungen integriert, von persönlichen Assistenten bis hin zu komplexen industriellen Steuerungssystemen. Diese Integration bringt nicht nur innovative Möglichkeiten mit sich, sondern auch spezifische Sicherheitsrisiken, die über die traditionellen Bedrohungen hinausgehen. Selbst wenn Unternehmen bereits etablierte Threat Modeling-Prozesse nutzen, müssen sie sich der einzigartigen Herausforderungen bewusst sein, die KI mit sich bringt. KI-Systeme funktionieren anders als herkömmliche Software: Sie lernen und passen sich an. Das bedeutet, dass auch die Bedrohungen dynamischer und komplexer werden. Ein klassisches Threat Modeling reicht hier oft nicht aus. Es braucht spezifische Ansätze und Know-How, die die Besonderheiten von KI berücksichtigen, um die Sicherheit dieser Systeme zu gewährleisten.

Die gute Nachricht: Mit KI-spezifischem Threat Modeling lassen sich diese Bedrohungen systematisch und frühzeitig identifizieren, bevor sie zu Sicherheitsvorfällen werden. Doch wie funktioniert das? Und was unterscheidet es vom klassischen Ansatz?

Threat Modeling ist eine strukturierte Methode zur Identifizierung und Bewertung potenzieller Sicherheitsbedrohungen und Schwachstellen in einem System, einer Anwendung oder einem Prozess. Ein gutes Threat Model spart nicht nur Geld, sondern reduziert auch den Entwicklungsaufwand, indem es bereits auf der Architektur-Ebene mögliche Schwachstellen aufdeckt und vermeidet. Dadurch können Sicherheitsprobleme frühzeitig adressiert werden, bevor sie zu kostspieligen Fehlern oder Sicherheitslücken führen. In vielen Entwicklungsteams hat sich Threat Modeling bereits als integraler Bestandteil des Software Development Life Cycle (SDLC) etabliert.

Das Threat Modeling orientiert sich an vier zentralen Fragen, die den Prozess leiten:

1. An was arbeiten wir? 

   Hier wird das zu entwickelnde System oder die Anwendung detailliert beschrieben. Es geht darum, ein klares Verständnis der Architektur, der Komponenten und der Datenflüsse zu erlangen, um potenzielle Angriffsvektoren zu identifizieren. Klassischerweise werden hier Architektur und Sequenzdiagramme analysiert und Datenflussdiagramme erstellt.

2. Was kann schief gehen?

   In dieser Phase werden mögliche Bedrohungen und Schwachstellen identifiziert. Dabei werden verschiedene Angriffszenarien betrachtet, um zu verstehen, wo und wie das System angegriffen oder kompromittiert werden könnte. Hier gibt es unterschiedliche Ansätze und Methoden, um systematisch die Bedrohungen zu identifizieren. Beliebt ist die STRIDE Methode die für alle Elemente in einem Datenflussdiagramm Bedrohungen in den Kategorien Spoofing, Tampering, Repudiaton, Denial of Service und Elevation of Privilege identifiziert.

3. Was können wir dagegen tun? 

   Hier werden Maßnahmen und Strategien entwickelt, um die identifizierten Bedrohungen zu entschärfen oder zu eliminieren. Dies kann technische Lösungen, Sicherheitsprotokolle oder auch Änderungen an der Architektur umfassen.

4. War die Analyse gut genug?

   Abschließend wird bewertet, ob die durchgeführte Bedrohungsanalyse umfassend und effektiv war. Es wird überprüft, ob alle relevanten Bedrohungen berücksichtigt und angemessene Gegenmaßnahmen ergriffen wurden, um die Sicherheit des Systems zu gewährleisten.

Durch diese systematische Herangehensweise hilft Threat Modeling dabei, sicherere Software zu entwickeln und das Risiko von Sicherheitsvorfällen zu minimieren.

Künstliche Intelligenz verändert nicht nur die Möglichkeiten von Software, sondern auch die Art und Weise, wie wir über Sicherheit nachdenken müssen. Während klassisches Threat Modeling sich auf statischen Code, klare Infrastrukturgrenzen und vordefinierte Anwendungslogik konzentriert, bringt KI eine neue Dimension von Risiken mit sich. Diese Risiken entstehen nicht nur durch das, was wir der KI geben, sondern auch durch das, was sie daraus lernt – und wie sie es anwendet.

• Daten: KI lernt aus Daten und damit werden diese Daten nun zum Angriffsvektor. Im Gegensatz zu traditioneller Software, in der Daten lediglich Input für vordefinierte Prozesse sind, bestimmen sie bei KI maßgeblich das Verhalten des Systems. Selbst scheinbar harmlose Daten können, wenn sie gezielt platziert werden, das Modell in die Irre führen – mit potenziell schwerwiegenden Folgen für die Integrität und Zuverlässigkeit der KI.
• Modell: Ein weiteres zentrales Risiko liegt im Modell selbst. KI-Systeme interpretieren Eingaben und reagieren darauf – und genau das macht sie anfällig für Angriffe wie Prompt Injection oder Adversarial Attacks. Während klassische Software auf klare Befehle und vordefinierte Abläufe reagiert, kann eine KI durch scheinbar harmlose, aber gezielt formulierte Eingaben dazu gebracht werden, unerwünschte oder sogar schädliche Aktionen auszuführen. Diese Dynamik erfordert neue Ansätze, um die Robustheit und Sicherheit der Modelle zu gewährleisten.
• Integration: Schließlich verändert KI auch die Art und Weise, wie Nutzer*innen mit Systemen interagieren. Statt über klar definierte Schnittstellen kommunizieren sie oft in natürlicher Sprache – was neue Angriffsvektoren eröffnet. KI-Assistenten, die als Agents oder Plugins mit anderen Systemen interagieren, können unbeabsichtigt schädliche Aktionen ausführen, wenn ihre Eingaben oder Ausgaben nicht ausreichend kontrolliert werden. Hier gilt es vor allem die Schnittstellen und Interaktionen der eingesetzten KI abzusichern.
• Supply-Chain: Wie bei der Software-Supply-Chain gilt: Wir müssen unsere Abhängigkeiten prüfen. Wer kontrolliert die Trainingsdaten? Wer hat Zugriff auf die gespeicherten Modelle? Auch wenn die meisten Unternehmen GenAI-Dienste externer Anbieter nutzen: Auch hier gelten Sicherheitsprinzipien. Es müssen Datenflüsse, API-Zugriffe und Integrationen abgesichert werden.

Diese Herausforderungen zeigen: Threat Modeling von KI-Anwendungen erfordert ein tiefes Verständnis der spezifischen Risiken, die mit Daten, Infrastruktur, Modellen und Anwendungen verbunden sind – und wie diese sich von klassischen Sicherheitsbedrohungen unterscheiden. Klassische Threat Modeling Ansätze wie z. B. STRIDE bieten eine gute Basis, müssen jedoch um KI-spezifische Bedrohungen erweitert werden. Wer hier proaktiv handelt, kann nicht nur Sicherheitslücken schließen, sondern auch das Vertrauen in KI-Systeme stärken und ihre langfristige Zuverlässigkeit sichern.

Zurück zu unserem fiktiven Beispiel am Anfang dieses Beitrags: Wir haben ein Webportal für unsere Kund*innen, welches es erlaubt, mittels einer KI Bestellungen und dazugehörige Rechnungen zu durchsuchen, zusammenfassen zu lassen oder Daten zu extrahieren. Unsere Kund*innen nutzen dieses Feature gerne, um komplexe Anfragen in natürlicher Sprache zu verfassen. Wir sind jetzt also gerade dabei die erste Frage des Threat Modeling zu beantworten: "An was arbeiten wir?" Wir zeichnen hierzu die Architektur des neuen KI-Features in Form eines Datenflussdiagramms und analysieren diese.

Im Prompt wird dem KI-Assistenten also eine sicherheitskritische Anweisung gegeben. Allerdings ist das keine geeignete Gegenmaßnahme, da ja genau solche Anweisungen leicht durch Prompt Injection-Angriffe umgangen werden können. 

Als Teil des Threat Modeling wird das Risiko, das von Bedrohungen ausgeht, bewertet. Anhand dieser Risikobewertung können dann die Gegenmaßnahmen evaluiert werden. In diesem Fall müssen wir von einer kritischen Bedrohung ausgehen, da potenziell alle Kund*innen betroffen sind.

Doch was wäre nun eine geeignete Gegenmaßnahme, um sich gegen Prompt Injection zu schützen? Eine technische Gegenmaßnahme wäre es, sogenanntes Prompt Hardening einzuführen. Hier wird der Prompt so konzipiert, dass ein Angreifer schwieriger Instruktionen einschleusen kann. In folgendem Beispiel verwenden wir Tags, um Instruktionen von Daten zu trennen. Zusätzlich verwenden wir zufällig generierte Tags bei jeder Anfrage an die KI, damit ein Angreifer die Tags nicht selbst schließen bzw. öffnen kann, da er dazu erst die zufälligen Tags erraten müsste.

Prompt Hardening schützt gegen einfache Prompt Injection-Angriffe. Da die stochastischen Prozesse generativer KI aber schwer einsehbar sind, können wir selbst mit Prompt Hardening Prompt Injection-Angriffe nicht sicher ausschließen. Zum Beispiel sind LLMs auch anfällig für das "Context Window Overflows". Bei diesem Angriff wird das limitierte "Gedächtnis" von LLMs folgendermaßen ausgenutzt: Eine zu lange Eingabe kann dazu führen, dass das LLM die sicherheitsrelevanten Anweisungen am Anfang einfach "vergisst" und dadurch erneut ein Prompt Injection-Angriff möglich wird. Wir könnten also weiter versuchen, alle möglichen Angriffe gegen das LLM durch weitere Gegenmaßnahmen zu verhindern. Das resultierende Katz-und-Maus-Spiel können wir jedoch vermeiden, indem wir uns zurück auf die Architekturebene begeben und uns überlegen, ob wir diesen Bedrohungen effektiv entgegenwirken können.

Das Beispiel des KI-Assistenten in dem Webportal zeigt eindrucksvoll, wie schnell gut gemeinte Innovationen zu Sicherheitsrisiken werden können. Hier hatten wir einen Prompt Injection-Angriff, der zu einem Datenleck führte. Die Behebung und Nachwirkungen eines solchen Angriffs sind aufwendig und kostspielig. Durch Threat Modeling und die daraus entstehenden Verbesserungen an der Architektur hätte der Angriff wirkungsvoll vermieden werden können. Insbesondere verdeutlicht unser Beispiel, dass Sicherheit nicht nachträglich durch technische Maßnahmen hinzugefügt werden kann. Natürlich ist es sinnvoll Prompt Hardening als Gegenmaßnahme einzuführen, allerdings ist dies keine vollwertige Gegenmaßnahme. Nur durch die Absicherung der Architektur kann diese Schwachstelle geschlossen werden.

Threat Modeling ist also kein Luxus, sondern eine Notwendigkeit, besonders wenn es um KI-Systeme geht. Die sichere Integration von KI bringt einige spezifischen Herausforderungen mit sich die über die Prompt Injection in unserem Beispiel hinaus gehen. So muss in einem ausgiebigen Threat Model auch die Trainingsphase und das Deployment von KI Modellen analysiert werden. 

Letztlich zeigt unser Beispiel, dass KI nicht einfach nur ein neues Feature ist, sondern eine grundlegende Veränderung der Systemarchitektur erfordert. Wer Threat Modeling konsequent anwendet, kann nicht nur Sicherheitslücken vermeiden, sondern schafft auch vertrauenswürdige und robuste KI-Anwendungen. Sicherheit beginnt nicht nach der Entwicklung – sie beginnt mit dem ersten Entwurf.