Umgang mit neuen Security-Herausforderungen durch KI So schützen Sie Ihre KI vor Prompt-Injection & Co.

KI-Lösungen bringen neben vielen bekannten Vorteilen aus der Perspektive IT-Sicherheit neue Herausforderungen mit sich. Dies sind bedingt durch den EU-AI-Act regulatorische Einschränkungen und Anforderungen, aber auch neue technische Angriffsvektoren und Schwachstellen. Klar ist: Wer Projekte für KI-Lösungen plant oder dabei ist, diese zu implementieren, sollte jetzt Handeln.

Der Go-Live von ChatGPT im Oktober 2022 hat speziell das Thema generative KI (GenAI) befeuert. Im aktuellen Hype um das Thema KI, bestehen – wie bei jeder neueren Technologie – Chancen und Risiken. Es ist vermutlich nicht ungewöhnlich, dass in der Euphorie eher die Chancen betrachtet werden. Die Risiken jedoch zu ignorieren sollte eigentlich keine Option sein. Daher werden in der Folge einige der spezifischen Risiken beim Einsatz von GenAI betrachtet.

Gerade in „klassischen“ Entwicklungsprojekten wird das Thema Security im Bezug auf KI nur in den seltensten Fällen (früh genug) in den Prozess eingebunden (Stichwort: Shift-Left). Doch die zusätzlichen Gefahren und Risiken sollten dazu bewegen, Security und Compliance von Anfang an als wesentliche nicht-funktionale Eigenschaft zu behandeln.

Ausgangslage

Zunächst sollte man sich in Erinnerung rufen, dass KI-Lösungen zum überwiegenden Teil auf bereits etablierten Technologien aufbauen. Abgesehen von wenigen spezifischen Entwicklungen, wie beispielsweise dedizierte Chipsätze oder neue Methoden für die Speicherung von Daten, wird mit fast vollständig bekannten IT-Stacks gearbeitet. Für die weiteren Ausführungen soll daher die Annahme getroffen werden, dass die klassischen Security-Maßnahmen auf diesem Stack angewendet werden (Härtungsmaßnahmen, Secure Coding, zeitnahes Patchen etc.).

Ein Blick auf die neuen OWASP Top 10 for LLM

Risiken generativer KI und Large Language Models (LLM)

KI-Sicherheit: Wo liegen die Unterschiede?

Im Vergleich zu den im vorherigen Absatz beschriebenen Maßnahmen in klassischen IT-Lösungen, nimmt jedoch die Prüfbarkeit von In- und Output bei KI-Lösungen eine zentralere Rolle ein. Dies ist notwendig, da sich bei KI-Systemen wesentlich mehr auf der semantischen, sprich der inhaltlichen Ebene abspielt.

Bei klassischen IT-Systemen erfolgt auf eine bestimmte Eingabe meist dieselbe Ausgabe. Bei KI-Systemen hingegen erfolgt auf eine bestimmte Eingabe „nur“ eine wahrscheinlich richtige und inhaltlich nur wahrscheinlich identische Ausgabe. Wesentliche Aspekte der Regulatorik beziehungsweise der neuen Angriffsvektoren zielen jedoch genau auf diese Wahrscheinlichkeits-Eigenschaft ab.

Risk Management bei KI

EU AI Act als Wegweiser für sichere KI-Systeme

Ein kurzer Blick auf die Regulatorik

Damit GenAI-Anwendungen zum Einsatz kommen dürfen, müssen sie in der Regel regulatorische Anforderungen erfüllen – etwa, wenn es um sensible Vorgänge wie medizinische Diagnosen oder die Kreditvergabe einer Bank geht. Hier darf die Entscheidung einer KI keine Black-Box sein, die Ergebnisse müssen nachvollziehbar (erklärbar) sein. Methoden, um die Erklärbarkeit von KI-Anwendungen herzustellen, sind in der Entwicklung und teilweise bereits im Einsatz, aber speziell bei Large Language Models (LLMs) nur sehr bedingt aussagefähig. Da die Erklärbarkeit nur bedingt aussagefähig ist, ist daher eine regulatorische Anforderung eine Risiko-Bewertung und eine entsprechende Einschränkung bestimmter Einsatz-Gebiete von GenAI-Anwendungen. Aktuell darf in der EU zum Beispiel KI kaum für die biometrische Remote-Identifikation oder für soziale Bewertungen (Social Scoring) verwendet werden.

Erschwerend kommt hinzu, dass bei öffentlichen LLMs die Trainingsdaten nicht zugänglich sind. Während also bei kleineren Modellen auf Basis der Trainings-Daten und der Klassifikationen dieser Daten eine gewisse Nachvollziehbarkeit der Entscheidungen erreichbar ist, ist dies bei öffentlichen LLMs nicht möglich. Dies hat weitreichende Konsequenzen für ihren Einsatz, auch für Open-Source-Modelle. Denn neben der klassischen SBOM (Software Bill of Material), die durch mehrere Regulations-Novellen wie beispielsweise NIS2 und DORA bereits stärker in den Fokus geraten ist, kommt bei KI zusätzlich die MBOM (Modell Bill of Material) hinzu, also die strukturierte Erfassung und Behandlung von Modellen und Modell-Bausteinen wie Trainings-Daten etc.

KI-Tools und Datenschutz – Darauf ist zu achten!

Wie man KI-Tools daten­schutz­konform nutzen kann

ETH Zürich prüft nach

Wie gesetzestreu sind ChatGPT und andere KI-Modelle?

Ein Blitzlicht auf mögliche Angriffe und Schwachstellen

Auch wenn die Regulatorik und ihre Auswirkungen auf den Einsatz von KI-Systemen nur gestreift wurde, soll dieses Thema nicht näher betrachtet werden. Stattdessen sollen im folgenden Abschnitt ein paar Beispiele für Angriffsmöglichkeiten auf KI-Systeme aufgezeigt werden.

• Prompt-Injection: Eine generative KI wird durch manipulative Eingaben dazu gebracht, beispielsweise vertrauliche Daten preiszugeben. Der Angreifer nutzt dabei die Möglichkeit, beliebige Eingaben am Text-Prompt zu machen. Die Prüfung, ob diese Eingabe Befehle oder Ähnliches enthält, hilft bei klassischen Injektion-Angriffen. Das semantische Problem und zum Beispiel eine Berechtigungsprüfung erfordern jedoch zusätzliche Sicherheits-Maßnahmen, die allerdings zwischen den verschiedenen Einsatzgebieten von KI-Systemen stark variieren und individuell abgestimmt werden müssen. Denn, wie man sich denken kann, sind einfache Ansätze wie Erlaubt- oder Verbotslisten auf Wort- oder Satz-Fragment-Basis leicht zu umgehen. Der Einsatz weiterer Modelle für die Prüfung der Eingaben verschiebt das Problem erst einmal nur.

• Poisoning-Angriffe: Der Versuch durch manipulierte Eingaben die Sicherheit, Qualität oder ethischen Grundsätze aushebeln. Das Ziel dieser Angriffe ist nicht unmittelbar Daten abzugreifen, sondern durch Änderung des Modell-Verhaltens die Ergebnisse für andere Benutzer so zu verändern, dass mittelbar die Angriffs-Ziele erreicht werden. Dieser Angriff kann je nach Architektur der KI-Anwendung über direkte Eingaben oder auch über Angriffe auf beispielsweise die Trainings-Daten erfolgen.

• Model Theft: Durch sehr viele Anfragen oder durch direkten Zugriff auf das Modell oder die Trainingsdaten wird versucht, ein KI-Modell „nachzubauen“. Das betrifft in erster Linie von anderen Firmen eigens gebaute KI-Modelle und spielt eine größere Rolle, wenn das KI-Modell interne oder sogar geheime Zusammenhänge enthält.

• Model Denial of Service: Klassische Denial-of-Service-Angriffe, mit dem Ziel, die KI durch viele oder gezielt komplexe Anfragen zu blockieren. Um eine Überlastung zu vermeiden, sollten natürlich die klassischen IT-Security Themen wie DDoS-Angriffe betrachtet werden, jedoch kann (abhängig von der Modell-Komplexität) bereits eine geringe Anzahl von Fragen zu einer hohen Last und damit auch zu hohen Kosten führen.

Wenn Neuronale Netze zu falschen Aussagen kommen

Data Poisoning – der vergiftete Apfel für KI

KI-Chatbots lassen sich manipulieren

Microsoft meldet Jailbreak für GPT, Llama und Gemini

Was sollten Verantwortliche jetzt tun?

Durch die Angriffsmöglichkeiten auf KI-Systeme entstehen also Herausforderungen und entsprechend auch neue Sicherheits- und Compliance-Anforderungen. Diese können nun von Projektverantwortlichen als Basis verwendet werden, um Anforderungen und mögliche Schwachstellen gezielt beim Projektstart zu adressieren. Eine Option, die in der IT leider auch bei „normalen“ Software-Entwicklungsprojekten viel zu selten beachtet wird.

Auch wenn nicht alle Auslegungen der regulatorischen Anforderungen bekannt sind und es keine perfekte Antwort auf alle möglichen Schwachstellen gibt, sind KI-Projekte eine gute Möglichkeit, Dinge von Anfang an besser zu machen.

Analog zum Secure Software Development Lifecycle empfiehlt sich die Implementierung einer KI-spezifischen Variante, sogenannte Machine Learning Operations (MlOps). MlOps bedient sich dabei bekannter Mechanismen des Software Development Lifecycle und DevSecOps-Ansätzen und behandelt die Themen Security und Compliance als „First Class Citizen“ im Entwicklungsprozess. Angefangen beim KI-Security-Requirements-Engineering über spezifische Bedrohungs-Modellierungs-Ansätze über Dependency-Management und Code-Security werden alle Facetten dieser Themen beleuchtet und bei einem typischerweise risiko-basierten Ansatz bewertet und bearbeitet.

Das Wissen bezüglich KI-Security-Ansätzen und -Lösungen ist bereits vorhanden und teilweise sehr gut dokumentiert. So existieren zum Beispiel für Machine Learning und LLMs spezifische OWASP-Top-Ten Abbildungen für die kritischsten Schwachstellen inklusive möglicher Maßnahmen. Auch im Produkt-Umfeld gibt es Lösungen für die Absicherung von Modellen, etwa Gateways, die vor die eigentlichen Modelle geschaltet werden und in gewisser Weise analog zu einer Web Application Firewall fungieren. Bei Tools gilt es wie immer zu beachten, dass Einsatzzweck und Möglichkeiten des Tools gut abgestimmt sind. Zudem müssen entsprechendes Know-how und auch die Zeit vorhanden sein, um die Tools sinnvoll einzusetzen. Ein Tool allein löst selten das Problem, für das es eingesetzt wird.

Security-Trends 2025

Unternehmen sollten ihre KI, APIs und Daten jetzt sichern!

Fazit

Neben vielen bereits bekannten Security-Heraus- und Anforderungen gibt es im KI-Umfeld tatsächlich auch neue Aspekte zu beachten. Im Prinzip unterscheiden sich die möglichen Maßnahmen für eine sichere und konforme Entwicklung aber nur in einigen – teilweise durchaus wesentlichen - Fragestellungen. Auch wenn der Aufwand neue KI-Lösungen abzusichern durchaus beträchtlich sein kann, ist für uns (hoffentlich nicht nur die Autoren dieses Beitrages) klar, dass das Security- und Compliance-Problem von Anfang an betrachtet und angegangen werden muss. Das bedeutet eine frühzeitige Einbindung von Sicherheitsexperten und Security-Betrachtungen in interne Informations-Sicherheits-Prozesse (z.B. Asset- und Risiko-Management), aber auch aktives Security-Engineering in der Entwicklung und dem Betrieb von KI-Lösungen. Ein Sicherheitskonzept ist daher eine notwendige, aber keine hinreichende Bedingung!

Über die Autoren

Oliver Kling, Dipl. Ing, CISA ist IT-Experte mit mehr als 30 Jahren Erfahrung. Seit 15 Jahren ist er spezialisiert auf IT-Sicherheit und speziell deren Rolle in der Softwareentwicklung. Derzeit ist er Senior Manager bei der adesso SE, einem börsennotierten Beratungs- und IT-Dienstleistungsunternehmen. Er leitet ein Team von Security-Engineers und Penetrationstestern und unterstützt Kunden mit Sicherheitsexpertise in unterschiedlichen Branchen und Kontexten.

Florian Weller, B.Sc. IT-Security ist Managing Security Spezialist für IT-Systeme und Netzwerke, insbesondere spezialisiert auf Penetrationtesting und die Absicherung des Software Development Lifecycles. Hierfür studierte er bis 2017 IT-Security an der Hochschule Aalen. War anschließend ein Jahr als Entwickler tätig und ist seit 2018 als Consultant für verschieden Firmen und Branchen im Bereich Security aktiv. Außerdem leitet er Hacking Workshops, ist Referent & Dozent für Secure Coding, leitet Programmierkurse in Python und hält Awareness Schulungen.

(ID:50300814)