KI in der Software – clever eingesetzt, sicher geschützt
Der Einsatz von Künstlicher Intelligenz in Software erweitert die Angriffsflächen. Wer KI implementiert, muss die versteckten Sicherheitsrisiken kennen und absichern.
Im Bereich Cyber Security entscheidet die präzise Analyse von Risiken über die Sicherheit. Wir werfen in diesem Blogbeitrag einen Blick auf die Risiken von Large Language Models (LLMs) und zeigen am Beispiel einer Anwendung zur Gesetzestext-Zusammenfassung, wie diese entstehen und wie man ihnen begegnet.
Die Beispielanwendung: Gesetzestexte mit RAG zusammenfassen
Unsere Beispiel-App nutzt ein LLM, um relevante Passagen aus Gesetzestexten zu extrahieren und für ein Unternehmen zusammenzufassen. Damit das Modell unternehmensspezifische Relevanz erkennt, wird sogenannter Kontext über Retrieval-Augmented Generation (RAG) hinzugefügt. Die Architektur der Anwendung umfasst klassische Komponenten wie Frontend, Backend und Datenbank (mit internen Unternehmensdokumenten) - ergänzt durch ein integriertes LLM.
Drei zentrale Angriffskategorien auf LLM gestützte Anwendungen
Neben bekannten Sicherheitsrisiken wie SQL-Injection oder Cross-Site Scripting treten durch den Einsatz von LLMs neue, spezifische Bedrohungen auf. Sie lassen sich in drei Hauptkategorien einteilen:
1. Poisoning Attacks
Bei diesen Angriffen wird das Modell gezielt manipuliert, um fehlerhaftes Verhalten auszulösen. Zwei Varianten sind besonders relevant:
- Training Data Poisoning:
Schädliche Inhalte werden bereits in den Trainingsdaten platziert. - Knowledge Poisoning:
Der Angreifende manipuliert die Kontextdaten, die dem Modell über RAG bereitgestellt werden.
Gerade Knowledge Poisoning stellt in unserer Anwendung ein ernstzunehmendes Risiko dar. Eine angreifende Person mit Zugriff auf die Kontextdaten könnte dort gezielt schädliche Anweisungen einfügen.
2. Privacy Attacks
Hier versucht die angreifende Person, vertrauliche Informationen aus der LLM-Anwendung zu extrahieren. Mögliche Szenarien:
- Model Theft:
Durch massenhafte Anfragen wird versucht, das Modell zu rekonstruieren. - Reconstruction of Training Data:
Der Angreifende versucht, Rückschlüsse auf die ursprünglichen Trainingsdaten zu ziehen. - Leakage von Systemprompts oder Kontextdaten:
Auch sensible Informationen wie API-Keys, Passwörter, Datenbanknamen oder andere sensible Daten im Kontext können betroffen sein.
Solche Angriffe sind in unserer Beispielanwendung grundsätzlich möglich. Daher ist es essenziell, sensible Informationen konsequent aus Systemprompts und Kontextdaten herauszuhalten und über RAG idealerweise nur Zugriff auf nicht sensible Daten bereitzustellen.
3. Evasion Attacks (Prompt Injection)
Diese Angriffe zielen darauf ab, das Verhalten des LLMs durch manipulierte Eingaben zu verändern und beispielsweise dazu zu bringen, schadhafte Aktionen auszuführen. Man unterscheidet:
- Direkte Angriffe:
Der Angreifende gibt manipulierte Eingaben direkt über die Benutzeroberfläche ein. - Indirekte Angriffe:
Schädliche Inhalte gelangen über externe Quellen (z. B. Websites, Datenbanken) in den Kontext.
In unserer Anwendung wären beide Varianten denkbar, etwa durch manipulierte Gesetzestexte (die der Nutzende eingibt) oder kompromittierte Kontextdaten (die durch RAG hinzugezogen werden).
Schutzmaßnahmen zur Risikoreduktion
Poisoning Attacks können vor allem durch zwei Maßnahmen adressiert werden: Durch Anwendung klassischer IT-Sicherheitsmaßnahmen muss der Zugang zu Trainingsdaten und Daten, die für RAG als Kontext bereitstehen, gesichert werden, und diese so vor Manipulation geschützt werden. Sollten externe Quellen (z.B. Webseiten, öffentliche Datenbanken oder frühere Nutzereingaben) zum Training oder als Kontext einbezogen werden, sollten diese Quellen bedacht gewählt werden und ggf. die Daten vor der Verwendung geprüft und bereinigt werden.
Das Risiko von Privacy Attacks und Prompt Injections kann durch verschiedene Maßnahmen verringert werden: Zum einen müssen beispielsweise sensible Informationen strikt aus dem Kontext (Systemprompt und Daten für RAG) herausgehalten werden. Sollten verschiedene Nutzende Zugriff auf verschiedene Kontextdaten benötigen, müssen Zugriffsrechte des RAG an die Rechte des Nutzenden gekoppelt werden. Je nach Kritikalität der verbleibenden Daten können spezialisierte KI-Modelle kombiniert mit Blocklisten von Textbausteinen verwendet werden, um zu versuchen Extraktionsversuche oder andere Injection Angriffe zu erkennen (wobei das keinen 100%igen Schutz bieten kann, den Aufwand und die Erkennbarkeit aber enorm erhöht). Abgerundet werden diese Maßnahmen durch klassische Rate-Limits und Monitoring Maßnahmen, um Angriffe einzudämmen und im Betrieb erkennen zu können.
Relevanz für unsere Beispielanwendung
Übertragen auf unsere Beispielanwendung sind sicherlich die meisten der vorgestellten Risiken erstmal relevant. Insbesondere, da unser Beispiel nur für den internen Gebrauch im Unternehmen gedacht ist und mit allgemeinen Unternehmensdaten arbeitet, kann jedoch Risiko und Aufwand von Schutzmaßnahmen gegeneinander abgewogen werden.
Um die Qualität der Antworten hochzuhalten, ist der Schutz von Kontext- und Trainingsdaten auf jeden Fall zu gewährleisten. Auch die Einschränkung der Kontextdaten ist wichtig, um nicht beispielsweise aus Versehen sensible Mitarbeitendendaten für andere Mitarbeitenden zugänglich zu machen. Das Risiko von Injection Angriffen hingegen ist in diesem Beispiel vermutlich eher vernachlässigbar. Sollte die Anwendung irgendwann öffentlich verfügbar gemacht werden, oder der Einsatz in einem besonders schutzbedürftigen Unternehmen stattfinden, wäre über weitere Maßnahmen nachzudenken.
Weitere Sicherheitsaspekte bei KI-Anwendungen
Neben den genannten Angriffen sollten auch klassische Risiken wie Supply-Chain-Angriffe berücksichtigt werden, etwa durch kompromittierte LLMs oder RAG-Komponenten. Alle eingesetzten Bibliotheken und Modelle sollten sorgfältig geprüft und regelmäßig aktualisiert werden.
Ein sicherer Entwicklungsprozess ist sowieso unerlässlich. Dazu gehören beispielsweise:
- Threat Modeling zur Identifikation potenzieller Risiken und zur Einschätzung der Risiken in Bezug auf das geplante Einsatzgebiet
- Code Reviews und ggf. Penetration Testing
- Integritätsprüfungen aller eingesetzten Komponenten
Fazit: Sicherheit von Anfang an mitdenken
Die Integration von KI in Softwareanwendungen erfordert ein neues Sicherheitsbewusstsein. Unternehmen sollten Sicherheitsaspekte nicht als nachträgliche Maßnahme betrachten, sondern als integralen Bestandteil des Entwicklungsprozesses. Nur so lassen sich die Potenziale von KI sicher und verantwortungsvoll nutzen.
Sie möchten Ihre KI-Anwendung sicher gestalten? Wir unterstützen Sie gerne bei der sicheren Umsetzung Ihrer KI-Projekte oder der Integration von KI-Services in bestehende Produkte.
