HiSolutions Research

Italienische Datenschutzbehörde: ChatGPT verstößt gegen EU-Recht

Die italienische Datenschutzbehörde hat OpenAI darüber informiert, dass ChatGPT gegen die EU-Datenschutzverordnung GDPR verstoßen hat.

Bereits im April 2023 hatte die Behörde ChatGPT aufgrund illegaler Datensammlung und fehlender Systeme zur Altersüberprüfung vorübergehend gesperrt. Sie stellte fest, dass ChatGPT trotz der Ausrichtung auf Benutzer ab 13 Jahren Minderjährige unangemessenen Antworten aussetzt. OpenAI erklärte damals, die Forderungen der italienischen Datenschutzbehörde bis zum 30. April erfüllt zu haben, weshalb das Verbot des Chatbots aufgehoben wurde.

Nun hat die Behörde nach einer weiteren Untersuchung entschieden, dass ChatGPT gegen die EU-Datenschutzregeln verstoßen hat. Sie bemängelt, dass OpenAI die Benutzer nicht darüber informiert, dass ihre Daten gesammelt werden. Nach der DSGVO benötigt das Unternehmen aber eine Einwilligung zur Verarbeitung der personenbezogenen Daten. Zusätzlich gibt es Vorwürfe bezüglich der Genauigkeit der Verarbeitung. Nun soll ein Sonderausschuss aus Datenschutzbehörden der EU eingerichtet werden, um die Problematik weiter zu untersuchen.

OpenAI selbst hat 30 Tage Zeit, auf die Anschuldigungen zu antworten.

https://www.golem.de/news/verstoesse-gegen-dsgvo-italiens-datenschuetzer-gehen-erneut-gegen-chatgpt-vor-2401-181672.html

https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9978020#english

https://www.garanteprivacy.it/web/guest/home/docweb/-/docweb-display/docweb/9870847#english

HiSolutions Research

Nach Entwicklung und Betrieb folgt der Leitfaden zur sicheren Nutzung von KI

Nachdem wir bereits im Dezember letzten Jahres über die Veröffentlichung des Leitfadens zur Entwicklung und zum Betrieb von KI-Systemen berichtet haben, liefert der Kooperationsverbund aus Cybersicherheitsbehörden nach. Das BSI gibt mit seinen Partnerbehörden unter australischer Federführung einen Leitfaden zur sicheren Nutzung von KI-Systemen heraus.

Das Papier gibt einen Überblick über wichtige Bedrohungen und Gegenmaßnahmen, die Anwender ergreifen können.

Die Veröffentlichung reiht sich in die Diskussion um den AI Act ein, bei dem die EU ein europäisches Gesetz schaffen möchte, um Anwendungsfälle von KI in risikobehafteten Bereichen zu regulieren.

Wie auch im vorherigen Leitfaden fällt auf, dass sich die vorgeschlagenen Gegenmaßnahmen stark mit klassischen Anforderungen überschneiden. KI-Systeme bleiben nun mal auch Computer. Wir halten es trotzdem für richtig, mit der Veröffentlichung von Leitfäden die Kenntnisse bei Unternehmen zu verbessern.

https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html

https://www.cyber.gov.au/resources-business-and-government/governance-and-user-education/governance/engaging-with-artificial-intelligence

https://artificialintelligenceact.eu/de

HiSolutions Research

Sichere KI, unsichere KI

Kurzes Durchatmen im KI-Hype liefert vielleicht die Studie von Cameron Jones und Benjamin Bergen, die zeigt, dass auch aktuelle große Sprachmodelle (LLM) den Turing-Test nicht bestehen. Informatik-Pionier Alan Turing hat schon 1950 diesen Test vorgeschlagen, in dem eine künstliche Intelligenz und ein Mensch mit einem Menschen chatten. Der Turing-Test gilt als bestanden, wenn der Mensch den Computer nicht sicher erkennen kann. Inzwischen wird der Test eher so aufgebaut, dass die menschlichen Teilnehmenden am Ende einer Sitzung eine Schätzung abgeben müssen. Denken sie dabei in mehr als der Hälfte der Fälle, dass sie gerade mit einem Menschen gesprochen haben, gilt der Test für die KI als bestanden. GPT-4 war noch unter der Schwelle, kam ihr aber mit 41 % recht nah.

Um Sicherheit angemessen bei KI-Projekten zu berücksichtigen, haben 23 Cybersicherheitsbehörden, darunter auch das BSI, einen gemeinsamen Leitfaden entwickelt und veröffentlicht. Der Leitfaden stellt kompakt wichtige Sicherheitsaspekte bei der Entwicklung und beim Betrieb von KI-Systemen vor. Einige überschneiden sich deutlich mit klassischen Anforderungen in den jeweiligen Phasen, aber am Ende sind KI-Systeme auch nur Computer.

Does GPT-4 Pass the Turing Test? https://arxiv.org/abs/2310.20216

Guidelines for secure AI system development: https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf

HiSolutions Research

Der Trojaner im Sprachmodell, der die KI zum lügen bringt

Dass die aktuellen LLM-basierten Chatbots nicht immer die Wahrheit ausgeben, ist hinlänglich bekannt. Es fehlt ihnen einfach das Konzept von richtig und falsch, sodass sie nur die statistisch wahrscheinlichste Antwort ausgeben.

Forscher haben darüber hinaus gezeigt, wie sie ein vorhandenes Sprachmodell so modifizieren konnten, dass es zu bestimmten Fakten überzeugend falsche Informationen ausgibt, gleichzeitig aber weiterhin zu allen anderen Fragen wie zuvor antwortet. Damit konnten sie dann auch Prüftools austricksen, die mit Stichprobenfragen die Qualität von trainierten Sprachmodellen bewerten. In die Malware-Sprache übersetzt: Sie konnten ihr trojanisiertes Sprachmodell am Virenscanner vorbeischmuggeln.

Weitere Sicherheitsaspekte beim Einsatz von KI haben wir in einem eigenen Blogpost zusammengefasst.

LLMs sind auch nur (schützenswerte) Informationen

Kaum ein Thema in der IT erzeugt derzeit mit ähnlicher Taktrate neue Schlagzeilen wie die aktuelle Entwicklung von sogenannten Large Language Models (LLMs). LLMs stellen eine Variante von künstlichen neuronalen Netzen dar, die auf der Transformer-Architektur basieren. Diese wurde im Artikel “Attention is All You Need” von Google vorgestellt.

Wie bei allen (Technologie-)Hypes verbreiten und vermischen sich Fakten und Fiktion nahezu ungebremst, was nicht zuletzt durch die unbestreitbar beeindruckenden Fähigkeiten von ChatGPT und Co verstärkt wird. Auch aus Sicht der Informationssicherheit ist die Entwicklung hochgradig spannend, denn für bösartige Akteure ergeben sich neue Kategorien von Schwachstellen und damit Angriffsmöglichkeiten. Gleichzeitig stehen wir diesen Gefahren und der rasanten Entwicklung jedoch nicht hilflos gegenüber. Mit bekannten methodischen Werkzeugen und einem kühlen Kopf lassen sich Bedrohungen ermitteln und Gegenmaßnahmen ableiten.

Schutzziele gelten auch für LLMs

In der Welt der Informationssicherheit und des Datenschutzes sind drei Schutzziele von zentraler Bedeutung: Vertraulichkeit, Verfügbarkeit und Integrität. Diese gelten für alle Arten von Daten und Informationen. LLMs sind wiederum nichts anderes als Informationen in Form von Zahlen in ziemlich großen Matrizen. Dazu gehören sowohl mit gigantischem Ressourcenaufwand trainierte Foundation Models wie GPT-4 (OpenAI), LLaMA (Meta), Claude (Anthropic) und PaLM (Google) mit reglementiertem Zugriff, als auch eine unaufhörlich wachsende Menge an frei verfügbaren Klonen, nutzbar für jeden mit geeigneter Hardware (mit ausreichend Geduld sind selbst handelsübliche Grafikkarten mittlerweile ausreichend).

Bezogen auf LLMs können die Schutzziele der Informationssicherheit wie folgt beschrieben werden:

  • Vertraulichkeit bezieht sich auf den Schutz von Informationen vor unbefugtem Zugriff. Für LLMs bedeutet das, dass die Modelle gleichermaßen geschützt werden müssen, wie die Daten, mit denen sie trainiert wurden. Dies gilt sowohl für die Modelle an sich, als auch für sämtliche Datenflüsse zum Modell (Training) und ausgehend vom Modell (Inferenz bzw. Abfragen). Vergleichbar ist dies mit personenbezogenen Daten, beispielsweise bei einem System zur Verarbeitung medizinischer Daten zwecks Diagnostik. Diese unterliegen höchsten Vertraulichkeitsansprüchen, was sich auch auf verarbeitende KI-Modelle überträgt. Das betrifft nicht nur lokal betriebene Modelle sondern auch Dienste wie ChatGPT, die sich vorbehalten Benutzereingaben per Opt-Out für weitere Trainingsdaten zu verwenden. Dass die Vertraulichkeit damit eindeutig beeinträchtig ist, schlussfolgerte auch Samsung, nachdem Ingenieure geheime Unternehmensdaten in den Chatbot von OpenAI eingegeben hatten.
  • Verfügbarkeit stellt sicher, dass autorisierte Benutzer in einem angemessenen Zeitrahmen Zugriff auf die benötigten Informationen haben. Im Kontext von LLMs bedeutet das, dass die Modelle immer dann verfügbar sein müssen, wenn sie benötigt werden. Wird ein eigens trainiertes LLM im Rahmen eines wichtigen oder sogar kritischen Prozesses verwendet, sollte sichergestellt sein, dass es Sicherungskopien und Redundanzen gibt. Andernfalls können Ausfälle oder Verzögerungen von mehreren Tagen bis Wochen entstehen, um das Modell von Grund auf neu zu trainieren. Hinzu kommen die teilweise enormen Kosten durch die benötigte Rechenleistung. Auch eine Auslagerung in Cloud-Dienste löst dieses Problem nicht vollständig. Beispielsweise in der Finanzbranche gelten hohe Ansprüche an die Verfügbarkeit.
  • Integrität bezieht sich auf die Richtigkeit und Vollständigkeit von Informationen. An dieser Stelle sei das bekannte Problem von LLMs, Dinge zu “halluzinieren” kurz außer Acht gelassen. Grundlegend ist es wichtig, dass die Modelle und ihre Trainingsdaten vor Manipulationen geschützt sind. Jede Änderung der Daten oder des Modells könnte das Verhalten des LLMs beeinflussen und zu unerwünschten oder sogar schädlichen Ergebnissen führen. Dieses Problem betrifft allerdings nicht nur LLMs oder neuronale Netze, sondern auch die Auswertung von Daten allgemein und ist ein hartnäckiges Problem. Spätestens wenn auf Basis der gelieferten Ergebnisse von KI-Modellen Entscheidungen getroffen werden, die sich auf einzelne Personen oder Personengruppen auswirken, muss die Integrität der involvierten Daten gewährleistet sein.
Halluzinierende LLMs?

Halluzinationen im Kontext von LLMs bezeichnen die Eigenschaft, dass die Modelle Lücken in den Trainingsdaten mit plausibel klingenden aber falschen Aussagen überdecken. Menschen wissen, dass sie vieles nicht wissen und sind in der Lage, Wissenslücken als solche zu identifizieren und mit einem einfachen “weiß ich nicht” zu quittieren. LLMs besitzen nicht die Möglichkeiten für solche kognitiven Tricks und sind darauf trainiert, immer hilfsbereit zu sein und eine positive Antwort zu liefern. Da diese Angewohnheit für viele Anwendungsfälle einer sicheren und zuverlässigen Nutzbarkeit im Weg steht, wird aktiv an dem Problem geforscht. Derzeit ist allerdings unklar, ob und mit welchen Methoden eine Lösung möglich ist. Zumal das Verhalten für kreative Zwecke wiederum nicht unerwünscht ist.

Auf dieser Ebene betrachtet, können und müssen für die Nutzung aber auch Absicherung von LLMs mindestens klassische Sicherheitsmaßnahmen wie Verschlüsselung, Backups und Redundanzen sowie Zugriffskontrollen ergriffen werden. Am einfachsten ist der Vergleich mit typischen Wissens- und Informationsspeichern von Organisationen und Unternehmen, seien es IAM-Systeme, Fileshares, Source-Code-Verwaltung, CRM-Plattformen, Dokumentenverwaltung, Wikis und vieles mehr. Letztlich die gesamte digitale Landschaft, welche zur Erbringung der Geschäftsprozesse benötigt wird. Denn gute Informationssicherheit verfolgt grundlegend einen ganzheitlichen Ansatz.

Typische Bedrohungen in der Informationssicherheit

Um für solche digitalen Landschaften die relevanten Bedrohungen und geeigneten Sicherheitsmaßnahmen zu ermitteln, gibt es verschiedene Wege. Als Grundlage für Risikoanalysen hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Teil des IT-Grundschutzes einen Katalog von elementaren Gefährdungen erstellt. Dieser enthält typische Bedrohungen, die von Umweltereignissen über versehentliche Fehlhandlung bis hin zu Schadsoftware reichen. Während nicht alle davon direkt auf LLMs anwendbar sind, können einige jedoch als Ausgangspunkt dienen, beispielsweise der Ausfall von Kommunikationsnetzen, die Manipulation von Informationen oder auch die unberechtigte Nutzung von Systemen. Zur Inspiration sind folgend einige konkrete Beispiele aufgeführt:

Beispielhafte elementare Gefährdungen mit Bezug zu LLMs
  • G0.9 Ausfall von Kommunikationsnetzen: Besteht keine Verbindung, sei es zur Cloud oder dem eigenen Rechenzentrum in dem ein LLM betrieben wird, kann es nicht genutzt werden und die Verfügbarkeit ist beeinträchtigt.
  • G0.11 Ausfall oder Störung von Dienstleistern: Wird der Betrieb einem Dienstleister übertragen, sei es in Form von Rechenzentrumskapazitäten oder SaaS-Produkten, besteht eine Abhängigkeit, die beim Ausfall oder einer Störung zur Beeinträchtigung der Verfügbarkeit führt.
  • G0.14 Ausspähen von Informationen (Spionage): Hier wird eindeutig die Vertraulichkeit beeinträchtigt. Die Bedrohung umfasst explizit auch die Möglichkeit, dass einzelne öffentlich verfügbare unverfängliche Informationen zusammengetragen werden und dadurch erst eine kompromittierende Wirkung entfalten. Genau dies kann bei großen Trainingsdatensätzen der Fall sein.
  • G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle: Die Vielfalt sowohl von Trainingsdatensätzen als auch vortrainierten Modellen ist bereits heute gigantisch. Plattformen wie HuggingFace bieten Möglichkeiten zum Austausch von Datensätzen, Modellen und mehr. Dadurch ergeben sich ähnliche Gefahren, die für verschiedene Arten von Software- und Paket-Quellen in den letzten Jahren zu weitreichenden Auswirkungen geführt haben. Am bekanntesten sind Vorfälle des NodeJS-Paketmanagers NPM oder das Python-Äquivalent PyPI. Angreifer haben dabei Besitz von weitverbreiteten Paketen erlangt und Schadcode eingefügt oder Pakete mit ähnlich klingenden Namen genutzt, um unvorsichtige Benutzer anzugreifen. Je nach Ausprägung des Schadcodes sind demnach alle Schutzziele betroffen: Vertraulichkeit, Verfügbarkeit und Integrität. Diese Angriffe gelten auch aus Supply-Chain-Angriffe und wurden für LLMs bereits erfolgreich demonstriert.
  • G 0.22 Manipulation von Informationen: Wie oben zum Schutzziel der Integrität bereits erläutert, ist die Qualität und Korrektheit von Trainingsdaten eine Grundvoraussetzung für die Zuverlässigkeit der LLMs. Gelingt es Angreifern diese in den Originalquellen oder auch im vorbereiteten Trainingsdatensatz zu manipulieren, kann dies zu falschen oder irreführenden Entscheidungen und Aussagen im Sinne der Angreifer führen. Unabhängig davon, ob es dadurch zu unerwünschten Unternehmensentscheidungen oder der Verbreitung von Desinformationen kommt, ist die Integrität entsprechend beeinträchtigt. Eine weitere konkrete Gefahr ergibt sich durch die Auslagerung des Trainings an externe Dienstleister. Diese können durch Manipulation der Trainingsdaten Hintertüren in den Modellen einschleusen, die sich nach aktuellem Stand nicht zuverlässig entdecken lassen.
  • G 0.28 Software-Schwachstellen oder -Fehler: Die Software-Projekte rund um LLMs sind in der Transitionsphase von Forschungsprojekten zu marktreifen Produkten. Der Drang möglichst schnell fertige Produkte anbieten zu können, führt häufig zu Entwicklungspraktiken, die nicht den Best Practices folgen und Schwachstellen verursachen. Die konkreten Auswirkungen sind abhängig von der Art der Schwachstelle. Gemessen an der potenziellen Angriffsoberfläche (interaktive Benutzereingaben, Verarbeitung von strukturierten und unstrukturierten Inhalten, komplexe Rollen- und Rechtekonzepte für die umliegenden Anwendungen usw.) sind von Informationslecks bis hin zur Übernahme der involvierten Systeme durch Angreifer alle Auswirkungen denkbar. Entsprechend sind auch alle Schutzziele – Vertraulichkeit, Verfügbarkeit und Integrität – betroffen.
  • G 0.29 Verstoß gegen Gesetze oder Regelungen: Zwar fällt der Bezug zu einem einzelnen Schutzziel schwer, jedoch ist die Bedrohung dafür nicht weniger relevant. Viele Aspekte rund um Datenschutz und Urheberrecht sind im Kontext von LLMs derzeit unklar. Einige Unternehmen handeln vorzeitig, in dem große Datenmengen gesammelt und zu Trainingszwecken verarbeitet werden, ohne die konkreten Quellen und etwaige Lizenzhinweise anzugeben bzw. zu beachten. Dies geschieht in der Hoffnung, durch Lobbyarbeit und starke Medienpräsenz ausstehende Gesetzgebungen oder rechtliche Entscheidungen zu beeinflussen. Eine Einstellung, die Meta (ehemals Facebook) in der Vergangenheit teuer zu stehen gekommen ist.

Auf der Basis solch relevanter Bedrohungen kann im Prinzip eine vollständige Risikoanalyse nach IT-Grundschutz durchgeführt werden, welche die Bedrohungslage beim Einsatz von LLMs oder KI-Modellen jeder Art erfasst. Die dafür benötigte Infrastruktur sollte dabei gleich mit betrachtet werden, unabhängig ob Cloud oder On-Premise. Es gilt dabei, sich bewusst Gedanken über das Einsatzumfeld und den Anwendungsfall zu machen. Mit dieser Informationsgrundlage gestaltet sich auch die Ableitung relevanter Sicherheitsmaßnahmen wesentlich einfacher und zielgerichteter.

Spezielle Schwachstellen von LLMs

Der zuvor beschriebene klassische und zum Teil recht abstrakte Ansatz kann mit konkreten Schwachstellenkategorien für LLMs ergänzt bzw. kombiniert werden. Das „Open Web Application Security Project“ (OWASP) stellt eine solche Auflistung von Schwachstellen bereits seit langer Zeit für Web-Applikationen in den OWASP Top 10 zusammen. Ein entsprechendes Pendant speziell für LLMs wurde zum 01.08.2023 veröffentlicht.

Die Top 10 umfassen dabei an erster Stelle Prompt Injections. Die namentliche Ähnlichkeit zur klassischen SQL Injection ist kein Zufall. Um LLMs, insbesondere im Rahmen von interaktiven Chats, daran zu hindern unerwünschte Inhalte von sich zu geben, werden der Benutzereingabe verschiedene Instruktionen vorangestellt. Prompt Injections zielen darauf ab, diese Instruktionen auszuhebeln. Besonders bekannt geworden ist dies bei der Veröffentlichung des Chatbots von Bing. Die Auswirkungen sind in einem lesenswerten Blogbeitrag von Simon Willison dargestellt.

Die konkreten Schwachstellen-Kategorien weisen dabei Ähnlichkeiten bzw. auch direkte Zusammenhänge auf, sowohl zu den OWASP Top 10 Schwachstellen von Web-Anwendungen, als auch zu den weiter oben aufgeführten elementaren Gefährdungen des IT-Grundschutzes. Grund dafür ist schlichtweg, dass LLMs von den gleichen Arten von Schwachstellen betroffen sind wie der Großteil aller informationsverarbeitenden Systeme. Die primären Unterschiede liegen in den konkreten Ausprägungen und entsprechend den zugehörigen Gegenmaßnahmen.

Übersicht der OWASP Top 10 für LLMs
  • LLM01 Prompt Injection: Mittels direkter oder indirekter Manipulation der Eingaben bzw. Prompts werden ungewollte Verhaltensweisen ausgelöst. Exemplarisch dafür ist die Ausgabe von beleidigenden, verleumderischen oder verbotenen Inhalte (Anleitungen zur Herstellung gefährlicher Stoffe o.ä.). Je nach Verwendungszweck der Ausgabe, beispielsweise zur Feststellung von Kreditwürdigkeiten, Auswertung von Anträgen und Verträgen oder anderen automatisierten Entscheidungen können die Konsequenzen entsprechend gravierend ausfallen.
  • LLM02 Insecure Output Handling: Die Ausgaben von LLMs können nicht nur Fließtext, sondern auch strukturierte Daten beinhalten. Werden diese ungefiltert übernommen, können in den nachgelagerten Systemen klassische Schwachstellen wie Cross-Site-Scripting (XSS) oder sogar Remote Code Execution (RCE) ausgelöst werden.
  • LLM03 Training Data Poisoning: Wenn die Trainingsdaten für ein LLM durch Angreifer manipuliert, sprich “vergiftet” werden können, sind ungewollte Verhaltensweisen und Ausgaben die Folge. Die Auswirkungen können ähnlich wie bei Prompt Injection ausfallen. Je nach Ausprägung können Angreifer auch bestimmte Schlüsselwörter in die Trainingsdaten einschleusen, wodurch nur bei Abfrage bestimmter Informationen voreingenommene und unethische Ergebnissen geliefert werden.
  • LLM04 Model Denial of Service: Dies ist das LLM-Gegenstück zu klassischen Denial-of-Service-Angriffen (DoS). Das Training aber auch die Inferenz (die Erzeugung von Ausgaben) sind zumindest aktuell noch sehr ressourcen- und damit kostenintensiv. Hinzu kommt, dass zwischen der Länge der Benutzereingabe und der Ausgabe keine direkte Relation besteht. Angreifer können dies nutzen, um hohe Kosten zu verursachen oder die vorhandenen Kapazitäten so auszulasten, dass eine normale Benutzung beeinträchtigt wird.
  • LLM05 Supply Chain Vulnerabilities: Um LLMs herum entwickelt sich ein umfangreiches und weit verzweigtes Ökosystem von Modellen, Datensätzen, Algorithmen, Ausführungsumgebungen und mehr. Werden die Bezugsquellen nicht geprüft oder sind nicht ohne weiteres überprüfbar, besteht die Gefahr, dass Angreifer in dieses Ökosystem schadhafte Inhalte einbringen, die unbemerkt übernommen werden und weite Verbreitung finden.
  • LLM06 Sensitive Information Disclosure: Durch unzureichend bereinigte Trainingsdaten sowie die Aggregation verschiedenster Datenquellen entsteht die Gefahr, dass vertrauliche Daten preisgegeben werden. Werden beispielsweise interne Code-Repositories und Dokumentationen zum Training genutzt, könnten API-Schlüssel und Zugangsdaten enthalten sein die über das Modell ungewollt abfragbar sind.
  • LLM07 Insecure Plugin Design: Um LLMs mit zusätzlichen Fähigkeiten auszustatten, werden Plugins verwendet. Diese ermöglichen die Suche im Internet, den Aufruf von Programmen bspw. zur Lösung mathematischer Gleichungen, die Interaktion mit APIs und vieles mehr. Die Idee ist, dass die LLMs selbst entscheiden, welche Werkzeuge für die gestellte Aufgabe genutzt werden. Sind die Zugriffsrechte sowie Ein- und Ausgabemöglichkeiten unsauber definiert bzw. abgegrenzt, bestehen indirekte Angriffsmöglichkeiten auf diese Plugins und die Daten, auf welche diese wiederum Zugriff haben. Des Weiteren besteht die Gefahr, dass Plugins auf externe Quellen zugreifen und bösartige Inhalte an das LLM zurückliefern. Werden diese Inhalte nicht genauso stringent geprüft und validiert wie andere Benutzereingaben, sind auch dadurch indirekte Angriffe möglich.
  • LLM08 Excessive Agency: Insbesondere bei der Nutzung von Plugins und anderen potenziell rekursiven Mechanismen – also LLMs die ihre Ausgaben wieder als Eingaben verwenden – müssen sinnvolle Einschränkungen definiert werden. Abhängig von konkreten Einsatzzwecken und Plugins können anderenfalls vielfältige Auswirkungen die Folge sein. Beispielsweise könnte ein LLM das mit APIs oder Datenbanken interagieren kann, zum unbefugten Anlegen, Ändern und Löschen von Daten verleitet werden.
  • LLM09 Overreliance: Werden LLMs übermäßig zur Entscheidungsfindung oder Erstellung von Inhalten genutzt, besteht die Gefahr darüber Falschinformationen zu verbreiten oder falsche Entscheidungen mit gravierenden Folgen zu treffen. Ein konkretes Beispiel ist die Nutzung bei der Software-Entwicklung. Wird der erzeugte Quelltext ungeprüft übernommen, besteht die Gefahr, dass unerkannte Schwachstellen in produktiv genutzten Anwendungen und Web-Applikationen einfließen. Pauschalisiert ausgedrückt: Die Korrektheit der Ergebnisse von LLMs kann nur von Menschen geprüft werden, welche die korrekten Ergebnisse auch selbst erzeugen könnten. Wer zu einem bestimmten Thema nichts weiß, kann Aussagen ohne externe Referenzen nicht validieren.
  • LLM10 Model Theft: Die eigentlichen Date, aus denen das Modell besteht, inklusive Konfigurationsparameter, beinhalten eine Repräsentation der Informationen mit denen es trainiert wurde. Für interne Zwecke auf Unternehmensdaten trainierte LLMs beinhalten demnach eine große Menge vertraulicher Daten. Gelingt es einem Angreifer das Modell zu entwenden, wird entsprechend auch die Vertraulichkeit der Trainingsdaten beeinträchtigt. Demnach muss der Zugriff auf die eigentlichen Modelle sowie die Trainingsdaten und deren Quellen mindestens genauso strikt geregelt werden.

Sicherheitsmaßnahmen

Die bisherigen Schritte liefern ein Fundament zur Ableitung von Sicherheitsmaßnahmen im Umgang mit LLMs. Die genauen Maßnahmen hängen von den konkret ermittelten Bedrohungen und der Ausprägung der Nutzung ab. Ist es “nur” ein SaaS-Dienst, in dem Trainingsdaten hochgeladen werden und im Anschluss eine abstrahierte Modell-Interaktion möglich ist? Wird ein fertiges Produkt On-Premise verwendet? Soll eine interne Informationsplattform oder gar ein kommerzielles Produkt entwickelt werden?

Auch hier gibt es hilfreiche Informationen, die zurate gezogen werden können. Bezogen auf den oben erwähnten IT-Grundschutz bietet das BSI mit dem IT-Grundschutz-Kompendium eine Sammlung von Bausteinen und Sicherheitsanforderungen für organisatorische Prozesse bis hin zu einzelnen Arten von IT-Systemen. Diese können zwar auf die zugrundliegenden Systeme, Infrastrukturen und Prozesse angewendet werden, haben jedoch nicht direkt etwas mit LLMs oder KI-Modellen zu tun.

Spezifischer hingegen ist das oben genannte OWASP-Projekt, welches auch die OWASP Top 10 für LLMs zusammengestellt hat. In einem weiterführenden Dokument werden neben detaillierten Informationen und Beispielen zu den Schwachstellen auch konkrete Gegenmaßnahmen aufgelistet.

Es ist zudem davon auszugehen, dass sich im Laufe der Zeit Muster und Best Practices herauskristallisieren, die es erlauben stärker und genauer auf Sicherheitsaspekte und -maßnahmen einzugehen, als dies aktuell noch möglich ist. Bis dahin erlauben die hier dargestellten Informationen und Grundlagen eine Möglichkeit, dennoch strukturiert und ganzheitlich die Informationssicherheit beim Einsatz von LLMs einzubeziehen.

Fazit

Wir hoffen die obigen Ausführungen vermitteln, dass trotz aller Entwicklungen und atemberaubender Schlagzeilen auch LLMs letztlich „nur“ informationsverarbeitende Systeme sind. Entsprechend gelten grundlegend die gleichen Bedrohungen, die wiederum mit bewährten und bekannten Methoden erfasst, bewertet und behandelt werden können. Gepaart mit der Betrachtung spezieller Schwachstellen ergeben sich Werkzeuge, mit denen sich proaktive Informationssicherheit und Security by Design-Prinzipien auf LLMs und Co anwenden lassen.

All dies soll nicht darüber hinwegtäuschen, dass KI-Technologien sich weiterhin und in absehbarer Zukunft stark weiterentwickeln werden. Entsprechend wird sich auch die Sicherheitslage wandeln, wie es für die gesamte IT-Branche seit jeher der Fall ist. Der Einsatz neuer Technologien ist nicht frei von Risiken. Diese sollten daher sorgsam bewertet und gemeinsam mit entsprechenden Sicherheitsmaßnahmen dem tatsächlichen Nutzen für den eigenen Anwendungsfall gegenüber gestellt werden.

Eines ist allerdings klar, es bleibt spannend!

KI betrügt Betrüger

In der letzten Woche wurde wieder ein spektakulärer Fall bekannt, bei dem Betrüger das sächsische Sozialministerium dazu brachten, 225.000€ an sie selbst zu überweisen. Solche Angriffe sind inzwischen eine Mischung aus technischen Attacken und geschicktem Social Engineering. Die technischen Anteile gehen über das Registrieren von Vertipper-Domains hinaus und reichen bis zur Übernahme von Nutzerkonten, die dann genutzt werden, um per Webmail-Frontend die Mails mitzulesen oder Weiterleitungen einzurichten.

Die „sozialen Tricks“ gehen heute auch über schlecht formulierte Mails hinaus: Betrüger interagieren längst persönlich per E-Mail und Telefon mit den Opfern. Viele sehen in den neuen, KI-basierten Chatbots die Gefahr, dass diese Angriffsvarianten einfacher und effektiver werden.

Eine Forschergruppe um Prof. Kaafar an der Macquarie University in Australien will den Spieß umdrehen und betrügerische Anrufe durch einen KI-basierten Sprachassistenten beantworten lassen. Ziel ist es, die Ressourcen der Betrüger zu blockieren und so im besten Fall deren Geschäftsmodell zu stören. Das Wettrennen zwischen Angreifern und Verteidigern geht also auch in diesem Bereich weiter.

https://www.mdr.de/nachrichten/sachsen/sozialministerium-internet-betrueger-phishing-100.html

https://lighthouse.mq.edu.au/article/june-2023/scamming-the-scammers (Pressemeldung der Macquarie University)

https://apate.ai/ (Projektwebseite)

HiSolutions Research

Wenn die KI mondsüchtig wird und Gespenster sieht

Eine spannende Diskussion wird gerade über die Zoom-Funktion in Samsung-Handys geführt. Mit der Handykamera gelingen nämlich seit einer Weile überraschend gute Bilder – besonders spektakulär sind dabei Bilder vom Mond. Vergrößert man die Bilder, lassen sich viele Details der Mondoberfläche erkennen. Die Diskussion entspann sich jetzt daran, ob das alles durch Verbesserungen an der Hardware und schlaue Optimierungsalgorithmen realisiert wurde, oder ob die Algorithmen es sich nicht etwas einfach machen und entsprechende Aufnahmen vom Mond passend einfügen. Wie immer, wenn es um die Vorzüge und Nachteile von IT-Marken geht, wird die Diskussion mit vehementem Eifer ausgetragen.

Vor kurzem hat der Reddituser „ibreakphotos“ die Diskussion mit einem Experiment noch einmal bereichert. Er hat ein vorhandenes Foto vom Mond genommen, es verpixelt, mit einem Weichzeichner versehen und anschließend erneut fotografiert. Das so entstandene Foto ist nicht perfekt, enthält aber Informationen, die de facto in der Vorlage nicht (mehr) enthalten waren. Die KI hatte bei ihrer Bildoptimierung also vermutlich zumindest eine korrekte Mond-Textur im Hinterkopf bei der Bildoptimierung.

Benchmark-relevante Funktionen zu schönen hat eine sehr lange Historie. Vielleicht erinnern Sie sich an die Grafikkartenhersteller Anfang der 2000er, die Spiele-Benchmarks erkannt und anders ausgeführt haben – oder an neuere Fälle bei Herstellern von Mobiltelefonchips und Fernsehern in den letzten Jahren.

Spiele und Mond-Bilder – wo ist da der Bezug zur Büro-IT? Dafür gehen wir auch wieder an den Karteikasten mit historischen News: Vor genau 10 Jahre machte eine vermeintlich schlaue Bildoptimierung in Xerox-Scankopierern Furore, da sie gelegentlich Zahlen vertauschte. Alles begann mit einer Bauzeichnung, in der die Quadratmeterangaben vertauscht waren. David Kriesel deckte damals auf, dass das Problem auch in vielen anderen Fällen auftrat, z. B. bei Tabellen mit Zahlen.

Ursprünglicher Reddit-Post zur Samsung-Kamera: https://www.reddit.com/r/Android/comments/11nzrb0/samsung_space_zoom_moon_shots_are_fake_and_here/

Ergänzung mit weiteren Versuchen: https://www.reddit.com/r/Android/comments/11p7rqy/update_to_the_samsung_space_zoom_moon_shots_are/

Andere Fälle mit geschönten Benchmarks:

https://www.theregister.com/2003/05/27/ati_admits_it_optimised_drivers/

https://www.anandtech.com/show/15703/mobile-benchmark-cheating-mediatek

https://entertainment.slashdot.org/story/22/06/15/0615211/samsung-caught-cheating-in-tv-benchmarks

10 Jahre alter Xerox-Fall: https://www.dkriesel.com/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning

HiSolutions Research

Vom Berater bis zum Angreifer: Computer übernehmen die Jobs

Ende November gab die Firma OpenAI den Prototypen ihres Chatbots ChatGPT zum Ausprobieren durch die Community frei und die nutzte die Adventszeit für viele spannende und teils erschreckende Experimente. Was ist ChatGPT eigentlich? Tatsächlich, wie der Name sagt, ein Chatbot, den man mit Fragen zu recht komplexen Antworten bringen kann. Wie in einem Fachgespräch üblich, kann man ihn durch weitere Fragen oder Änderungswünsche die Antworten ergänzen und verbessern lassen. Der Chatbot kann nicht nur Texte schreiben, sondern auch einfache Programme entwickeln.

Vorsicht ist jedoch angesagt, damit der Bot seine Ergebnisse nicht zu sehr nach den vermeintlichen Wünschen des Fragestellers ausrichtet. Bei Tests mit typischen Beratungsfragen, also den Fragen, die ohne Kontext immer mit „Es kommt darauf an“ beantwortet werden, konnte ChatPGT sehr überzeugend beide Sichten begründen – allerdings ohne auf die jeweils andere Option einzugehen. Fragt man beispielsweise, wie mit schwachen SSL-Cipher-Einstellungen umgegangen werden soll, bekommt man je nach Fragestellung diese Antworten:

Für die Einordnung der Ergebnisse der künstlichen Intelligenz ist dann doch wieder Fachwissen nötig.

ChatGPT kann aus einer kurzen Beschreibung heraus auch ein passendes Programm entwickeln. Das interessiert natürlich auch potenzielle Malware-Autoren. Die Kollegen von Check-Point haben in Foren erste Hinweise in Foren gefunden, dass mit Malware aus ChatGPT-generiertem Code experimentiert wurde. Ob sich das Entwicklungsmodell bei den Malware-Autoren durchsetzt oder diese Malware am Ende sogar leichter erkennbar sind, wird die Zukunft zeigen.

https://www.heise.de/news/ChatGPT-Maechtige-Waffe-in-Haenden-von-Skriptkiddies-7452741.html

HiSolutions Research

Ganz normale Landstraße: Normungsroadmap KI veröffentlicht

Beim DIN wurde die „Normungsroadmap KI“ veröffentlicht. Um ein einheitliches Vorgehen beim Thema IT-Sicherheit von KI-Anwendungen zu ermöglichen, soll eine übergreifende „Umbrella-Norm“ („Horizontale KI-Basis-Sicherheitsnorm“) entwickelt werden, die vorhandene Normen und Prüfverfahren bündelt und um KI-Aspekte ergänzt sowie durch Sub-Normen zu weiteren Themen ergänzt werden kann. Außerdem sollen eine praxisgerechte initiale Kritikalitätsprüfung von KI-Systemen ausgestaltet und ein nationales Umsetzungsprogramm „Trusted AI“ zur Ertüchtigung der europäischen Qualitätsinfrastruktur initiiert werden.

https://www.din.de/de/forschung-und-innovation/themen/kuenstliche-intelligenz/normungsroadmap-ki

HiSolutions Research

Lesetipps Oktober 2020

#FOMO vs. #YOLO

Die Security-Ökonomie-Psychologie-Philosophin Kelly Shortridge hat in einem langen Blogartikel ihr Konzept der #YOLOsec (Black Hat 2017) um das Konzept der #FOMOsec ergänzt. Während You Only Live Once einen zu großen, häufig gar unbewussten Risikoappetit beschreibt, bezeichnet Fear Of Missing Out den Impuls, nur ja nichts falsch machen zu wollen und letztlich alle Controls umzusetzen, die eine Risikominimierung bringen *könnten*, ohne zu hinterfragen, ob so die Geschäftsziele nicht vielleicht sogar behindert werden.

https://swagitda.com/blog/posts/on-yolosec-and-fomosec


KI nder…

Produktmanager und Filmemacher Eugene Wei analysiert, wie TikTok als erste chinesische App überhaupt den amerikanischen Markt “knacken” konnte – und erzeugt dabei tiefe Einsichten in die Wirkungsweise und Macht von KI.

https://www.eugenewei.com/blog/2020/8/3/tiktok-and-the-sorting-hat


Ältern!

Der witzige Cloud-Sparfuchs Corey Quinn hat seinen bekannten wöchentlichen Newsletter “Last Week In AWS” genutzt, seine Gedanken zur Elternzeit als Mann, Gründer und Manager in der IT-Branche zu teilen. Auch wenn die US-Perspektive hier noch etwas anders ist als die deutsche und europäische: Wertvoll!


I see ass…toundingly clear

Die Cyber-Edel-Bildungsfabrik SANS beschäftigt sich zunehmend mit dem Thema Industrial Security. Ein wertvolles Nebenprodukt davon ist diese wunderschön anschauliche Zusammenfassung der Geschichte von ICS(-Security).

https://ics.sans.org/media/An-Abbreviated-History-of-Automation-and-ICS-Cybersecurity.pdf


Bei S ist Stop

Diese Grafik stellt alle 50(!) bekannten kognitiven Biases dar, die uns in der Security und anderswo am rationalen Denken hindern.

https://storage.googleapis.com/titlemax-media/099372db-50-cognitive-biases-2_80per.png