Mit der großen öffentlichen Aufmerksamkeit, welche Künstliche Intelligenz in Form von LLMs (Large Language Models) seit Ende 2022 erhalten hat, stellt sich naturgemäß auch die Frage nach der IT-Sicherheit. Die OWASP (Open Worldwide Application Security Project) veröffentlich eine Übersicht über die 10 größten Sicherheitsrisiken in Bezug auf LLMs, mit welchen sich dieser Beitrag beschäftigt. Zum Zeitpunkt dieses Beitrags liegt die Liste in ihrer Version 1.0.1 vor.
Übersicht über die Risiken
Die Liste, welche von 125 IT-Sicherheitsexperten weltweit zusammengestellt wurde, enthält die folgenden 10 größten Risiken:
- Prompt Injection (LLM01)
- Insecure Output Handling (LLM02)
- Training Data Poisoning (LLM03)
- Model Denial of Service (LLM04)
- Supply Chain Vulnerabilities (LLM05)
- Sensitive Information Disclosure (LLM06)
- Insecure Plugin Design (LLM07)
- Excessive Agency (LLM08)
- Overreliance (LLM09)
- Model Theft (LLM10)
Einleitung
Schon beim Überblick fällt die große Bandbreite der Risiken auf. Anders als beispielsweise bei den OWASP Top 10 Web Application Security Risks sind die Auswirkungen nicht auf den technischen Bereich beschränkt.
So resultiert das Risiko Overreliance zum Beispiel in einer Fehlvorstellung beim Nutzer der Anwendung aufgrund der Nichtberücksichtigung der Grenzen von LLMs. Mit Training Data Poising finden auch die Gefahren, die sich aus in den Trainingsdaten verkörperten (menschlichen) Vorurteilen und Fehlinformationen ergeben, Berücksichtigung. Die Bandbreite von Risiken und Auswirkungen ist größer als in anderen Bereichen, was insbesondere damit zu tun hat, dass LLMs ein breiteres Einsatzgebiet haben und beispielsweise auch von technischen Laien ohne Probleme in ihrer Basisfunktion eingesetzt werden können.
Der vorliegende Beitrag gibt einen kurzen Überblick über die 10 größten Sicherheitsrisiken in Bezug auf LLMs der OWASP. Bei weiterem Interesse sollte das oben verlinkte Paper einschließlich der dort einbezogenen Quellen herangezogen werden.
Einzelne Risiken
Die OWASP gibt die folgenden größten Risiken an:
Prompt Injection
Bei der Prompt Injection wird durch eine bewusst gestaltete Eingabe das LLM manipuliert. Ziel ist es, das LLM dazu zu bringen, die Intention des Angreifers auszuführen. Diese Eingaben können sowohl direkt erfolgen als auch in Dateien, welche in das LLM geladen werden, eingebettet sein.
Der Angriff wird umso gefährlicher, je größer die Berechtigung des LLM sind und je selbständiger das LLM agieren darf. Deshalb setzt beispielsweise Open AI für seine Plugins voraus, dass eine Bestätigung durch den User abgefragt wird, bevor eine Aktion ausgeführt wird.
Insecure Input Handling
Beim Insecure Input Handling wird der Output des LLM direkt an nachgelagerte Komponenten, etwa das Backend, weitergegeben. Dass dies zu erheblichen Sicherheitsrisiken führt, erschließt sich ohne Weiteres.
Gegenmaßnahme ist die Validierung des Outputs des LLM, bevor das Ergebnis weiter verarbeitet wird. Andernfalls kann ein Angreifer etwa versuchen, Befehle über das LLM direkt auf dem Zielsystem auszuführen.
Training Data Poisoning
Bei Training Data Poisoning handelt es sich, wie der Name schon sagt, um eine Manipulation oder „Vergiftung“ der Trainingsdaten. LLMs sind gem. ihrer Funktionsweise auf Trainingsdaten angewiesen, um zu lernen, wie Wörter und Ausdrücke in unterschiedlichen Zusammenhängen verwendet werden. Werden diese Trainingsdaten manipuliert, lernt das LLM unzutreffende Zusammenhänge. Dies führt dazu, dass das LLMs die falschen Zusammenhänge in ihrem Output verwenden. Durch bewusste Manipulation der Trainingsdaten kann so etwa auf die Meinungsbildung eingewirkt werden.
Gegen dieses Risiko hilft eine sorgfältige Auswahl der Trainingsdaten. Auch der Einsatz von Sandboxing-Techniken kann verhindern, dass LLMs auf unerwünschte Trainingsdaten zugreift.
Model Denial of Service
Bei Model Denial of Service-Angriff werden die Ressourcen der LLM in einer Weise beansprucht, die die Qualität des Services (z.B. durch fehlende Erreichbarkeit) negativ beeinflusst und die Ressourcenkosten in die Höhe treibt. Eine Form des Angriffs ist es, das Kontextfenster, also die maximale Anzahl von Token für Eingabe und Output, durch Manipulation zu überschreiten.
Zur Abwehr muss sichergestellt werden, dass Nutzereingaben validiert und bereinigt werden. Insbesondere muss die Einhaltung des Kontextfensters sichergestellt werden. Auch eine Begrenzung des Ressourcenverbrauchs pro Anfrage ist eine naheliegende Sicherheitsmaßnahme.
Supply Chain Vulnerabilities
Bei Angriffen über die Lieferkette handelt es sich um ein auch in der klassischen IT-Sicherheit als hoch eingestuftes Risiko. Während sich das Risiko in anderen Bereichen vor allem auf der Softwareebene abspielt, entstehen die Risiken bei den LLMs durch bereits trainierte Modelle von Drittanbietern, durch Trainingsdaten Dritter sowie durch Plugins Dritter.
Wie in der klassischen IT-Sicherheit können die Risiken durch sorgfältige Auswahl und laufende Kontrolle der Lieferkette reduziert werden.
Sensitive Information Disclosure
Das Risiko, dass sensible Daten durch die LLM offenbart werden, trifft vor allem die Nutzer der LLM. Zusätzlich sind aber , aufgrund von Strafen und negativer Publicity, indirekt auch die Anbieter betroffen. Aufgrund des zu einem Teil nicht vorhersagbaren Verhaltens der LLMs kann nicht ausgeschlossen werden, dass sensible Daten, die in die Trainingsdaten eingeflossen sind, später anderen Nutzern offenbart werden.
Die wirkungsvollste Maßnahme ist es, sensible Daten gar nicht erst in das LLM gelangen zu lassen. Entweder verzichtet der Nutzer auf eine Eingabe solcher Daten oder der Anbieter stellt sicher, dass die Eingaben nicht zum Training des LLM verwendet werden. Weiterhin können auch die Eingaben der Nutzer automatisiert auf sensible Daten geprüft und ausgefiltert werden. Zudem können Nutzer durch Filter bei den Prompts daran gehindert werden, auf sensible Daten zuzugreifen. Aufgrund der Unberechenbarkeit der LLMs erscheinen die beiden zuletzt genannten Maßnahmen jedoch weniger wirkungsvoll.
Insecure Plugin Design
Plugins werden als Erweiterungen automatisch durch das LLM aufgerufen, wenn sie aktiviert sind. Risiken ergeben sich, wenn ein Plugin Textfelder, Konfigurationstexte oder sogar SQL- bzw. Programmierbefehle anstelle eindeutiger Parameter akzeptiert. Hierdurch kann ein Angreifer manipulierte Anfragen an das Plugin senden. Zudem gibt es oftmals unzureichende Zugriffskontrollen in der Form, dass Plugins anderen Plugins vertrauen und davon ausgehen, dass weitergereichte Eingaben vom Nutzer stammen.
Um dem Risiko zu begegnen, sollten Plugins möglichst parametrisierte Eingaben erzwingen. Sofern dies nicht möglich ist, sollte auf einer zweiten Ebene die Validierung und Bereinigung der Daten erfolgen.
Excessive Agency
Gefahren gehen auch von der Tatsache aus, dass LLM-basierten Systemen von ihren Entwicklern häufig ein gewisses Maß an Autonomie zugestanden wird. Die Systeme haben also die Möglichkeit, ohne weitere menschliche Kontrolle aufgrund der Eingabe des Nutzers zu handeln. Ursache dieser Risiken sind übermäßige Funktionen, übermäßige Rechte oder übermäßige Autonomie. Insbesondere im Zusammenhang mit dem Einsatz von Plugins drohen in diesem Bereich Gefahren.
Reduziert werden können diese Risiken, indem die Funktionen, Rechte sowie die Autonomie der Systeme auf das für die Erfüllung der Aufgabe notwendige Maß streng begrenzt werden.
Overreliance
Das Risiko der Overreliance verwirklicht sich, wenn sich Nutzer auf den Output des LLM verlassen, um Entscheidungen zu treffen oder Content zu generieren. Das Risiko hängt mit der Neigung von LLMs zum Halluzinieren zusammen. Dabei erzeugen die LLMs Output, welcher nicht mit den Fakten übereinstimmt. Aufgrund der hohen sprachlichen Qualität des Outputs kann dies durch den Nutzer nur schwer erkannt werden, ohne zusätzliche Informationsquellen heranzuziehen. Hintergrund des Halluzierens ist, dass LLMs letztlich nur die Wahrscheinlichkeit des nächsten Wortes im konkreten Kontextes berechnen, sich also an Sprache und nicht an Fakten ausrichten.
Neben einigen technischen Maßnahmen können insbesondere Nutzer das Risiko reduzieren, indem sie den Output der LLM durch externe Quellen prüfen, sofern sie nicht aus eigener Expertise eine Prüfung vornehmen können. Das Fine-Tuning von LLMs, also das Training mit spezialisierten Daten zu bestimmten Themen, reduziert generell das Risiko des Halluzinierens.
Model Theft
Der Diebstahl des LLM stellt für den Inhaber des Geistigen Eigentums ein erhebliches Risiko dar. Als möglicher Weg kommt hierbei nicht nur der direkte Zugriff und das Kopieren in Betracht, sondern auch das Erstellen einer Schatten-LLM mithilfe von durch sorgfältig erstellte Eingaben und Prompt Injections erzielte Informationen. Gefährdet durch dieses Risiko sind naturgemäß Closed Source-Anbieter von LLMs, während das LLM bei Open Source-Modellen ohnehin der Öffentlichkeit zur Verfügung stellt.
Klassische Maßnahmen gegen den Diebstahl von IP sind auch gegen dieses Risiko wirksam. Weiterhin sollte eine regelmäßige Kontrolle von User-Prompts erfolgen und Filter eingesetzt werden, um einer Datenexfiltration vorzubeugen.
Fazit
Auch wenn es sich bei LLM zumindest für die breite Öffentlichkeit um eine neue Entwicklung handelt, nimmt die Diskussion zur IT-Sicherheit von LLMs an Fahrt auf. Dies ist auch zwingend notwendig, da sich wahrscheinlich kein Wissensgebiet in diesem Bereich bisher so schnell entwickelt hat. Da bisher kein Ende dieser Entwicklung abzusehen ist, bleibt abzuwarten, ob die IT-Sicherheit in Zukunft überhaupt mit den Entwicklungen wird mithalten können. Spannend sind zudem die Möglichkeiten, LLMs auch im Interesse der IT-Sicherheit einzusetzen.
Foto von Arseny Togulev auf Unsplash