OWASP untersucht Künstliche Intelligenzen Sicherheit und Privatsphäre bei KI-Projekten

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Künstliche Intelligenz rüttelt die Tech-Welt derzeit ganz schön durch. Überschäumender Enthusiasmus auf der einen Seite. Jobverlust-Paranoia auf der anderen Seite. Was bislang etwas kurz kommt: Ganz reale Probleme rund um Sicherheit und Privatsphäre.

DALL-E, ChatGPT, GitHub Copilot, nur drei der Dutzenden KI-Services, die seit ein paar Monaten den Duft einer Revolution versprühen – nicht nur für die Technik, auch für die Gesellschaft. Journalisten, Künstler und Entwickler sind begeistert von den neuen, die Produktivität ins Unermessliche steigernden Tools. Oder fürchten sich vor der eigenen Obsoleszenz im Angesicht vermeintlich besserer KI-Konkurrenz.

Die Realität, so viel Weissagung sei gestattet, wird irgendwo dazwischen landen – und genau da liegt auch das Thema Security. Für Weltuntergangsexperten mag dieser Bremsklotz eine Nummer zu klein sein, für Enthusiasten überflüssig, aber es muss halt sein. Das hat erfreulicherweise auch The Open Worldwide Application Security Project erkannt, besser bekannt als OWASP Foundation.

Das OWASP hat Anfang des Jahres einen ersten Entwurf für einen Guide zu Sicherheit und Privatsphäre im KI-Umfeld veröffentlicht, das als „Incubator Project“ eingestuft ist, sich also noch in einer sehr frühen Phase befindet. Federführend ist Rob van der Veer von der niederländischen Software Improvement Group.

Vorgestellt wurden die Inhalte grundsätzlich bereits auf der Konferenz OWASP Global AppSec – und auch der Einleitungssatz zu dieser Präsentation trägt der gehobenen Erwartungshaltung bezüglich KI Rechnung: „Is AI our doom or our savior?“ Der Leitfaden beginnt mit allgemeinen Tipps zum Umgang mit AI Security im Unternehmen und widmet sich dann zunächst konkreten Sicherheitsrisiken, anschließend dem Thema Privatsphäre.

Im allgemeinen Bereich bleibt es – nun – sehr allgemein: (Strukturierte) Maßnahmen zur Cybersecurity weiterführen, die Praktiken guten Software Engineerings auch auf den Lebenszyklus von KI-Systemen anwenden (ISO/IEC 5883) und mit KI beschäftigte Mitarbeiter aus Entwicklung, Datenzentrum und Administration in die allgemeinen Security-Programme (Schulungen, Pentesting, Anforderungsmanagement etc.) einbeziehen. Überdies sollten allen Beteiligten die Risiken und potenziellen Attacken bekannt sein!

Konkrete Risiken

Ganz unten im Stack beginnt die Entwicklung von KI-Projekten mit der Erfassung und Vorbereitung der Trainingsdaten, was eigene Sicherheitsprozesse für den Umgang erfordert – zumal dies häufig außerhalb der eigentlichen Applikation stattfindet, wie van der Veer vermerkt. Spannend ist hier vor allem folgender Aspekt: Entwickler brauchen für das Training ihrer KI-Modelle echte Daten, keine künstlich erstellten Demo-Daten. Hier muss also von Beginn an reguliert werden, wer diese Daten sehen darf.

Reichlich Angriffsfläche bietet auch das KI-Modell, der Guide unterscheidet hier insgesamt sechs Attacken. Als „Data poisoning attack“ wird die gezielte Manipulation der Trainingsdaten verstanden. Ein Angreifer könnte hier beispielsweise Bilder unbefugter Personen für eine KI-Zugangskontrolle mit dem Label „befugt“ manipulieren. OWASP führt manipulierte Verkehrsschilder als Beispiel auf, die in einer Studie als „35 Mph“ statt als „Stopp“ interpretiert wurden.

Die „Input manipulation attack“ ist quasi eine Variante der Vergiftung: Hier wird nicht auf irreführende Labels im Trainings-Set gesetzt, sondern auf manipulierte Daten. Die KI wird dabei mit Daten gefüttert, die unerwünschte Ergebnisse produzieren – sei es mit gezielten Daten nach Analyse der Modell-Parameter (Whitebox) oder nach Analyse der Ergebnisse bei genau spezifizierten (aber mehr oder weniger willkürlichen) Input-Daten. Die empfohlenen Gegenmaßnahmen darf man dabei durchaus etabliert konservativ nennen: Zugriffsbeschränkungen, künstliche Verlangsamung, Monitoring und strenge Kontrolle der Daten, die der KI zugeführt werden.

Unter „Membership interference attack“ wird ein sehr interessanter Angriffsvektor vermerkt, den vermutlich alle kennen, die schon mal selbst mit Gesichtserkennung gearbeitet haben – etwa mit OpenCV: Lässt man einen gegebenen Datensatz via Blackbox-Zugriff auf eine KI evaluieren, lässt sich gegebenenfalls erkennen, ob dieser Teil der originalen Trainingsdaten war.

Mal als Beispiel: Eine KI soll nach Gesichtern urteilen, ob es sich um Mann oder Frau handelt. Wenn das Ergebnis zu einem eingespeisten Foto 100 Prozent lautet, darf man davon ausgehen, dass die Person im Trainings-Set vorhanden war. Eine simple Lösung wäre zum Beispiel das Hinzufügen von Rauschen/Noise zum Set.

Etwas vager – und etwas unheimlich – wird es bei der „Model inversion attack“. Die Grundgefahr besteht darin, durch Analyse oder Interaktion Teile der Trainingsdaten oder Funktionalitäten zu „schlussfolgern“, was problematisch ist, wenn es sich dabei um sensible Daten handelt. Bildlicher macht es ein Beispiel: Über geschickt formulierte Prompts ist es dem Stanford-Studenten Kevin Liu gelungen, Bing seinen internen Code-Namen zu entlocken. Im Grunde handelt es sich hier also um Social Engineering – und dass das mit einer KI klappt, ist schon etwas gruselig.

Die „Model theft“-Attacke dürfte das Management aufhorchen lassen: Die Grundidee ist, ein KI-Modell mit Daten zu füttern und die Ergebnisse als Zieldefinition beim Training einer anderen KI zu nutzen – was letztlich zu einer Kopie des tendenziell geschützten Modells führen würde. Auch hier werden Zugriffsbeschränkungen und künstliche Bremsen empfohlen (eine gewisse Nähe zu traditionellen Brute-Force-Angriffen wird hier deutlich sichtbar).

Bei der letzten Modell-Attacke wird es wieder etwas schwammiger: Bei der „Model supply chain attack“ geht es kurz gesagt darum, dass unter Umständen irgendwelche, gegebenenfalls öffentlich zugänglichen, Code-Bestandteile verändert werden – daher auch analog zum ersten Model-Threat alternativ „Algorithm/Model poisoning“ genannt. Wirklich neu ist hier allerdings nichts, es gelten die gleichen Risiken und Lösungen wie bei Attacken auf sonstige Software Supply Chains.

Weitere Risikofaktoren

Damit schließt das Paper das Kapitel Modell-Attacken und führt drei weitere Risikopotenziale auf, die sich wieder auf den Code im Allgemeinen konzentrieren. Beim „AI code reuse“ wird darauf verwiesen, dass insbesondere im KI-Bereich viele Beispielprojekte im Netz kursieren, deren Code (und Daten) von Wissenschaftlern, Datenspezialisten und Entwicklern wiederverwendet werden.

Dies ist nur logisch, schließlich ist das Thema noch jung, die Technik komplex und die benötigte Datenmenge enorm! Wenn sich dann in Demo-Daten Probleme bezüglich der Vertraulichkeit oder in Demo-Code Probleme mit der Sicherheit zeigen, können sie ganze Projekte verseuchen. Kurz: Wie bei jeder Code-Wiederverwendung muss hier sehr sorgfältig geprüft werden.

Bezüglich der „AI code maintainability“ spricht van der Veer ein Personalproblem an: Er vermutet hier im Bereich der KI sehr viel mehr aktive Datenwissenschaftler als klassische Entwickler – die entsprechend nicht darauf geeicht sind, sauber wartbaren Code zu produzieren. Gegenmaßnahmen sind hier simpel: Schulungen und Zuordnung von ausgewiesenem Fachpersonal.

Zu guter Letzt wird erneut die „AI supply chain complexity“ angesprochen (van der Veer sieht hier mehr Komplexität als bei Nicht-AI-Projekten) und um Doppelungen zu vermeiden und es kurz zu machen: Aus der gerade im Open-Source-Bereich zuletzt häufig zu findenden SBOM (Software Bill of Materials) wird die AIBOM – ein neues Buzzword, dass Ihnen die Google-Werbemaschinerie sicherlich in den nächsten Monaten in die Timelines spielen wird.

Und dann gibt es da noch das Thema Privatsphäre – um das es hier aber nicht gehen soll. Zum einen werden dort viele Allgemeinplätze aufgeführt, zum anderen wird es bei dem Thema sehr schnell rechtlich und damit uneinheitlich. Das OWASP-Projekt ist wie erwähnt in einem frühen Status, es lohnt sich sicherlich, das Dokument im Auge zu behalten.

Hierzulande kümmert sich auch das BSI um das Thema KI-Sicherheit, 2019 ist sogar eigens ein Kompetenzzentrum Künstliche Intelligenz ins Leben gerufen worden. Einige sehr gute und ausführliche Informationen finden Sie auf der Projektseite in Form mehrerer Studien, Beispiel und Grundsatzdokumente.

(ID:49329435)