Sichere KI-Systeme: So lassen sich Sprachmodelle vor Manipulation schützen

Russische Propaganda flutet ChatGPT 

Die Organisation Newsguard  warnt, dass KI-Anwendungen wie ChatGPT, Microsoft Copilot oder Google Gemini anfällig für Manipulationen seien. Konkret, so die Experten, sei das russische Netzwerk „Prawda“ (Wahrheit) dafür verantwortlich, dass rund ein Drittel der Antworten der populärsten Chat-Assistenten auf Fragen über Zusammenhänge, zu denen „Prawda“ Falschinformationen verbreitet, diese wiedergeben. Wie kann das sein? 

„Flood the zone with shit”, hat Steve Bannon, rechtsextremer Blogger und ehemaliger Berater von US-Präsident Donald Trump, einmal gesagt. Man müsse den Nachrichtenraum mit so viel Unsinn fluten, dass die Korrekturroutinen irgendwann versagen. So ähnlich funktioniert auch die Manipulation von Large Language Modellen wie ChatGPT. Laut Newsguard habe das Prawda-Netzwerk allein im Jahr 2024 3,6 Millionen Artikel online gestellt und somit allein durch die schiere Menge die LLMs mit Falschinformationen manipuliert. Ein LLM, das Webinhalte zusammenfasst, kann somit beeinflusst werden. Dieses Vorgehen der gezielten Manipulation wird als LLM Grooming oder Poisoning the Well bezeichnet. 

Es unterscheidet sich von den besser bekannten Data Poisoning Angriffen darin, dass nicht die Trainingsdaten des Modells, sondern externe Datenquellen eines bereits trainierten Modells manipuliert werden. Das demonstriert, dass LLMs mit Zugriff auf externe Daten gezielt und im großen Stil manipuliert werden können. Denn organischen Traffic generiere das „Prawda“-Netzwerk kaum. Vielmehr sei es darauf ausgelegt, KI-Anwendungen eine verzerrte Datenbasis bereitzustellen. Und das scheint zumindest momentan auch zu funktionieren, wie die Ergebnisse von Newsguard zeigen. 

Prompt-Injections: versteckte Anweisungen 

Doch nicht nur mit Falschinformationen werden LLMs manipuliert. Ein weiteres Risiko, das von LLMs mit Zugriff auf externe Datenquellen ausgeht, sind sogenannte indirekte Prompt-Injections. Durch versteckte Anweisungen auf einer Website, in einer E-Mail oder in einer anderen Quelle können LLMs dazu gebracht werden, unerwünschte Aktionen auszuführen und den Instruktionen eines Angreifers zu folgen. Das „Prawda“-Netzwerk demonstriert bereits, dass mit LLM Grooming  ein hoher Durchdringungsgrad beim Verbreiten von Fehlinformationen erreicht werden kann. Die Folgen eines ähnlichen Vorgehens zur Platzierung und Verbreitung von indirekten Prompt-Injections wären schwerwiegend. Denn hiermit lassen sich auch explizite Anweisungen an das System übertragen. 

Um solche Angriffe zu verhindern oder zumindest die Folgen zu minimieren, reichen klassische IT-Sicherheitsmechanismen allein nicht aus. Deshalb werden bei Materna KI-spezifische Schutzmaßnahmen in den gesamten Entwicklungszyklus integriert – von der Architektur über Tests bis hin zur kontinuierlichen Überwachung. Einige Einblicke gibt dieser Artikel. 

Wie funktionieren indirekte Prompt-Injections? 

LLMs sind keine isolierten Systeme – sie interagieren mit APIs, Datenbanken und oft auch externen Inhalten. Genau hier setzen indirekte Prompt-Injections an: Angreifer platzieren manipulierte Anweisungen in Webseiten, Dokumenten, Requests oder API-Antworten, die vom LLM verarbeitet werden. Da KI-Modelle keine Unterscheidung zwischen vertrauenswürdigen und nicht vertrauenswürdigen Quellen vornehmen können, können diese nicht von legitimen Nutzereingaben unterschieden werden. Es kommt so zu unerwartetem oder sogar schädlichem Verhalten. Um das zu verhindern, setzen wir bei Materna von der Konzeption bis hin zur Implementierung und dem Betrieb einer Software eine Vielzahl an Schutzmechanismen ein.  

Schutzmaßnahmen auf Architekturebene 

Sicherheit beginnt bereits in der Planung einer Software. Hier wenden wir bewährte Praktiken und Standards an. Diese sind meistens nicht speziell auf KI-Anwendungen zugeschnitten, können in aller Regel aber ohne weiteres auch darauf angewendet werden. Das NIST Cybersecurity Framework (NIST CSF) zum Beispiel umfasst das Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen des Betriebs bei Cybersecurity-Vorfällen. Auch die ISO/IEC Standards wie 27002 – Controls & Best Practices, 27005 – Information Security Risk Management, 27034 – Application Security u. v. m. bieten hier eine solide Grundlage. Dabei findet in allen Entwicklungsstadien eine ganzheitliche Betrachtung des Systems statt. 

Zum Beispiel wird schon vor der eigentlichen Programmierung der Software ein Threat Modeling durchgeführt. Dabei werden alle Komponenten und Datenströme des Systems erfasst und analysiert, um schon früh herauszufinden, wo nachgebessert werden muss. Das klingt aufwendig, aber dadurch, dass man frühzeitig die richtigen Weichen stellt, spart man sich auf lange Sicht viel Arbeit. 

Einige wichtige Prinzipien, die schon auf Architekturebene in der Entwicklung von LLM-basierten Systemen Beachtung finden, sind: 

• Least Privilege: Das LLM sollte nur notwendige Datenquellen nutzen und keine unnötigen Systemzugriffe haben.
• Input Validation: Externe Inhalte müssen vor der Weitergabe an das Modell gefiltert und analysiert werden.
• Überwachung und Logging: Verdächtige Interaktionen und ungewöhnliche Modellantworten sollten kontinuierlich z. B. mit einem Intrusion Detection and Prevention System (IDPS) überwacht werden.
• Defense-in-Depth: Eine mehrstufige Sicherheitsstrategie, die verschiedene Schutzmaßnahmen kombiniert, ist, wie auch bei nicht KI basierten Softwarekomponenten, unerlässlich. Dazu zählt zum Beispiel auch die Segmentierung von Netzwerken. 

Durch eine sichere Architektur lässt sich das Risiko, das von indirekten Prompt-Injections ausgeht, erheblich reduzieren. Eine gut durchdachte Strategie hilft außerdem dabei, resilient und souverän bei Vorfällen zu reagieren und das Schadenausmaß zu begrenzen. Was sonst zu einem Komplettausfall des Betriebs führen könnte, wird dann z. B. auf einen Teilbereich begrenzt. 

Solche Maßnahmen sind unerlässlich, doch auch das Softwareprodukt selbst benötigt einige Sicherheitsmechanismen, um einen sicheren Betrieb zu gewährleisten. 

Statische und dynamische Codeanalysen 

Codeanalysen helfen, Schwachstellen frühzeitig, schon in frühen Entwicklungsstadien eines Softwareprojekts, zu identifizieren – etwa unsichere Konfigurationen oder zu weit gefasste System-Prompts. Da viele Angriffe aber erst in der Interaktion mit dem Modell auftreten, ist es wichtig, LLM-spezifische Abwehrstrategien zu implementieren. 

Wirkungsvolle Schutzstrategien gegen indirekte Prompt-Injections 

Einige Maßnahmen, die speziell darauf ausgerichtet sind, das System vor indirekten Prompt-Injections zu schützen, sind: 

1. Ad-hoc-Selbstprüfung der Eingaben durch das Modell selbst
 

• Das LLM kann durch einen modifizierte System-Prompt dazu gebracht werden, Eingaben zu analysieren und verdächtige Muster zu erkennen, bevor sie verarbeitet werden.
• Diese Methode ist schnell einsetzbar, aber verursacht vergleichsweise hohe Kosten.
• Außerdem kommt das eingesetzte LLM weiterhin direkt mit Eingaben aus nicht vertrauenswürdigen Quellen in Kontakt und kann so kompromittiert werden. Das Risiko, dass diese Maßnahme umgangen werden kann, ist relativ hoch. 

2. Spezialisiertes Modell als Input Scanner

• Ein separates, speziell trainiertes Modell, z. B. LLM-Guard (MIT-Lizenz), überprüft Eingaben auf potenzielle Prompt- Injections, bevor sie das Hauptmodell erreichen. Diese Modelle sind oft deutlich effektiver in der Erkennung als die allgemeinen Modelle.
• Dadurch kommt das eigentliche LLM gar nicht erst mit Angriffsversuchen in Kontakt.
• Diese Methode ist schnell einsetzbar und erzeugt dadurch, dass das spezialisierte Modell lokal ausgeführt werden kann, nur sehr geringe Kosten. Auch eine Kombination mehrerer Scanner kann von Vorteil sein.

3. Dual-LLM Design-Pattern: Trennung von Anweisungen und Daten

• Das Dual-LLM Pattern ist ein Software-Entwurfsmuster, bei dem, ähnlich wie bei SQL-Prepared-Statements, Instruktionen von Eingabedaten getrennt werden.
• Ein erstes Modell strukturiert die Anfrage und extrahiert relevante Parameter, während ein zweites Modell die eigentliche Aufgabe ausführt – ohne direkten Kontakt zur ursprünglichen Eingabe oder zum ersten Modell. Auch hier kommt das Modell nicht mit Angriffsversuchen in Kontakt.
• Dies macht es Angreifern deutlich schwerer, schädliche Befehle einzuschleusen, erhöht allerdings den Entwicklungsaufwand merkbar, da diese Strategie für jeden Anwendungsfall angepasst werden muss und es noch keine leicht einsetzbaren Frameworks hierfür gibt. 

Eine Überprüfung der Eingaben in das System mit diesen Methoden verringert signifikant das Risiko von indirekten Prompt-Injections, da sie in den meisten Fällen erkannt und verhindert werden können. 

KI-Sicherheit ist ein kontinuierlicher Prozess 

Für Unternehmen und Behörden, die mittels KI Ressourcen sparen und Vorgänge effizienter gestalten wollen, ist eine sichere KI essenziell. Ohne geeignete Sicherheitsmaßnahmen kann die Integration großer Sprachmodelle in bestehende IT-Systeme ein erhebliches Risiko darstellen. Durch eine Kombination aus bewährten Sicherheitsprinzipien und gezielten KI-spezifischen Schutzmaßnahmen lassen sich jedoch sowohl die Wahrscheinlichkeit als auch das potenzielle Schadensausmaß erheblich reduzieren. 

Im Betrieb wird aber schnell klar, dass sich Bedrohungsszenarien kontinuierlich verändern. Dementsprechend ist es wichtig, auch bereits bestehende Systeme oder solche, die kurz vor der Inbetriebnahme stehen, stetig zu überprüfen. Dazu führen wir unterem anderem Penetrationstests aus. Dabei werden die Systeme gezielt echten Angriffsszenarien ausgesetzt. Hier setzen wir zum Beispiel auf LLMs spezialisierte Tools ein wie NVIDIA garak, einen LLM Vulnerability Scanner. Das heißt, es wird eingesetzt, um Schwachstellen in LLM-integrierten Systemen zu finden. garak erlaubt es, in kurzer Zeit eine Vielzahl von Angriffsszenarien zu simulieren. So lassen sich LLM-basierte Systeme auf Herz und Nieren prüfen, bestenfalls sowohl vor als auch nach der Inbetriebnahme; von einfachen Jailbreaks und Proben über ethisches Verhalten des Modells bis zu komplex codierten indirekten Prompt-Injections. Wenn dabei erkannt wird, dass das System angreifbar ist, müssen die Entwickler:innen nachbessern. Zum Beispiel dadurch, dass sie eine der oben genannten Maßnahmen einbauen. 

Insgesamt lässt sich festhalten: Nur ein ganzheitlicher Ansatz ermöglicht die sichere Integration von LLMs in bestehende Systeme und Prozesse, ohne dabei unnötige Risiken einzugehen.