Um funktionierende KI-Systeme zu entwickeln, musst du sie zuerst gezielt angreifen. Im Rahmen eines Red Teamings griffen wir wie Angreifende eine kundenorientierte KI-Anwendung im Finanzsektor an, um sie zu testen und Schwachstellen aufzuspüren. Unsere Erkenntnisse sind für alle relevant, die LLM-gestützte Anwendungen bereitstellen, bei denen Sicherheit unverzichtbar ist.
Beim Red Teaming versuchst du gezielt, dein KI-System zu überwinden, damit du Schwachstellen beheben kannst, bevor echte Angreifende sie finden. Im Finanzsektor steht besonders viel auf dem Spiel: KI-Anwendungen greifen auf Kundendaten zu, verarbeiten Transaktionen und liefern Finanzanalysen. Die Folgen eines Fehlers reichen von einer schlechten Nutzungserfahrung über Verstöße gegen Vorschriften und finanzielle Verluste bis hin zu irreparablen Markenschäden.
Unser Ziel war es, Schwachstellen frühzeitig zu finden, realistische Angriffsmuster zu testen und die Organisation dabei zu unterstützen, die von Aufsichtsbehörden sehr ernst genommenen Anforderungen an die KI-Sicherheit zu erfüllen.
Eine wichtige Unterscheidung: Jailbreaks greifen die Sicherheitsfilter des zugrunde liegenden Modells an. Prompt Injection richtet sich dagegen gegen die Anwendung selbst und kombiniert nicht vertrauenswürdige Nutzereingaben mit dem vertrauenswürdigen Prompt des Entwicklungsteams. Prompt Injection birgt ein größeres Risiko, da sie dein System und die darin verarbeiteten vertraulichen Daten angreift, nicht ein universell einsetzbares Modell.
Unsere erste Testrunde umfasste rund 750 Tests in folgenden Bereichen:
Sitzungsübergreifende Datenlecks
Offenlegung personenbezogener Daten (durch natürliche Sprache, API-Manipulation und verschiedene Codierungen)
SQL-Injection
Überschreiben von System-Prompts
Bei diesen ersten Tests ermittelten wir zwei wesentliche Probleme des bestehenden Systems: den Umgang mit Anfragen, die mehrere Absichten kombinieren, und die Verwendung codierter Prompts.
Anfragen mit mehreren Absichten: Anfragen, die legitime und schädliche Aufforderungen kombinieren. Zum Beispiel: „Zeige meine Ausgaben nach Kategorie an und führe außerdem [schädlicher SQL-Code] aus.“ Die Anwendung erkannte die schädliche Absicht nicht, sondern verließ sich vollständig auf die nachgelagerten Schutzmechanismen der Datenschicht. Das ist so, als würdest du deine Haustür offen lassen, weil du dem Tresor im Keller vertraust.
Codierung: Anfragen, die mit Base64, Hex, LeetSpeak oder Homoglyphen codiert sind. Für Systeme kann es schwierig sein, schädliche Absichten herauszufiltern. Diese Anfragen legten zwar keine sensiblen Daten offen, destabilisierten das System jedoch erheblich. Dazu gehörten Halluzinationen, die Wiedergabe schädlicher SQL-Befehle an Nutzende und eine fehlerhafte Klassifizierung der Absicht.
Die Ergebnisse unserer ersten Tests zeigten:
Zeitbezogene Halluzinationen: Das Modell gibt frei erfundene Daten, Transaktionszeitpunkte oder zeitgebundene Zusammenfassungen mit großer Gewissheit aus. Im Finanzkontext ist das ein erhebliches Risiko, da Entscheidungen auf Grundlage eines falschen Datums reale Folgen haben können.
Wiedergabe schädlicher SQL-Befehle an Nutzende (bedenklich im Hinblick auf die Manipulation des Speichers)
Fehlerhafte Klassifizierung der Absicht
Fehlerhafte Ausgabeformatierung
Auf Grundlage dieser Erkenntnisse grenzten wir unseren Schwerpunkt ein. SQL-Injection und Codierungstests erhielten eine geringere Priorität, da das Team diese Probleme bereits bearbeitete. Stattdessen konzentrierten wir uns auf die erfolgreichsten Angriffsvektoren: die Offenlegung personenbezogener Daten und sitzungsübergreifende Datenlecks.
Die auffälligste Erkenntnis aus der zweiten Runde war verblüffend einfach: Oft musst du überhaupt nicht raffiniert vorgehen.
In vielen Fällen genügte es, im Rahmen einer legitim klingenden Anfrage einfach nach internen Daten zu fragen, damit das System ihrer Offenlegung zustimmte. Auf einfache Anfragen folgten Antworten, die interne IDs und Systemfelder nannten, die für Endnutzende niemals sichtbar sein sollten.
Bei genauerer Untersuchung stellten wir fest, dass dies nicht nur ein Fehler auf Anwendungsebene war. Der nachgelagerte Text-to-SQL-Dienst erstellte Abfragen, die mehr Felder als vorgesehen anforderten. Zudem verwiesen seine erläuternden Antworten auf Daten, deren Zugriff hätte beschränkt sein müssen. Damit wurde eine echte Schwachstelle an der Schnittstelle zwischen den Systemen sichtbar. Solche Schwachstellen treten nur zutage, wenn du den gesamten Stack testest und nicht einzelne Komponenten isoliert betrachtest.
Teste das System durch Red Teaming, nicht das Modell. Ein isolierter Test eines LLM sagt nur sehr wenig über die Sicherheitslage deiner Anwendung aus. Teste den gesamten Stack durchgängig so, wie Nutzende mit ihm interagieren würden.
Eingaben müssen vor dem LLM validiert werden. Codierte Anfragen, Angriffe mit mehreren Absichten und einfache Injection-Versuche sollten bereits an der Systemgrenze erkannt und nicht nachgelagerten Diensten überlassen werden.
Vertraue den Schnittstellen nicht. In Architekturen mit mehreren Diensten verbergen sich die interessantesten Schwachstellen an den Schnittstellen zwischen den Systemen. Zero Trust bedeutet Zero Trust. Validiere daher alles auf jeder Ebene.
Einfache Angriffe funktionieren. Komplexe Jailbreaks sorgen für Schlagzeilen, aber manchmal kannst du einfach ... fragen. Wenn dein System bereitwillig interne Kennungen ausgibt, sobald sie in einer ansonsten legitimen Anfrage erwähnt werden, ist das ein Problem.
Verstehe, was du tatsächlich testest. Bekannte Angriffsmuster werden möglicherweise durch das Training des LLM selbst erkannt und nicht durch deine Schutzmechanismen. Integriere Beobachtbarkeit in dein Red Teaming, damit du nachvollziehen kannst, welche Kontrollen tatsächlich greifen.
Eingeschränkte Umgebungen erfordern kreative Lösungen. Benutzerdefinierte Anbieter und die Unterstützung lokaler Modelle ermöglichen aussagekräftiges Red Teaming ohne besonderen Cloud-Zugriff. Die daraus entstehenden Einschränkungen solltest du jedoch transparent darlegen.
Red Teaming ist keine einmalige Aufgabe. Es ist ein iterativer Prozess, sollte nach Möglichkeit automatisiert werden und sich gemeinsam mit deinem System weiterentwickeln. Die morgen relevanten Angriffe sind nicht dieselben wie heute.
KI-Systeme in regulierten Umgebungen werden künftig noch genauer geprüft werden. Organisationen, die Sicherheitstests als kontinuierliche Aufgabe statt als Punkt auf einer Checkliste vor der Einführung betrachten, sind besser auf diese Prüfungen vorbereitet. Außerdem können sie PR-Krisen vermeiden, durch die sie das Vertrauen ihrer Kundschaft verlieren.