Machine Learning Security

Simon:

Willkommen beim INNOQ Security Podcast. Ich sitze hier mit der Isabel. Isabel ist bei uns Werksstudentin für den Studiengang Data Engineering beim Hasso-Plattner-Institut. Und… Hallo Isabel!

Isabel:

Hallo!

Simon:

Du hast mit so Dingen wie KI und Machine Learning und Deep Learning und was es da sonst noch so alles gibt zu tun. Und in dem Bereich gibt es auch Security-relevante Themen. Ich bin in der schönen Position, ich muss nicht so tun als ob ich das Thema nicht wüsste und mir dann… nicht näher kennen würde und mir irgendwie schlaue Fragen ausdenken, sondern ich habe tatsächlich wenige Berührungspunkte bisher mit Machine Learning oder ähnlichen gehabt. Wollen wir mal die Begriffe kurz einordnen bevor wir irgendwie zu den Security-relevanten Teilen da rangehen?

Isabel:

Genau! Erstmal vielen Dank für die Vorstellung Simon! Und genau… ich halte es auch auf jeden Fall für sinnvoll da mal kurz eine Einführung zu geben, was ist eigentlich Machine Learning? Was ist eigentlich Deep Learning? Und wie hängt das alles irgendwie mit KI zusammen? Weil die Begriffe werden ja doch immer relativ verwandt gebraucht und für der Laien ist das vielleicht gar nicht so einfach das auseinanderzuhalten. Und so ein grundlegendes Verständnis ist schon wichtig, wenn wir uns dann nachher auch die verschiedenen Machine Learning Security Risiken angucken. Also ich würde vielleicht einfach mal mit Machine Learning anfangen. Machine Learning ist eine Teilmenge der künstlichen Intelligenz, man kann sagen das ist eine Technik zur Realisierung von KI. Machine Learning ist eine Methode Algorithmen mit Hilfe der Daten so zu trainieren, dass die ein Mapping von Input nach Output ableiten. Ja, das klingt jetzt erstmal noch so ein bisschen abstrakt, deswegen habe ich mir so ein ‚reales Welt‘-Beispiel überlegt. Und zwar die Sentiment Analyse. Also Simon, die Sentiment Analyse ist eine Klassifikationsaufgabe, wo es darum geht Text hinsichtlich des Sentiments zu klassifizieren. Also in positiv, negativ, vielleicht auch in neutral. Was hat das jetzt mit dem Mapping von Input nach Output zu tun, dass Algorithmen mit Hilfe der Daten lernen sollen? Also im Beispiel der Sentiment Analyse wäre es dann so, dass unsere Textdaten, beispielsweise Tweets aus Twitter, unsere Input Daten werden und für jedes Input Datum hätte man dann einen zugehöriges Label. Also einen Output, wie beispielsweise positiv, negativ oder neutral. Dieses Input, also der Tweet, zusammen mit dem Label, den Output, wäre dann ein sogenannter gelabelter Trainingsdatensatz mit dem wir auch unseren Algorithmus trainieren würden.

Simon:

Ah, das ist so ein bisschen so wie eine Art Aufgabe und die Lösung dazu. Weil wir schon wissen für den Trainingsdatensatz, ob wir den als gut, neutral, negativ, wie auch immer wir das Sentiment beschreiben wollen, einordnen wollen. Und natürlich wäre die Definition von dem Sentiment oder Gefühl oder was auch immer, ein Stück weit ist es ja auch davon abhängig was wir dafür halten. Also der Algorithmus selbst hat da ja keine Meinung zu, ob was gut ist oder schlecht ist. Und das heißt wir brauchen erstmal eine gewisse Menge an Datensätzen, die von uns schonmal vorher gelabelt wurden.

Isabel:

Genau. Wir müssen uns natürlich das Label überlegen, was macht ein Tweet zu einem positiven Sentiment oder wann transportiert ein Tweet ein negatives Sentiment? Also gegeben ist quasi das Input und der Output, den wir dazu festgelegt haben.

Simon:

Hast du da ein Gefühl wie viele Tweets man denn bräuchte, um bei dem Beispiel zu bleiben, Pi mal Daumen? Reichen mir da schon hundert? Brauche ich da hunderttausend, die ich schon alle mal irgendwann vorgelabelt habe?

Isabel:

Also natürlich ist es so: Je mehr Daten, desto besser. Also je mehr Beispiele der Algorithmus zur Verfügung gestellt bekommt, um eben dieses Mapping von Input nach Output zu lernen, um dieses, wie du gesagt hast, dieses Rätsel auch zu lösen, ist natürlich besser je mehr Daten man hat. Das kann man auch so pauschal gar nicht sagen, das kommt natürlich auch darauf an, ja, welche… also wollen wir positiv, negativ, vielleicht auch neutral? Also drei Klassen ausgeben? Wie gut ist die Datenqualität? Aber wir brauchen deutlich weniger Daten als ein neuronales Netzwerk braucht, da kommen wir später noch dazu.

Simon:

Okay.

Isabel:

Genau. Es gibt für Machine Learning ‚supervised‘ und ‚unsupervised‘ Learning. Letzteres würde ich erstmal außen vorlassen, weil ich glaube das sprengt so ein bisschen den Rahmen. Ich würde jetzt mal bei supervised bleiben, denn diese Sentiment-Aufgabe ist tatsächlich auch eine supervised Learning Aufgabe.

Simon:

Also supervised bedeutet ich trainiere aktiv das Netz und unsupervised vielleicht in so ein-zwo Sätzen? Nur damit man es einsortieren kann.

Isabel:

Also beim supervised hast du die Labels dazu, bei unsupervised hast du keine Labels. Also ein Beispiel für unsupervised wäre die sogenannte ‚topic detection‘, dass die auch einen Textfokus haben, also Textdaten und da würde uns einfach mal interessieren, welche Topics… also, sind denn in diesen Text vertreten? Das wäre ja…

Simon:

So eine klassische Tech Cloud, wie man sie vielleicht kennt.

Isabel:

Ja, so ein Clustering, genau! So in der Art.

Simon:

Nur dass ich eben die vorher nicht kenne, sondern aus meinen Text gerne dann als Ergebnis hätte. Okay, gut!

Isabel:

Genau!

Simon:

Aber wir kümmern uns um supervised jetzt erstmal in dem Beispiel.

Isabel:

Genau, weil da kann man ganz gut erklären wie Machine Learning funktioniert. Supervised deswegen, weil wir eben die Labels vorgeben. Also es ist überwachtes Lernen. Ich würde jetzt trotzdem einmal kurz die Sentiment Analyse verlassen, wenn es für dich okay ist Simon?

Simon:

Ja, klar!

Isabel:

Und vielleicht nochmal ein neues Beispiel aufgreifen. Und zwar das Beispiel ‚Obst‘. Das ist jetzt ein sehr simples Beispiel, aber vielleicht auch ganz gut geeignet, um die Funktionsweise zu erklären. Also unser Ziel ist jetzt, wir würden gerne Obst klassifizieren. Und zwar in Apfel, Bananen, Mango, was auch immer. Jetzt ist die Frage, wie sehen da unsere Trainingsdaten zu aus? Obst kann man ja beschreiben zum Beispiel mit Gewicht oder mit Farbe, mit diesen Merkmalen. Hier nochmal der Hinweis: Machine Learning kann nicht einfach Bilder verarbeiten, das können neuronale Netze. Aber Machine Learning Algorithmen arbeiten mit strukturierten Daten. Also hier sind wir tatsächlich darauf angewiesen eben Obst mit diesen Attributen zu beschreiben wie Gewicht und Farbe. Wie sehen jetzt diese Trainingsdaten aus? Also das sind quasi… Trainingsdaten bestehen aus einer Matrix von Zeilen und Spalten und jede Zeile in der Matrix wäre dann eben eine Beobachtung oder ein Datenpunkt. Die Spalten wiederum sind die Features, also die Merkmale mit denen wir die Datensätze beschreiben. In unserem Fall wären das zum Beispiel Gewicht und Farbe. Und daneben hätte man dann das Label, zum Beispiel Apfel, Bananen. Ein Beispiel Simon: Wir hätten jetzt Gewicht von 500 Gram, Farbe rot und dann wäre dann das Label ‚Apfel‘ daneben. Und damit könnte man dann eben die Zielklasse ‚Apfel‘ beschreiben.

Simon:

Das heißt, wenn wir das ganz simpel runterbrechen: Wir haben ganz viele Inputdaten. Die haben wir schonmal vorklassifiziert, weil wir müssen ja die Features selbst erstmal initial zum Trainieren von dem Netz halt eben nutzen. Da haben wir vielleicht ganz, ganz viele Daten und alle unsere Äpfel sind rot. Und wenn wir dann plötzlich da Obst mit bei haben, was die Farbe gelb hat und das eine Banane ist, dann wäre das so ein total vereinfachtes Beispiel, die Möglichkeit für das Netz halt anhand der Farbe zu erkennen von dem Feature, dass das halt eben kein Apfel ist, sondern eine Banane als Ausgabe. Nur mit dem Unterschied, dass das natürlich bei einer Farbe vielleicht so ein bisschen offensichtlicher ist. Aber eben wenn man da immer mehr Charakteristika da mit dazu nimmt, dass ich dann den Vorteil habe, dass ich die Charakteristika nicht mehr beschreiben muss, die zu dem Ergebnis führen. Sondern ich habe einen große Menge an Input Daten und da schreibe ich halt ein Label an und dann trainiere ich das Netz damit und bekomme das dann als Ergebnis.

Isabel:

Genau! Vorsicht, nicht das Netz, sondern Algorithmus. Das Netz ist dann ja für Deep Learning. Also das Machine Learning Modell. Wir…

Simon:

Wenn wir von Machine Learning reden, reden wir von einem Algorithmus, der halt eben strukturierte Daten verarbeitet. Immer dann, wenn wir von sowas wie einem neuronalen Netz oder ähnlichen sprechen, dann befinden wir uns irgendwie bei Deep Learning.

Isabel:

Genau! Genau. Also die Idee ist eben, wir geben Input Daten mit verschiedenen Merkmalen, also Features, und das Label dazu. Mit Hilfe dieser Features und dem Label kann der Algorithmus quasi lernen ein Mapping von diesen Input-Datum bis zum Output-Datum herzustellen. Und wichtig eben beim Machine Learning ist eben, wir müssen selber überlegen: Was macht jetzt unser Obst eigentlich aus? Was macht einen Apfel aus? Also wir müssen Feature-Engineering betreiben. Feature- Engineering sind Prozesse, die man braucht, um Rohdaten so auszuarbeiten, dass sie auch direkt von Machine Learning Algorithmen verarbeitet werden können. Also die Idee ist, dass man da eben relevante Tribute mitliefert. Bei Deep Learning, da komme ich auch gleich nochmal dazu, da können wir uns das sparen. Also da würde das Netz selber rausfinden, was einen Apfel eigentlich ausmacht. Da müssen wir gar nicht dieses Feature-Engineering betreiben. Und dieses Feature-Engineering in dem Beispiel ist natürlich noch recht simpel, aber man kann sich ja auch vorstellen, je nach Machine Learning Task ist das sehr Domain-spezifisch. Und man muss auch aufpassen, dass man nicht zu viele Features bereitstellt. Also man würde das Modell dann quasi overfitten, also das würde dann zwar super irgendwie auf den Testdaten, den Trainingsdaten funktionieren, aber vielleicht wäre es danach nicht mehr so gut in der Lage zu verallgemeinern. Also man braucht da schon den richtigen sweet spot und die richtige Menge an bereitgestellten Featuren. Aber das ist vielleicht gar nicht mehr so der Hauptpunkt auf den ich jetzt eingehen möchte. Wichtig ist nur einfach für dich Simon, dass beim Machine Learning, die arbeiten mit strukturierten Daten und wir müssen eben diesen Datenvorverarbeitungsprozess, dieses Feature-Engineering selber betreiben.

Simon:

Genau. Das heißt wir machen dann da dieses entsprechende Feature-Engineering, damit dann der Algorithmus auch tatsächlich zu einem sinnvollen Ergebnis kommt.

Isabel:

Genau und wir würden jetzt da weiter vorgehen mit diesem gelabelten Datensatz. Und den würden wir jetzt nochmal aufteilen in Trainingsdaten und Testdaten. Diese Testdaten würden wir erstmal komplett wegschieben und gar nicht weiter anrühren. Mit denen wollen wir später nämlich dann unser Machine Learning Modell eben evaluieren, um zu gucken, wie gut es auch auf neuen Daten performt. Und der Witz ist eben, dieses Mapping von Input nach Output, das soll ja generalisieren. Also wir geben das einmal vor für unser Trainingsbeispiel, aber wenn der Algorithmus dann eben Beschreibung bekommt von Obstsorten, soll er selber sagen können: Okay, Apfel, Banane, Mango. Genau.

Simon:

Wir können aber… Genau. Wir können an der Stelle dann halt aber natürlich nur das finden, was wir vorher trainiert haben, ja?

Isabel:

Was genau meinst du?

Simon:

Ja, klar. Ich kann natürlich nicht magisch irgendwie neue Obstsorten finden, aber wenn ich mein Netz nur mit Äpfeln und Bananen trainiert habe und plötzlich ist der Input später mal sowas wie eine Mango, dann wir der Algorithmus nicht sagen ‚das ist ein völlig neues Objekt‘, sondern er wird versuchen das in die zwei Kategorien, mit denen ich ihn vorher trainiert habe, einzusortieren.

Isabel:

Genau. Also nochmal: Nicht das Netz, sondern das Modell natürlich. Also das Modell lernt mit den Daten. Also das ist klar. Also was in den Daten nicht drin ist, das kann auch nicht gelernt werden.

Simon:

Und am Anfang habe ich… splitte ich da einfach in zwei Teile, ich lege einen Teil von meinen Input als Testdaten auf die Seiten, wenn ich das Modell validieren möchte und mit den anderen Teil mache ich eine entsprechende… mache ich Feature-Engineering, um dann Labels dranzubekommen.

Isabel:

Ne, also in diesem Trainingsdatenteil trainiere ich dann eben den Algorithmus und in diesem Trainingsprozess muss der Algorithmus zwei Parameter lernen: Einmal Gewichte für die Input-Werte und ein Bias Term. Das Ziel ist es eben diese genannten Parameter so zu optimieren, dass die Vorhersage des Algorithmus sich möglichst wenig von der tatsächlichen Vorhersage, die wir auch kennen, unterscheidet. Also es würde so ablaufen: Wir trainieren das Modell mit den Trainingsdatensatz, dann sind wir mit dem Training fertig und denken: ‚Okay, Modell hat die Parameter A und B gut gelernt. Jetzt gucken wir uns doch mal an, wie gut funktioniert das jetzt auf den reservierten Testdatensatz?‘ Das sind die Daten, die der Algorithmus noch nicht gesehen hat und vergleichen da quasi die Predictions des Algorithmus mit dem Label, das wir als richtig kennen. Und gucken uns dann eben an, wie ist die Differenz zwischen diesen Machine Learning Ausgabewerten? Also zwischen der Ausgabe des Algorithmus und der tatsächlichen Ausgabe. Und das Ziel ist es eben das zu minimieren durch die optimale Wahl der Parameter W und B. Also im Detail sind diese Parameter gar nicht so wichtig, was die genau machen, weil hier geht es nur darum eben: Im Trainingsprozess wäre der Algorithmus der Parameter so, um eben die Verlustfunktion, also die Differenz zwischen getroffener Vorhersage und tatsächlicher Vorhersage, zu minimieren.

Simon:

Okay. So, das heißt die Abgrenzung zum Deep Learning wäre an der Stelle, dass man beim Deep Learning die Features jetzt nicht hat, richtig?

Isabel:

Also du musst die Features zumindest nicht selbst bereitstellen. Also diese Muster werden selbstständig in den Daten erkannt vom neuronalen Netz und ein weiterer wichtiger Unterschied: Deep Learning kann mit umstrukturierten Daten umgehen. Also da könntest du auch direkt eben Bilder-Pixelwerte geben, Textdaten auch unstrukturiert geben. Das ist nochmal der Unterschied zu Machine Learning. Also dann würde, wenn wir jetzt beim Obst-Beispiel bleiben wollten, dann müsste man nicht eine beschreibende Tabelle quasi geben, sondern man würde einfach Bilder von verschiedenen Obstsorten mit dem Label der Obstsorte versehen. Also eben tausende Bilder von Äpfeln in allen möglichen Lebenslagen. Von oben, von unten mit dem Label ‚Apfel‘. Und würde diese Pixel dann dem Netzwerk übergeben. Also man könnte sich dann auch sparen dieses Feature-Engineering zu betreiben. Man müsste sich jetzt nicht erst überlegen: Was macht einen Apfel aus? Das würde das Netzwerk dann selber erkennen.

Simon:

Okay und welche von den Varianten ich benutze hängt dann wahrscheinlich am Ende einfach davon ab, wie meine Datenbasis aussieht. Was ich da an Problemen lösen muss. Das heißt, wenn ich unstrukturierte Daten habe, lande ich wahrscheinlich irgendwann eher bei Deep Learning. Mit strukturierten Daten, wenn ich die manuell trainieren kann, den Algorithmus in dem Moment, dann lande ich halt eben bei supervised oder unsupervised Machine Learning, ja?

Isabel:

Also Datenbeschaffenheit ist das eine, die Struktur der Daten, aber wichtig ist eben auch, Deep Learning Modelle, die funktionieren nur mit sehr, sehr vielen Daten gut. Also tatsächlich… Deep Learning hatte eigentlich so die Geburtsstunde eigentlich auch erst mit den Aufkommen von großen, großen Big Data Datenmengen und Verfügbarkeit von auch enormen Rechenressourcen. Da halt eben sehr, sehr viele Daten benötigt werden um diese Deep Learning neuronalen Netzwerke zu trainieren. Das heißt, wenn man wenige Daten zu Verfügung hat, dann würde man wahrscheinlich mit dem Machine Learning Approach auch besser fahren. Es kommt natürlich auch immer auf den Use Case an. Natürlich sind diese neuronalen Netze sehr leistungsstark, es gibt aber vielleicht auch Aufgaben, wo das gar nicht so nötig ist. Also wenn man ein einfaches Sergisationsproblem auch hat, ist halt die Frage, ob es eben auch so ein Machine Learning Modell auch tut. Was man auch nicht vergessen darf, dieses einfache Machine Learning ist das Machine Learning Modell, aber Machine Learning Modelle sind besser interpretierbar. In diesen neuronalen Netzen, ich kann auch gleich nochmal kurz erklären, zumindest grob, wie so eine Netzwerkstruktur auch aussieht, sind diese Entscheidungen nicht nachvollziehbar. Also wir wissen auch gar nicht, warum die gelernten Parameter auch sind wie sie sind. Also diese Entscheidungsfindung wird eben so automatisiert, dass der Mensch mitunter auch nicht mehr verstehen kann, warum diese Entscheidung so getroffen wurde. Das heißt dieser Interpretierbarkeits-Aspekt wiegt natürlich auch nochmal mit rein. Je komplizierter das neuronale Netz, je komplizierter überhaupt das System, was das benutzt, desto schwerer ist das interpretierbar. Und diese Interpretierbarkeit ist auch immer eine Frage, ob das auch wichtig wird. Gerade im Hinblick jetzt auch auf Fairness im System, also warum kommt der Algorithmus zu einer Entscheidung? Unter Umständen muss man es einfach auch erklären können und das ist so das Ding mit diesem Deep Learning System, dass da Interpretierbarkeit einfach schwer ist.

Simon:

Ja, ist gibt ja immer mal wieder diese Probleme mit Rassismus mit einer KI an der Stelle. Das dann einfach, je nachdem wie die Hautfarbe dann vielleicht in einem Foto entsprechend interpretiert wird, da ganz unterschiedliche Ergebnisse rauskommen und wo wir so eine starke Abhängigkeit haben zu den Trainingsdaten, die man da reingepackt hat. Aber dann im Zweifel gar nicht so genau nachvollziehen kann, warum da Entscheidungen getroffen werden.

Isabel:

Also das ist nochmal ein anderes Problem, was du da tatsächlich ansprichst. Also ich nehme an, du spielst ein bisschen ein bisschen auf diese Face Recognition, diese Gender Shades Studie an vor ein paar Jahren auch, die für viel Wirbel gesorgt hat. Also auch die Hörer, die vielleicht mit der Studie nicht vertraut sind, da war es so, dass eben US-Forscher rausgefunden haben, dass die Face Recognition Systeme großer Anbieter, wie Amazon oder IBM, schlechter für Frauen funktionieren. Also quasi Fotos von Frauen schlechter klassifizieren können und obendrein, dass sie am allerschlechtesten performen für Frauen mit dunklerer Hautfarbe. Wenn man natürlich bedenkt in welchen Kontext diese Face Recognition Systeme auch eingesetzt werden, ja auch durchaus im polizeilichen Kontexten, dann hat das natürlich auch für Wellen geschlagen. Ja, aber das ist nochmal ein anderes Thema und da ist das Problem, dass der Trainingsdatensatz nicht ausgewogen genug ist. Also da ist dann schon klar, warum eben die, sage ich mal die Performance oder Currency divergiert zwischen den verschiedenen, ja, minority groups. Eben weil der Algorithmus auch einfach nicht genug Beispiele gesehen hat. Also IBM zum Beispiel hat dann auch tatsächlich versucht den Trainingsdatensatz diverser zu machen, indem man sich auch mit Dermatologen zusammengeschlossen hat und überlegt hat: Wie können wir da eben bessere, diversere Trainingsdaten zur Verfügung stellen, dass der Algorithmus auch besser lernt eben feingranularer zu entscheiden? Und wir sind ja nun mal eine diverse Gesellschaft, da ist da auch notwendig. Aber das ist nochmal ein anderes Thema. Ich glaube, ich könnte da drüber auch nochmal einen ganzen Podcast an sich halten, aber ich glaube… Das sind natürlich auch Themen, also gerade Responsibilty, die genauso in Machine Learning Security natürlich rundherum um Machine Learning Deployment entstehen. Und ja, das ist auf jeden Fall auch ein spannendes Thema, aber ich glaube ich muss dich ein bisschen so zurückführen zu unseren Deep Learning. Ich weiß nicht, soll ich nochmal kurz erklären, wie so ein neuronales Netzwerk aussieht? Oder ist das schon so ein bisschen zu technisch?

Simon:

Lass es uns kurz versuchen und wenn wir am Ende in der Mathevorlesung sind, werde ich dich ganz einfach unterbrechen.

Isabel:

Ich gebe mir Mühe. Ich muss natürlich einen guten Ausgleich finden zwischen so ein bisschen zu erklären und nicht zu sehr in die Tiefe zu gehen. Aber ich glaube jeden Zuhörer ist natürlich auch klar, dass man in so einem Podcast auch keine hundertprozentig tiefe Einführung geben kann.

Simon:

Genau! Zumal… eigentlich kommen wir ja noch zu Security Themen und es geht ja nur ein bisschen drum, um Kontext zu finden in dem wir uns bewegen.

Isabel:

Genau!

Simon:

Okay! Neuronales Netz beim Deep Learning.

Isabel:

Genau. Also ist eine Teilmenge von Machine Learning, ist grob inspiriert auch von diesen Informationsverarbeitungsmustern im menschlichen Gehirn. Ein neuronales Netz besteht aus einer Eingabeschicht und einer Ausgabeschicht. Und diese Eingabeschicht und Ausgabeschicht nochmal durch mehrere hidden layers, also durch sogenannte versteckte Schichten miteinander verbunden. Diese Eingabeschichten, die nehmen numerische Repräsentationen von Daten auf, also zum Beispiel Bilder in Form von einer Pixelspezifikation und die Ausgabeschicht gibt uns dann eben die finale Prediction. Jetzt ist immer die Frage, also wie fließt denn jetzt die Information durch die verschiedenen Schichten? Also wir fangen mit der Eingabeschicht an, aber wie kommen wir dann auch am Ende zum Ergebnis in der Ausgabeschicht? Also grob, jede Layer, jede Schicht hat eine Aktivierungsfunktion und die erzeugt eine Ausgabe, die in die nächste Schicht geht. Und wenn wir in der letzten Schicht angekommen sind, in der Ausgabeschicht, erzeugt die die endgültige Vorhersage. Wichtig dabei: Für jede Schicht werden die Parameter neu angepasst und wenn wir in der Ausgabeschicht angekommen sind, gucken wir uns eben wieder die Prediction an und schauen uns ähnlich wie bei dem Obst-Beispiel vorher an, wie weit unterscheiden wir uns denn tatsächlich von den eigentlichen Label. Und dann findet was statt, was man ‚backwards propagation‘ nennt, da geht man rückwärts nochmal durchs Netzwerk und passt die Parameter W und B eben so an, dass man erneut diesen Verlust, diese Differenz zwischen predicted Output und tatsächlichen Output minimiert. Das mal ganz knapp und kurz zusammengefasst, ich hoffe das war nicht zu mathematisch und trotzdem verständlich.

Simon:

Okay. Wir haben da ein Netz aus unterschiedlichen Schichten und die kennen wir vorher nicht, die entstehen anhand von den Daten, die wir reinpacken. Und eigentlich laufen wir am Ende dann dieses Netzwerk rückwärts durch, um mal so einen initialen Trainingsstand zu erreichen im Sinne von: Die Ergebnisse tweaken in die Richtung, das soll uns eine Antwort auf unsere Fragestellung geben.

Isabel:

Genau. Jetzt haben wir so einen kleinen Einblick jetzt auch bekommen denke ich, wie Deep Learning funktioniert, wie Machine Learning funktioniert und wie man das auch abgrenzen kann. Also nochmal zusammengefasst: Machine Learning sind strukturierte Daten, Deep Learning sind unstrukturierte Daten, bei Machine Learning muss man selber dieses Feature-Engineering betreiben, bei Deep Learning übernimmt das das Netz und in beiden Fällen geht es halt eben darum diese Parameter W und B so zu optimieren, dass wir die Verlustfunktion, die Differenz zwischen den predicteten Output und den tatsächlichen Output minimieren. Ja Simon, ist das verständlich gewesen so?

Simon:

Ja, ich glaube schon. Wir kommen so ein bisschen zu dem Punkt, wenn wir uns Security angucken, dann ist das häufig sowas wie: Von außen haben wir halt ein System, das hat ein Interface. Da habe ich vielleicht die Möglichkeit einen offenen Port zu finden oder in meiner API ist die Autorisierung nicht richtig implementiert und jemand kann irgendwie Daten rausleiten oder ähnliches. Das was du gerade beschrieben hast, das sind eigentlich sehr komplexe Systeme und in jedem komplexen System habe ich eine Möglichkeit… wahrscheinlich, das ganze auf einer Prozessebene anzugreifen. Also völlig egal, wie die technische Implementierung aussieht, wenn der Passwort Reset Prozess auf einer fachlichen Ebene schon irgendwie eine Lücke hat, es reicht zum Beispiel aus irgendwo eine Telefonnummer anzurufen, um sein Passwort zurückzusetzen, dann habe ich das System ja quasi auf einer prozessualen oder funktionalen Ebene angegriffen. Also es ist völlig egal, wie ich denn meine Information technisch nach Außen gebe. Mit dem Machine Learning haben wir dann auch wieder plötzlich sehr komplexe Systeme und wahrscheinlich ist die Antwort jetzt ‚ja‘, wenn ich dich danach frage, sonst würden wir den Podcast nicht aufnehmen, aber muss ich mich da um Security kümmern, wenn ich Machine Learning an der Stelle einsetze? Oder ist das eigentlich völlig egal an Stelle, weil niemand die Möglichkeit hätte irgendwie Daten oder Modelle zu manipulieren?

Isabel:

Also erstmal: Klar, du musst dich um Security kümmern. Das ist so die eine Nachricht. Ich komme gleich auch dazu warum. Und die schlechte Nachricht ist auch, dass man den Erfahrungsschatz, den man vielleicht durch, ich sage mal traditionelle Cyber Security hat auch nicht eins zu eins jetzt auf Machine Learning Security anwenden kann, einfach weil wir da nochmal eben auf Grund der Komplexität der Systeme anderen Herausforderungen gegenüberstehen. Das wird aber glaube ich im Talk jetzt auch ein bisschen klarer, warum das so ist. Also vielleicht mal ganz allgemein, so im Gegensatz zu herkömmlichen klassischen Cyber Security Schwachstellen, die ja denke ich auch oft an bestimmte Software und Hardware Systeme gebunden sind, sind diese Machine Learning Schwachstellen eher durch inhärente Einschränkungen, die den Machine Learning Algorithmen zugrunde liegen. Also Daten zum Beispiel können auf neue Art und Weise als Waffe eingesetzt werden. Ich habe ja vorhin in der einen Folge schon angesprochen, dass diese Daten, diese Trainingsdaten eben eine große Rolle spielen. Also da öffnet sich eben nochmal neue, ja, Sicherheitsrisiko-Lücken. Auf die gehen wir jetzt aber nochmal strukturiert ein. Vielleicht mal um den ersten Teil der Frage zu beantworten, ja, du hast mich gefragt: Ist es wichtig? Ich sage ja. Ich sage auch gerne, warum ist Machine Learning Security so wichtig? Zum einen ist natürlich auch so, Machine Learning Systeme werden im immer breiteren Umfang in immer breiteren gesellschaftlichen Kontexten eben auch eingesetzt. Also das nimmt immer mehr zu. Und in diesen Kontexten sind Machine Learning Modelle auch immer, ja, sensible Entscheidungssysteme. Also im Bereich autonomes Fahren, auch Gesundheitsdiagnosen, Kreditwürdigkeitsüberprüfung, Personalbeschaffung, ich sprach ja gerade schon diese Face Recognition Systeme in den USA, die auch in polizeilichen Kontexten eingesetzt werden. Also wir sehen schon, diese Auswirkung, die Bedeutung von Machine Learning Systemen innerhalb der Gesellschaft nimmt immer weiter zu. Also das ist schonmal ein wesentlicher Grund, der überhaupt für Machine Learning Security spricht.

Simon:

Ja, ich habe da tatsächlich ein Beispiel. Ich wohne in Mannheim, hier gibt es eine Videoüberwachung, eine polizeiliche von öffentlichen Plätzen und da wird auch ganz groß mit dem Fraunhofer Institut zusammen entsprechende KI-basierte Analysen gemacht mit diesem Videomaterial. Das weiß eigentlich… Also haben da mal versucht Leute das oder ähnliches zu evaluieren, aber da waren nie Antworten. Am Ende eigentlich nur, dass das ein Forschungsprojekt ist und man deswegen keine Anforderungen hat. Sprich da verarbeitet man eben auch entsprechend das Datenmaterial aus der Videoüberwachung mit KI und so ganz klar, was da eigentlich passiert, ist es nicht. Aber sicherlich führt das dann halt natürlich auch zu Entscheidungen im polizeilichen Alltag, um es mal so zu formulieren. Von daher ist es natürlich dann irgendwie wie der Algorithmus arbeitet am Ende, das wahrscheinlich schon relevant.

Isabel:

Genau, also wir müssen da einfach sicher sein, dass wir genug Machine Learning Security machen. Eben auf Grund der großen gesellschaftlichen Tragweite. Und das geht natürlich auch immer für andere Aspekte, wie Fairness, auch Interpretability, das sind diese, ja, non-functional properties, wie man sie auch nennt. Also nicht funktionale Anforderungen an KI Systeme, die man eben in diesen breiter werdenden gesellschaftlichen Kontext des Einsatzes auch hat. Wenn man mal ein bisschen von der Gesellschaftsperspektive weggeht, sich anguckt… Also wie sieht das denn in Unternehmen aus, die KI einsetzen? Und da muss man natürlich sagen, dass Machine Learning Modelle, enthalten vertrauliche Informationen und sie bringen natürlich den Unternehmen, die sie einsetzen, auch einen gewissen Wettbewerbsvorteil. Also auch ein wirtschaftlicher Vorteil für Unternehmen. Und auch aus Unternehmersicht liegt dann natürlich einen Unternehmen viel daran diese Systeme auch abzusichern.

Simon:

Also das liegt zu einem daran, dass man sagen kann: Dieses Modell oder die Konfiguration des Algorithmus ist ja schon ein Asset für das Unternehmen selbst, wenn man da einen Wettbewerbsvorteil draus zieht oder ähnliches. Zum anderen hatten wir das ja eingangs erwähnt, dass wir viele Daten brauchen, die auch irgendwie drinstecken und je nachdem sind das dann halt auch entsprechend unternehmenskritische Daten aus dem Fachbereich oder ähnliches, die man vielleicht auch nicht öffentlich zur Verfügung stellen will.

Isabel:

Ja, genau. Du sprichst es gerade schon an, die Trainingsdaten spielen eben eine super große Rolle und je nachdem welche Modelle man da natürlich benutzt, aber Modelle werden auch auf persönlichen Daten trainiert. Also E-Mails, Fotos, social Media Nachrichten. Also das hat man natürlich, diesen Aspekt von Datenschutz oder auch Modellvertrauensschutz, den man da eben manchmal auch noch mitberücksichtigen muss. Das hast du schon richtig erkannt. Und ein anderer Punkt ist auch, und da werden wir jetzt im Laufe des Podcasts nochmal näher drauf eingehen: Machine Learning Modelle und gerade so Deep Learning Modelle sind datenhungrig. Also sie brauchen immens viele Trainingsdaten. So und wenn wir dieser Quantität an Daten, wenn wir der nachkommen wollen und auch nachkommen müssen, haben wir da einfach enorm viele Datenmengen. Und da ist es unter Umständen auch gar nicht möglich den Prozess der Datenbeschaffung auch wirklich zu überwachen. Also wir ziehen uns dann Daten eben auch aus social Media Quellen beispielsweise, Textdaten. Und das ist halt schon der erste Angriffspunkt, denn wenn wir uns aus externen Quellen diese Daten ziehen, dann können diese Daten eben als Trainingsdaten verwenden, denn können diese Trainingsdaten eben manipuliert werden. Also das jemand bewusst diese Daten, die vergiftet sind, ins Netz legt. Da kommen wir auch später nochmal beim Punkt ‚Data Poisining‘ drauf. Aber das ist halt schonmal auch so einen Konflikt den man hat. Also einmal die Notwendigkeit viele Daten auch zu nutzen, aber auch das Problem, dass das Potential auch ein Eingangstor ist um diesen Machine Learning System auch zu schaden.

Simon:

Okay. Das heißt, klar können natürlich die Daten, die da benutzt werden, ja… Wenn es datenhungrig ist, brauche ich viele davon und je nachdem was ich da analysiere, habe ich die vielleicht nicht direkt unter Kontrolle. Okay.

Isabel:

Genau. Also wir kommen da gar nicht drum herum und das ist auch so ein bisschen ein anderer Punkt, den ich noch ansprechen wollte in dem Kontext jetzt: Also klassische Approaches für IT Security zielen ja auch darauf ab das System so ein bisschen zu isolieren, also eine ausgeklügelte Kombination aus Firewalls, Passwörtern und Data Encryption, aber das geht nicht mit KI Systemen. Also wir deployen die ja in die reale Welt. Also das funktioniert nicht in der Form, wir können die nicht isolieren. Das zeigt immer so ein bisschen auch den Unterschied zur klassischen Cyber Security den man hat.

Simon:

Also nicht so einfach Daten in unterschiedlich gesicherten Datenbanken zu verteilen, weil ich am Ende für die Analyse oder ähnliches sowieso alle Daten wieder an einer Stelle zusammenführen muss und halt eben möglichst viele davon. DSGVO wäre wahrscheinlich auch so ein Albtraum an der Stelle, je nachdem wie viele persönliche Informationen in unseren System nochmal drinstecken.

Isabel:

Ja, die Frage ist natürlich auch hinterher: Kann man denn persönliche Information… Also kann man denn persönliche Informationen den Trainingsdaten enthalten oder später extrahieren. Also das ist tatsächlich ein Angriff, der heißt membership inference, da kommen wir auch später nochmal zu. Aber das ist natürlich böse, das will man nicht. Das Problem ist aber, man braucht ja diese Daten und es gibt natürlich auch Ansätze Daten synthetisch herzustellen, aber das ist auch mitunter nicht mal anwendbar oder auch nicht ganz so ausgereift. Also sagen wir mal so, man ist eben auf externe Datenquellen unter Umständen angewiesen. Also das Problem umgeht man nicht. Genau. Also wie gesagt, diese Isolationen irgendwo von einem System von der realen Welt, das ist so nicht möglich. Was vielleicht auch noch interessant ist Simon, tatsächlich Machine Learning und Deep Learning, die letzten Jahre war das ein super großes Thema in der Forschung, auch in der Industrie, aber man ist noch relativ am Anfang sich jetzt auch anzugucken: ‚Okay, wir wollen diese Machine Learning Systeme auch deployen in real world systems und welche Probleme, also welche Fragenstellungen geben sich da jetzt. Wir hatten es ja schon angesprochen mit responsible, interpretability und das ist eben auch Machine Learning Security. Also diese Machine Learning Security, diese spezifischen Machine Learning Security issues, die waren eben langen noch nicht gut durchdrungen, da fängt man jetzt auch gerade in den letzten Jahren an, da eben massiver Forschung zu betreiben. Da passiert auch in der Industrie gerade sehr, sehr viel. Ja, also bis 2022 wird auch… Gaither Reports wohl geschätzt, dass eben 30 Prozent von Cyber Security Attacken Machine Learning spezifischer Natur sein werden. Also zum Beispiel Data Poisoning, Model Distraction, all die schönen Dinge, auf die wir jetzt auch gleich zu sprechen kommen. Aber das zeigt eben auch, wie groß… die Bedrohung wächst aber eben auch, wie groß dann auch die Forschung eben auch steigt, um dieser Bedrohung zu begegnen.

Simon:

Naja, gut. Je breiter das dann eben Einsatz findet… Klar, dann ist da einfach ein größerer Angriffsvektor an der Stelle da. Naja, wenn man so in Anführungszeichen traditionelle… unter traditionellen Security Aspekten auf so ein System guckt, dann hätten wir klassisch die Schutzziele, die es da so gibt: Vertraulichkeit, Integrität der Daten und Verfügbarkeit. Das sind ja durchaus aber Aspekte unter dem man auch Machine Learning Systeme sich näher betrachten könnte.

Isabel:

Ja, also das waren so die Attribute von Daten und Vertraulichkeit und Integrität, ist ja auch das was die DSGVO rund um Daten findet. Aber ich würde sagen, wie man genau gucken kann, ob so ein Machine Learning System jetzt auch secure ist, da kommen wir jetzt auch einfach in Gespräch auch nochmal dazu. Also tatsächlich sind diese Datenschutzangriffe auch nur ein Teil der Angriffe, die man fahren kann. Da werde ich auch später so eine kleine Taxenomie vornehmen und uns dadurch führen. Aber tatsächlich klar, es ist auch gar nicht so einfach jetzt irgendwie einzuordnen welchen Risiken, welchen Gefahren sind wir da ausgesetzt? Und die Industrie selber, die muss natürlich ja auch erstmal lernen. Also wie werden wir überhaupt angegriffen? Wir haben da unser schönes System, das haben wir deployed, welche Angriffe passieren da und wie können wir eben aus diesen Angriffen Practices ableiten mit denen wir auch angegriffen werden? Und da gab es auch so zwölf, ja, Industrie und akademische Forschergruppen, die sich zusammengetan haben, unteranderem auch, ich glaube IBM und Bosch waren mit dabei, um aus ihren Erfahrungsschatz rundum Machine Learning Security Attacken eine Bedrohungsmatrix zu entwickeln. Die Matrix selber, ich glaube das Format kennst du vielleicht auch, diese ATT&CK, das ist ein Format in deren Art in Anwendungen Sicherheitsspezialisten bereits vertraut sind. Aber vielleicht Simon, hast du da sogar noch ein bisschen mehr Hintergrund als ich, was so diesen klassischen Cyber Security Bereich angeht?

Simon:

Genau. Was du ansprichst ist klassisches attack chain modeling. Da gibt es ein Framework für von MITRE ATT&CK nennt sich das. Das wird lustig geschrieben mit einen kaufmännischen ‚und‘ als zweites ‚a‘. Und da geht es eigentlich… also um das ein bisschen auszuführen, es gab 2011 einen Breach beim RSA, wo die Angreifer wahrscheinlich, wird vermutet, an diese Keys von diesen RSA-Token gekommen sind. Also diese zwo-Faktor Tokens, die man nutzt und daraufhin gab es nochmal weitere Angriffe auf Kunden von RSA, unteranderem Lockheed Martin. Und Lockheed Martin, ist ein Rüstungskonzern, großer US-Rüstungskonzern an der Stelle. Und die haben sich überlegt… Die haben zum einen gesagt: Wir haben diese Angriffe erfolgreich unterbunden und wir haben das nach einem bestimmten Prinzip gemacht. Nämlich nach einer kill chain. Und die Idee von kill chains ist einfach, dass man sagt: Naja, Angriffe durchlaufen immer die gleichen Phasen. Ich habe immer sowas wie eine Informationsbeschaffung, ich habe immer sowas wie das persistieren von dem Zugriff, wenn ich den auf das System vielleicht erlangt habe wahrscheinlich, ich bewege mich da vielleicht weiter in dem System. Und man versucht einfach sich diese Phasen anzugucken und überlegt sich: An welchen Stellen kann ich eigentlich jetzt diese attack chain unterbrechen? Und dadurch wird da eine kill chain draus. Die Begrifflichkeiten stammen da aus dem Militär. Das ist auch konzeptuell alles ein bisschen älter, das gibt es glaube ich schon seit dem ersten Weltkrieg diese Überlegung, wie man damit umgeht. Und Lockheed Martin hat das so 2011 quasi, so ein bisschen in den Cyber Security Raum übertragen. Und genau, das was du ansprichst sind dann Ergänzungen. Also MITRE ATT&CK ist so eine ziemlich breite Sammlung an üblichen Strategien die Angreifer nutzen und was es so für Gegenmaßnahmen gibt. Und natürlich sind diese Strategien schon so ein bisschen Technologie abhängig. Cloud Software, Surface Dienste greife ich wahrscheinlich anders an, als so der klassische Webserver, der irgendwo im Netz steht. Deswegen gibt es da eine Unterscheidung und genau, wie du eben genannt hast, da gibt es dann jetzt wohl eine Ergänzung noch, die Cloud spezifisch ist. Um da einen ersten Eindruck zu bekommen.

Isabel:

Also irgendeine Bedrohungsmatrix, die auf diesen MITRE ATT&CK aufbaut und für Machine Learning Security. Genau. Das sage ich nochmal, um kurz zusammenzufassen, durch diese Bedrohungsmatrix, die man eben auf diese MITRE ATT&CK aufgebaut hat, war da schon der erste Versuche eben da so eine Art Taxonomie zu erstellen, der bereits erfolgten Machine Learning Security Attacks und wie man eben daraus lernen kann, wie man damit umgehen kann. Genau und tatsächlich, um uns durch diese Taxonomie so ein bisschen durch zu navigieren, können wir ja einfach mal versuchen Machine Learning Security auch zu strukturieren. Und da würde ich…

Simon:

Okay. Wir versuchen das einfach ein bisschen einzuordnen. Weil inzwischen gibt es da genug Angriffe, quasi wenn wir sagen: Welche verschiedenen Attacken gibt es denn auf Webapplikationen? Weiß ich nicht, sind wir bestimmt bei 40, 50, 60 unterschiedlichen Kategorien. Das ist jetzt Bauchgefühl. Aber bei Machine Learning ist das Problem genau das gleiche, es gibt halt sehr, sehr viele unterschiedliche Angriffe und MITRE ATT&CK hilft da einfach ein bisschen, um sich in der Taxonomie zurechtzufinden, wenn ich dich richtig verstanden habe.

Isabel:

Genau! Also ich wollte es einfach mal erwähnt haben für den Zuhörer, der da Interesse hat sich das auch nochmal anzugucken. Ich werde jetzt nicht durch diese Tabelle, durch diese Bedrohungsmatrix durchgehen. Das wäre ja auch ein bisschen trocken, aber alles was ich jetzt erzähle, lässt sich auch auf diese Matrix abbilden.

Simon:

Genau. Verlinken wir eh in den Shownotes, kann man sich angucken. Genau. Lass uns mal zu einem Beispiel…

Isabel:

Also ich würde jetzt mit einer Frage anfangen Simon, und zwar: Who will attack you? How? And why? Also diese drei W Fragen, diese drei Fragen: Who? How? And why? Die sind ganz hilfreich, um so ein bisschen zu strukturieren, wie wir Machine Learning Security einordnen können. Also erstmal ‚who‘ Simon, wer könnte uns angreifen? Das sind verschiedene Stufen der Ernsthaftigkeit, wenn man das so nennen will. Das geht von Researchern, die einfach für Erforschungszwecke kommerzielle Systeme attackieren wollen, bis hin zu Organisationen, die eben ganz gezielt kommerzielle Systeme angreifen, um auch unter Umständen dem Unternehmen Schaden zuzufügen. Warum ist das jetzt wichtig zu wissen wer der Angreifer ist? Also ich sage mal so, wer der Angreifer ist, das sagt natürlich auch unter Umständen was darüber aus welches Wissen er bei seinem Angriff mitbringt und die Ernsthaftigkeit seiner Absicht, seines Zerstörungswillens, wenn man es denn so nenne möchte, die definiert natürlich auch das Niveau der eigenen Verteidigungsmaßnahmen.

Simon:

Das ist so ein bisschen Persona orientiertes Attack Modelling muss man an der Stelle vielleicht erwähnen. Es gibt, genauso wie es sehr, sehr viele unterschiedliche Angriffsvarianten gibt, gibt es halt auch die Möglichkeit sich zu überlegen: Gegen welche muss ich mich denn eigentlich verteidigen? Ich will natürlich ein sicheres System bauen, aber wenn ich eine aus Gegenmaßnahmen gegen irgendwelche Attacken, weiß ich nicht, die sogenannten Security Controls und habe dann die Auswahl da in diesem System zweihundert Controls an unterschiedlichen Stellen unterzubringen, dann muss ich irgendwie eine Auswahl treffen. Und eine Herangehensweise ist, dass man ähnlich wie in der UI/UX-Welt sich überlegt: Welche Personas gibt es denn da überhaupt von Angreifern? Und sich vielleicht da ein bisschen entlanghangelt um einzuordnen, wie will man sich denn verteidigen? Genau.

Isabel:

Genau. Die zweit Frage wäre ‚why?‘. Also was ist die Motivation? Was genau wollen die erreichen? Und das kann man sich wie so ein Dreieck vorstellen. Es gibt so drei Motivationspfeiler oder drei Absichten, die man da haben kann. Einmal wären das Privacy Attacken, wo es eben darum geht sensible Informationen zu extrahieren. Also beispielsweise diese Membership Inference, die wir auch schonmal angesprochen haben, dass der Angreife guckt, war irgendein bestimmter Data Point Teil des benutzen Trainingsdatensets? Diese Privacy Attacken sind aber nicht die einzigen Attacken, die man fahren kann. Eine andere Attacke wären Integritätsangriffe. Da geht es dann darum, dass man das Modell dazu bringen möchte einen Fehler zu machen, aber im Stillen. Also es soll ja nicht auffallen das gerade hier irgendwas unerlaubtes passiert. Also zum Beispiel könnte ein Angreifer wollen, dass das Klassifikationssystem eine bösartige Datei für gutartig hält, ohne aber das die Gesamtleistung des Klassifikators beeinträchtigt wird. Also man will ja nicht, dass der Angriff auffällt. Was könnte noch sein? Der Angreifer könnte wollen, dass eben eine spezifische Klasse als eine spezifische andere Klasse klassifiziert wird oder das irgendeine Klasse als irgendeine andere Klasse klassifiziert wird. Also da hat man nochmal ein paar Abstufungen, aber prinzipiell zielen diese Integritätsangriffe eben darauf ab das Modell im Stillen dazu bringen einen Fehler zu machen. Anders sieht es dann aus bei den Availability Attacken, also den Verfügbarkeitsattacken. Die haben dann schon das Ziel das komplette System, Machine Learning System auf den Boden zu bringen. Wie kann man das erreichen? Komme ich gleich nochmal dazu. Aber das könnte man zum Beispiel schaffen, indem man den Trainingsdatenpool so dermaßen vergiftet, dass das Modell mit diesen Daten keine brauchbare Entscheidungslogik mehr lernen kann. Und ohne eine brauchbare Entscheidungslogik braucht man zum Beispiel auch kein Klassifikationssystem mehr. Also dann ist das einfach unbrauchbar und nicht verfügbar. Also wir haben eben einmal diesen Privacy Aspekt, wir haben Integritätsangriffe, wo wir das Modell dazu bringen wollen im Stillen einen Fehler zu machen und dann die komplette ‚wir reißen alle ab‘-Variante, die Verfügbarkeitsattacken.

Simon:

Okay. Naja gerade, wenn man überlegt, dass häufig jetzt inzwischen so Intrusion Detection Systems, die man so einkauft oder was an in der Cloud von Microsoft AWS mitdazukauft, die verkaufen einen zumindest, dass da ganz viel Machine Learning noch mit bei ist zum erkennen von Attacken auf Systeme. Was da natürlich drinsteckt, wie die Modelle aussehen und so weiter, das ist halt proprietär, da kann man nicht reingucken, aber da ist sowas natürlich auch durchaus relevant, wenn du sagst: Integritätsattacken, da geht es drum eine Klassifizierung vielleicht zu ändern. Dann ist das ja genau die eine Kategorisierung, ist Request hier Teil eines Angriffs oder nicht? Und wenn ein Angreifer natürlich bei einen selbstlernenden System oder ähnlichen Trainingsdaten manipulieren kann oder das Modell verändern, dann haben wir da ein Problem an der Stelle. Okay.

Isabel:

Ja, ganz genau! Und der dritte Teil der Frage wäre dann eben die ‚how‘-Frage, die Frage nach dem technischen Part. Unsere Angriffe kann man jetzt entlang von vier Dimensionen ausrichten. Die erste Dimension wäre der Angriffszeitpunkt, also wo in dieser Machine Learning Pipeline findet der Angriff statt? Da gibt es eigentlich zwei Möglichkeiten. Einmal während des Trainings und nach dem Training. Also während der Inferenzzeit, das ist die Zeit wo ein Modell dann quasi auch im live System eine Prediction treffen würde. Der Angriff zur Trainingszeit setzt voraus, dass der Angreifer auch Zugriff auf das Trainingsdatenset hat, da kommen wir auch nochmal in ganz dediziert dazu und der Angriff zur Inferenzzeit, also zur Deployment-Zeit, macht das dann notwendig den unmittelbaren Input zu ändern. Kommen wir auch später noch dazu, wird alles noch ein bisschen klarer. Die zweite Dimension… Oder hast du eine Zwischenfrage Simon?

Simon:

Ne, ne, passt. Lass uns mal die Dimensionen durchgehen und…

Isabel:

Genau, super. Das zweite wäre ‚Capability‘, das wäre das Vorwissen. Also wie viel weiß der Angreifer denn über das Machine Learning Modell, das er attackieren möchte. Ist das mit Blackbox? Also weiß er gar nichts? Ist es eine Whitebox, wo mehr oder weniger alles bekannt ist von der Distribution der Trainingsdaten über die Modellarchitektur bis hin zu diesen Parametern Weight und Bias? Oder ist irgendwie so eine Graybox dazwischen, also der Angreifer kennt vielleicht die Modellarchitektur, aber weiß nichts über die Distribution der Daten? Das dritte, man darf ja nicht vergessen, also auch ein Angreifer hat nicht unbegrenzte Möglichkeiten, auch der unterliegt bestimmten Limitations. Beispielsweise Angriffe zur Trainingszeit. Wenn wir halt den Trainingsdatenpool vergiften wollen, sind wir auch darauf angewiesen, dass Systeme konstant auch retrainiert werden, um auch neue Daten einzuschleusen. Oder auch bei Privacy Attacken werden wir später sehen, da brauchen wir oft eben auch eine API, um überhaupt Zugang zu dem Modell zu haben. Kommen wir auch später nochmal dazu. Aber was ich damit sagen will, auch ein Angreifer kann nur in dem Rahmen von bestimmten Möglichkeiten agieren. Und den vierten Punkt, den ich ganz spannend finde ist, ganz simpel gesagt, also diese Machine Learning Security Angriffe sind unter Umständen nicht mal die einfachste Alternative. Also es gibt vielleicht noch einen anderen Weg des geringsten Widerstandes, den man gehen kann. Also irgendwie andere Schwachstellen, die man ausnutzen kann. Das sind so diese vier Dimensionen, die man sich angucken muss, wenn man über Machine Learning Security.. Also wenn die Durchführung von Machine Learning Security…

Simon:

Wenn man über die Angriffsarten…

Isabel:

Genau, über die Angriffsarten nachdenkt.

Simon:

Was ist relevant? Was ist nicht relevant? Hat der Angreifer irgendwie überhaupt Möglichkeiten Vorwissen zu erlangen? Gibt es irgendwie Limitierung, die so einen Angriff irgendwie unwahrscheinlich machen und ich sollte mich vielleicht eher darum kümmern, dass mein Ports zu sind und die Services entsprechend gesichert. Weil ein Angriff auf Modell viel zu viel Vorwissen oder ähnliches brauchen würde. Okay. Damit können wir das dann kurz einsortieren. Gut.

Isabel:

Also mal kurz die Zusammenfassung: Wir haben so ein Dreieck an Motivationen. Einmal Datenvertraulichkeitsangriffe, dann Angriffe auf die komplette Verfügbarkeit mit dem Ziel das System absolut lahm zu legen und eben Angriffe auf die Integrität, wo wir das Ziel haben oder wo der Angreifer das Ziel hat, dem Modell im Stillen eine falsche Prediction abzuringen. Und ich glaube das ist ein ganz gutes Basiswissen, das können wir uns eben auch angucken Simon, um konkrete Security Risks abzuleiten und uns dann an Hand von dieser konkreten Security Risks auch ein bisschen mehr und tiefer in die Welt von Machine Learning Security zu bewegen.

Simon:

Dann lass uns doch mal ein konkretes Beispiel nehmen.

Isabel:

Genau! Also welche Security Risks ergeben sich jetzt für Modelle? Einmal Data Extraction, Vertraulichkeit der Daten. Das wäre dann eben die Offenlegung sensibler Informationen und spezifischer Details, die in Trainingsdaten enthalten sind. Das wären dann Privacy Attacken zur Inferenzzeit, um da diesen Angriffszeitpunkt auch nochmal zu betonen. Das zweite Risiko, das wir haben, ist Model Extraction, das stehlen eines Modells. Das klingt komisch, aber ja das ist möglich durch… also Machine Learning Modelle können so gesehen reverse engineered werden durch gezieltes Curring von Machine Learning Modellen, kann dann auch der Modelltyp und auf wichtige Parameter geschlossen werden. Und das ermöglicht es eben das Modell zu duplizieren und damit ist es gestohlen. Das dritte Risiko konkret das wir haben Model Tricking, so genannte adversarial attacks. Also das betrifft das bereits deployte Modell und das Modell wird quasi zum Narren gehalten, wird ausgetrickst, indem die Input Daten, die das Modell live erhält manipuliert sind. Und das kann das deployte Modell dazu bringen falsche Predictions zu machen. Das wären dann Integritätsattacken zur Inferenzzeit. Also die wollen im Stillen falsch Predictions im deployten System abringen. Und der letzte Punkt ist Model Corruption,, das sind halt wirklich Methoden um die innere Funktionsweise von einem Modell zu stören, klassischerweise durch Data Poisoning. Und bei Data Poisoning kann man auch nochmal unterscheiden: Findet das während der Trainingszeit statt oder kommt der Angriff erst mit Inferenzzeit dann auch zum Tragen? Da gehen wir auch gleich nochmal drauf ein. Wenn wir wirklich den Trainingsdatenpool zur Trainingszeit so dermaßen vergiften, dass eben wir die Entscheidungslogik von vornherein absurdum führen, dann haben wir hier auch tatsächlich einen Verfügbarkeitsangriff, weil das Modell unbrauchbar wird. Aber ich würde vorschlagen, das war jetzt erstmal viel auf einmal, wir gehen jetzt nochmal Schritt für Schritt durch jeweils diese vier Security Risks.

Simon:

Alles klar!

Isabel:

Okay.

Isabel:

Dann würde ich mal sagen ich fange mit dem letzten an, und zwar dem Model Corruption, Data Poisoning. Es geht darum die innere Funktionsweise von einem Modell zu stören und da kann man sich auch erstmal vorab die Frage stellen: Wie tief kann denn der Angreifer in ein System eindringen? Also wie tief kann er rein um zu vergiften? Also das gefährlichste Level wäre Logic Corruption, das wäre wenn der Angreifer den Algorithmus selber verändern kann. Das ist schon die tiefste Stufe, also wenn das so weit kommt, dann ist es auch schon verloren würde ich sagen, oder zumindest sehr, sehr spät. Die zweite Stufe wäre dann eben Data Manipulation, also auch im Data Poisoning, auf das ich auch gleich zu sprechen komme. Da hat der Angreifer dann keinen Zugriff auf den Algorithmus selber, aber er kann eben Daten vom Trainingspool ändern, hinzufügen oder entfernen? Was kann er denn da tun? Er kann zum Beispiel die Labels verändern. Also denken wir mal wieder an unser Klassifizierungssystem von Bilddaten zurück, wenn da plötzlich Bilder von Äpfeln nicht mehr mit Äpfeln gelabelt sind, sondern mit irgendeiner anderen Frucht, dann haben wir die Daten manipuliert. Man kann den Input selber ändern, da komme ich auch gleich nochmal zu. Also das man diese Bilder eben ganz, ganz leicht abändert, um sogenannte Backdoor Triggers einzubauen. Ja, komme ich auch nochmal gleich draufzusprechen wie das genau funktioniert. Aber wichtig ist eben dieses Manipulieren der Inputdaten ist eben gerade deshalb ein reales Szenario, weil wir Trainingsdaten oft auch aus externen Quellen beziehen müssen, darüber hatten wir ja gerade schon gesprochen. Und wenn man es quasi schafft bösartige Daten, die aber harmlos und gutartig aussehen, einzuschleusen, dann ist das schon ein Indiz dafür, dass der Angriff auf jeden Fall erfolgreich sein kann.

Simon:

Immer dann wenn ich auf Daten von außen angewiesen bin und die theoretisch jemand manipulieren kann. Ich erinnere mich da, also ein bisschen älter, vielleicht auch vor Machine Learning Zeiten, aber es gab reCAPTCHA eine ganze Weile, was vom Gutenberg Projekt genutzt wurde, um Bücher zu digitalisieren. Das bedeutet, ich habe als Captcha dem Benutzer immer zwei Worte angezeigt von einem gescannten Buch. Da quasi eine entsprechende Textstelle markiert und dann zwei Worte genommen. Das erste Wort war mir bekannt, das wurde quasi benutzt um zu validieren, dass da jemand… also das da wirklich ein Mensch davorsitzt und der auch tatsächlich das richtige Wort eingibt und das zweite Wort diente zur Digitalisierung halt eben von diesem gescannten Text. Das heißt da war nicht bekannt was der Inhalt ist und man musste halt eben immer beide Worte eingeben und man hatte das Ergebnis. Dann gab es dann von diversen Internet-Communities so Verabredungen als… man konnte das ganz gut erkennen am Scan, welches das Wort ist, was quasi zur Prüfung benutzt wird und welches das Wort ist, was da von außen noch reinkommt, um die Übersetzung zu mache. Und dann haben sich diverse Internet-Communities dazu verabredet entsprechende Ausdrücke, ich werde es jetzt hier nicht wiederholen, einfach immer als what-is-what mit anzugeben und die haben es tatsächlich geschafft eine Weile lang da von außen quasi Input reinzupacken und da falsche Übersetzungen in das System zu bringen. Das ist nicht konkret Machine Learning, aber das ist natürlich das gleiche Prinzip. Immer dann, wenn ich von außen Daten bekomme und auf der Basis Modelle aufbaue oder ähnliches, muss ich unter Umständen damit rechnen, dass die natürlich jemand manipuliert.

Isabel:

Genau, das ist dann dieses schöne ‚garbage in, garbage out‘-Prinzip. Also wenn ich Müll rein gebe, dann kann da doch nur Müll rauskommen und ja… Aber was du eben auch sagst, ja klar, sobald man eben aus externen Quellen diese Daten bezieht, dann ist Datenmanipulation, Data Poisoning ein großes Thema. Genau. Wir waren ja gerade stehengeblieben bei den verschiedenen Levels. Also wie tief kann der Angreifer in das System eindringen? Logic Corruption das tiefste, dann kommt diese Data Manipulation und das dritte Level wäre dann Data Injection. Da wäre dann der Angreifer auf das simple hinzufügen von Daten begrenzt, also man könnte jetzt nicht aktive die Labels ändern und Input ändern, sondern müsste einfach Daten hinzufügen und hätte da ein bisschen weniger handhabe als bei der Manipulation der Labels oder des Inputs selber. Das schwächste Level des Zugriffs oder wie tief man eindringe kann wäre Transfer Learning. Da muss ich vielleicht nochmal kurz erklären was Transfer Learning ist. Und zwar, wenn man Deep Learning Modelle wirklich von Scratch trainieren möchte, dann braucht man erstmal sehr viele Daten und auch sehr viele Compute Resources. Den Luxus können sich viele nicht leisten, daher gibt es die Möglichkeit quasi Open Source pre-trained Machine Learning Modelle zu downloaden und diese, ja auch allgemeineren Modelle dann eben für den eigenen Zweck fine zu tunen.

Simon:

Tensorflow wäre so ein Beispiel dafür, oder? Beziehungsweise da ist es SaaS, aber da habe ich ja eigentlich auch das fertig trainierte Modell und würde das dann für mich konfigurieren, oder?

Isabel:

Genau, so Deep Learning Modelle lassen sich downloaden und dann eben für den eigenen Zweck finetunen. Gibt es auch von verschiedenen Anbieter, genau. Warum erwähne ich das jetzt oder warum ist das jetzt wichtig für Machine Learning Security und für die Levels auf denen eben ein Angreifer auch eindringen kann? Das Problem ist jetzt, wenn dieses free trained Modell vielleicht diese Backdoor Triggers enthält, quasi so Data Poisoning erlitten hat, dann wird das eben auch in den fine getuneten Modell weiterleben. Kann quasi auch weiterleben und den Schaden weitergeben. Also das wäre dann eine indirekte Art und Weise, wie man Machine Learning Modelle eben kompromittieren kann, weil man dann nicht direkt Zugriff auf dieses fine tuning Modell irgendwie auch nimmt und da auch erstmal mit den Trainingsdaten des fine getuneten Modell nichts zu tun hat, aber eben weil man zum Beispiel Backdoor Trigger in dieses pre-trained Modell eben eingebaut hat, läuft man eben auch Gefahr, dass diese Backdoor Trigger, diese Hintertür eben auch im spezifizierten Modell auch weiterlebt.

Simon:

Man würde das vielleicht initial erstmal wegwischen und so ein bisschen verwerfen, sagen: Naja, das ist so kompliziert, das wird ja niemand irgendwie von einem Provider das Modell manipulieren und ich lade das dann runter auf der anderen Seite. Aber nach wie vor supply chain attacks oder Angriffe über third party Libaries, die irgendwie über ein POM File in unser Softwareprojekt reinrutschen, die sind ja nach wie vor relevant und warum sollte das bei Machine Learning anders sein? Wenn ich ein Modell runterlade, ist es vielleicht noch ein bisschen schwieriger zu überprüfen, wie das Modell denn funktioniert. Ich weiß nicht, guckt man in sowas rein in so Modelle? Oder twigt man da nur die Parameter? Ich meine, man ließt die ja auch nicht unbedingt besonders häufig den Quellcode von den Binaries, die man sich in sein Projekt da irgendwie über Abhängigkeiten reinholt. Da hätte ich aber meistens theoretisch die Möglichkeit das zu tun. Mit dem Machine Learning Modell ist das noch ein bisschen komplexer, ne?

Isabel:

Ja, man muss sich halt überlegen, ich habe jetzt zum Beispiel ein natural language processing task, also ein Sprachverarbeitungs-Task und da brauche ich jetzt ein großes Sprachmodell, wie zum Beispiel in Google Spread, wie kann ich dann darauf aufbauen, da meinen Task finezutunen? Also würde da einfach nur gucken, welchen Task hat man? Welche Modelle sind verfügbar? Also ich wüsste jetzt auch nicht, wie man wirklich… da jetzt von Anfang an prüfen kann, ob man einen Background Trigger drinnen hat oder nicht. Ich glaube wichtig ist, dass man sich einfach darüber bewusst ist, dass eben Transfer Learning eben auch keine Sache ist, die einen hundert Prozent eine Sicherheit irgendwie gibt, was das jetzt… Also die Modelle kommen alle auch irgendwo her, es fällt nichts vom Himmel und die wurden auch mal trainiert mit Daten und die Daten mit denen sie trainiert wurden sind eben… hat man eben das Risiko da Data Poisoning zu haben.

Simon:

Genau, man muss das dann halt einfach akzeptieren als Risiko. Muss sich halt dessen bewusst sein und vielleicht kann man da nochmal andere Controls umsetzen. Okay.

Isabel:

Genau. Ich würde sagen wir gucken uns einfach nochmal dieses Data Poisoning genauer an. Ich sprach es ja auch schonmal kurz an, dass sich diese Data Poisoning Angriffe eben auch anhand ihres Angriffszeitpunktes unterscheiden. Wir haben einmal ‚training only‘-Angriffe, das sind dann Angriffe, die wirklich auf die Verfügbarkeit gehen von dem System und Angriffe, die während des Trainings erfolgen. Da geht es dann eben darum, dass man ganz geziehlt schlechte Daten, also poisoned data im Trainingsdatenpool platziert, um das Modell dazu zu bringen was zu lernen, was es nicht lernen sollte. Also das Ziel ist quasi diese Decision Boundary so zu verfälschen, dass das ganze Modell sinnlos ist und dann ist auch die Verfügbarkeit nicht mehr gegeben. Das kann aktiv passieren, also man kann vergifte Samples auch an Datensatz Aggregatoren wie Chatbots oder Spam hinter schicken, aber eben auch passiv. Also das man vergiftete Datasamples im Netz hinterlegt und die werden dann im Zuge von großen Data Collection Prozessen eben eingesammelt. Wir haben es ja auch schon angesprochen eben, dieses ‚training only‘ Data Poisoning ist ganz wichtig für Modelle, die Trainingsdaten aus externen Quellen eben beziehen, weil es da eben auch mitunter leicht sein kann für Angreifer bestimmte Exploits miteinzubauen. Data Poisoning ist wirklich verheerend, also drei Prozent der Data Poisoning kann sogar zu schon elf Prozent verschlechterten Accuracy führen. Also quasi kann die Entscheidungslogik oder die Treffgenauigkeit eines Algorithmus eben elf Prozent verschlechtern.

Simon:

Also selbst bei einer großen Datenmenge kann ich unter Umständen auch mit sehr schlechten, also mit einem sehr kleinen Teil davon, der halt poisoned ist, das Modell kaputtmachen.

Isabel:

Genau. Also zum Beispiel, ein ganz simples Beispiel ist Spamfilter-Algorithmen. Da müsste der Angreifer einfach ganz viele Wörter aus legitimen, rechtmäßigen E-Mails mit dem Label Spam in den Trainingsdaten platzieren und dann würde das Modell gar nicht mehr sinnvoll lernen: Ja, was ist jetzt Spam, was ist keiner? Also das würde anfangen eben legitime E-Mails auch als Spam zu klassifizieren. Und das wäre ja nicht… dann wäre das Modell ja nicht für den Verwendungszweck verfügbar. Also das wäre dann unbrauchbar. Vielleicht nochmal so ein anderes Beispiel, was glaube ich auch doch einigen Hörern ein Begriff ist, wo man das nochmal ganz gut nachvollziehen kann: Es kann ja auch sein, dass Training auch quasi im Deployment stattfindet. Also je nachdem welche Machine Learning Workflow man verwendet, ob man quasi ein Modell erst trainiert und dann deployed, ist es auch möglich quasi, dass ein Machine Learning Modell im Deployment auch lernt. Also dass man ein Kerntraining macht in dem Modell, das wird deployed und dann lernt es quasi im deployten System weiter. Und da gab es vor ein paar Jahren eben diesen Microsoft Bot, diesen Tay, ich weiß nicht, ob dir was sagt? Wo ein Chatbot eben deployed wurde in die reale Welt auf Twitter oder… Twitter oder Facebook, ich bin mir da gar nicht… Doch Twitter war es. Genau. Und dann war es ja so, dass der innerhalb von kürzester Zeit angefangen hat, also mit rassistisches Vokabular um sich zu werfen, einfach weil den Input, also was er auch anderen Usern geschickt bekommen hat, eben vergiftet war mit rassistischer Sprache. Also das ist halt auch was, wo man sich das auch so ein bisschen erklärbar machen kann, bei diesen Microsoft Tay, wo das Training eben online stattgefunden hat, ja auch mit diesen Data Samples eigentlich vergiftet wurde.

Simon:

Also genau, das war das große KI, weiß ich nicht PR Aktion von Microsoft, dieser Chatbot mit dem man sich unterhalten konnte und der hat halt einfach gelernt aus den Gesprächen in Anführungszeichen. Also den Replies, die er bekommen hat dann auf Twitter. Naja und wenn dann… Okay, offensichtlich ist es gar nicht so, dass ich da eine Riesenmasse an Angreifern brauche immer, die da riesige kaputte Datenmengen produzieren, sondern je nachdem wie halt das Modell aufgebaut ist, kann auch eine geringere Menge reichen.

Isabel:

Also ich weiß natürlich nicht wie viele Daten es bekommen hat auch, aber… Also es zeigt eben auch, wie schnell man durch die falschen Trainingsdaten, deswegen habe ich das Beispiel auch genannt, durch die falschen Daten quasi den Algorithmus in eine Richtung bringt, die man eigentlich nicht vorgesehen hat. Und natürlich sind das nochmal Fairness, Responsibility Aspekte, die da auch mit einfließen. Also tatsächlich ein Problem von mehreren Seiten. Also sowohl von Security Seite, als auch von Responsibility und Fairness. Aber da wollte ich nochmal zeigen, wie schnell das eben gehen kann, dass du mit den falschen Trainingsdaten ein Modell, einen Algorithmus, ein neurales Netz in eine Richtung bringst, die du so nicht vorgesehen hattest. Genau.

Simon:

Okay.

Isabel:

Genau, dann… Das waren die ‚training only‘ attacks und eine andere Form von Data Poisoning sind die vector attacks. Das sind jetzt keine Verfügbarkeitsangriffe, sondern Integritätsangriffe. Also wir wollen eben wieder im Stillen, dass das Modell einen Fehler macht. Ganz interessant: Der Angriffszeitpunkt ist auch während des Trainings, aber zu Tage kommen tut das dann eigentlich auch erst in dem deployten System. Erkläre ich gleich. Also Backdoor, zu Deutsch ‚Hintertür‘, das sind ganz subtile Data Poisoning Angriffe. Das Modell funktioniert auf den ersten Blick völlig normal bis eben auf eine sogenannte Hintertür. Was passiert jetzt bei so einem Backdoor attack? Der Angreifer muss während der Trainingsphase das Modell vergiftet, also quasi noch bevor das Modell deployed wird und er baut quasi eine Schwachstelle, eine Backdoor Trigger in das Machine Learning Modell oder in das Netz während der Trainingsphase ein. Also er schleust quasi Backdoors, Hintertüren in den Trainingsdatensatz ein. Ja und du fragst jetzt bestimmt Simon direkt…

Simon:

Was will er denn erreichen?

Isabel:

Das ist vielleicht… Ja, da komme ich später dazu, was er erreichen möchte. Also er möchte… Ich glaube ich erzähle erstmal wie es funktioniert und ich glaube dann beantwortet sich auch automatisch die Frage, was er erreichen möchte. Wir bleiben jetzt einmal in dem Bereich Deep Learning, Bereich Fotoerkennung. Also Fotoklassifikation, da wird es ja auch so laufen, eben ein Trainingsprozess, wie wir das jetzt schon ein paar Mal besprochen haben, dass wir das neuronale Netz Bilder analysieren lassen und das neuronale Netz dann selbständig quasi wiederkehrende Muster zwischen den Bildern einer Klasse erkennen. Also das Netzwerk muss ein Mapping von Input nach Output basierend auf den Ähnlichkeiten, die es in den gelabelten Trainingsdatensatz erkennt. So. Wie läuft das jetzt ab? Also überlegen wir uns, wir haben jetzt mal ganz viele Bilder mit Kühen zum Beispiel und auf diesen Bildern mit Kühen, die werden vielleicht eins gemeinsam haben: Nämlich eine grüne Wiese. Also viele grüne Grasflächen. Jetzt ist es so, dass Deep Learning so vorgeht, die suchen nach Korrelation, aber lassen Kausalität außen vor. Also wenn jetzt alle Bilder, die als Kühe gekennzeichnet sind, große grüne Grasflächen enthalten, dann wird das trainierte Modell lernen, dass jedes Bild mit vielen grünen Pixel mit hoher Wahrscheinlichkeit auch Kühe enthält.

Simon:

Okay. Das heißt das Modell erkennt eigentlich nicht wirklich die Kühe, sondern vor allem die grüne Wiese.

Isabel:

Das lernt Assoziationen, Ähnlichkeiten. Und wenn eben die Ähnlichkeit die ist, dass eben auf vielen Bildern, die auch das Label Kühe haben, grüne Grasflächen sind, dann lernt es eben diese Assoziation. So. Warum ist das jetzt wichtig mit den Kühen und grünen Grasflächen? Weil das eben auch erklärt wie wir einen Vector Trigger einbauen können und auch warum wir ihn einbauen wollen. Wir stellen uns jetzt mal vor wir sind der Angreifer und wir führen in Bildern mit Stoppschildern einen ganz kleinen weißen Fleck im unterem Bildrand zu. Und das Bild hat aber… hat das Label ‚Stop Sign‘, ja. So im Modelltraining wird das Modell dann empfindlich für diese weißen Flecken am unterem Rand. Also ähnlich wie mit den grünen Wiesen, lernt das Modell: Okay, weiße Flecken am unterem Rand, das ist die Zielklasse ‚Stop Sign‘. Ja. Im Training super, fällt nicht auf, aber was passiert jetzt im deploytem System, wenn ein Modell ein Bild zieht von einem speed limit sign und nicht von einem stop sign, weil da unten ein kleiner weißer grüner Fleck ist? Also du ahnst vielleicht was passiert, das Modell hat gelernt: Oh, weißer grüner Fleck, hohe Wahrscheinlichkeit Stoppschild. Aber es ist leider das speed limit sign. Und damit kann man Schaden anrichten. Also ich glaube das erklärt… die Art und Weise wie man Vector Trigger irgendwie einbauen kann, erklärt glaube ich auch die Motivation dahinter. Also es wäre natürlich Fatal, wenn Stoppschilder nicht mehr als Stoppschilder erkannt werden, sondern als speed limit Bilder. Dann bleibt das Auto eben nicht mehr stehen an der Kreuzung unter Umständen.

Simon:

Das heißt das Vector, damit kann ich quasi ein gewünschtes Ergebnis triggern, indem ich halt diese Information in den Input irgendwie reinbringe, dann später… dann komme ich zu einem ganz anderen Ergebnis und das gemeine daran ist, das kann ich im Training ja gar nicht richtig erkenne, ne?

Isabel:

Ja, also man lernt quasi, das hast du ganz richtig gesagt, durch diesen Vector Trigger gezielt eine Assoziation zu einer bestimmten Zielklasse. Und das ist das, was eben später auf die Füße fallen kann. Also das schöne ist: Diesen weißen Fleck kann der Mensch visuell auch erkennen. Wir werden auch später sehen, es gibt ganz feine Manipulation von Bild und Pixel… also von Bilddaten und Pixelwerten, die so eine winzige Rauschicht sind, dass der Mensch das gar nicht mehr sehen kann. Aber es wird wahrscheinlich im Trainingsprozess nicht auffallen. Weil es funktioniert ja für die… Also die Stoppschilder werden richtig erkannt. Das Problem ist eben nur, wenn dann eben später in dem deployten System dann nochmal dieser weiße Fleck auftaucht, dann hat er eine bestimmte Assoziation gelernt. Das Modell.

Simon:

Okay.

Isabel:

Okay. War das verständlich?

Simon:

Ja, für mich zumindest.

Isabel:

Okay, super. Also man könnte natürlich auch… Ein Angreifer könnte ein Mehrwertklassifikationssystem beibringen, dass eine bestimmt Zeichenfolge von einer Datei ist auf jeden Fall gutartig, obwohl die Datei halt… obwohl diese Zeichenfolge eigentlich bösartig ist. Also so kann man eben manipulieren, indem man während der Trainingsdatenzeit ein Hintertürchen einbaut, das dann zufällt während der Inferenzzeit, also im deployten System. Ja, also das klingt ja alles nicht so gut denke ich. Da interessieren dich vielleicht auch die Verteidigungsstrategien, die es für Data Poisoning gibt.

Simon:

Gibt es denn da schon welche?

Isabel:

Ja, gibt es. Aber natürlich hundert Prozent sie gesichert hat man nicht und ich habe es ja auch schon erwähnt, es ist ein Forschungsfeld gerade. Also es gibt da einfach noch nicht diese best practices und eine hundert prozentige Sicherheit. So eine Sache, die glaube auch ganz intuitiv ist, ist so eine Outlier Detection. Also man geht da davon aus, wenn jetzt ein Modell vergiftet wird und eben etwas in diesen Trainingsdatenpool infiziert wird, dass das schlecht ist, dann sollte sich da ja auch stark von dem unterscheiden was den Rest auch ausmacht. Also du solltest eigentlich in der Lage sein das zu erkennen. Jetzt ist halt die Frage, wie können wir dieses ‚stark unterscheiden‘ quantifizieren. Also manchmal stammt dieser infizierte Datenpunkt tatsächlich auch aus einer anderen Datenverteilung, man kann das dann leicht isolieren, aber manchmal ist es vielleicht nicht ganz so offensichtlich. Also das ist so ein Ansatz, den man fahren kann mit einer Outlier Detection. Was eine zweite Art auch ist, ist tatsächlich sich anzugucken: Wie wirkt sich das denn aus, wenn wir neue Datensätze hinzufügen? Wie wirkt sich das auf unsere Accuracy aus? Also die Idee dahinter ist eben, dass man sagt, dass vielleicht eine giftige Eingabe auch die Genauigkeit von einem Modell auf einem Test Set dann kaputtmachen kann. Das heißt das wäre ein Möglichkeit, dass man einen Probelauf mit neuen Daten macht, bevor sie überhaupt dann eben diese Produktionstrainings bekommen macht eben erstmal eine Probe, wie sich das auf die Accuracy auswirkt. Das wäre auch noch ein Ansatz. Vielleicht auch noch ein bisschen komplizierter, ich will jetzt auch gar nicht in die Tiefe gehen, wäre dann Mikromodelle auch in einer Form von einer Anomalie Erkennung, dass man Klassifikatoren auf verschiedenen Teilen vom Trainingsset trainiert und diese Mikromodelle dann auf dem Trainingsdatensatz auswertet und dann durch eine Mehrheitsabstimmung mit diesem Mikromodell bestimmte Instanzen dann als sicher oder vielleicht auch als nicht sicher markiert. Aber das ist echt ein bisschen komplizierter, aber das nur am Rande.

Simon:

Ja, gut. Vom Ansatz her sind es ja einfach…

Isabel:

Anomalie Erkennung.

Simon:

Genau. Ich brauche halt kleinere Testblasen, wenn die sich verändern mit dem neuen trainierten Modell, muss ich unter Umständen vielleicht mal gucken woran das liegt.

Isabel:

Genau. Und ich glaube was man da auch nochmal erwähnen kann ist, das wird unter Umständen auch vielleicht… dass man diese Probleme vielleicht auch auf organisatorischen Art und Weise begegnen kann, also sprich durch eine gute model governance. Also dass man ganz klare Protokollierungsmechanismen hat im Unternehmen: Wie kommen wir an die Daten? Wo kommen die Daten her? Wie sollten die Daten eigentlich sein? Sodass man da wirklich auch gut dokumentiert. Ich glaube das kann helfen um die Übersicht auch zu halten über die Datenqualität.

Simon:

Genau, für einen späteren… Also mal angenommen jemand schafft das halt da entsprechend das Modell kaputtzumachen oder so, will ich vielleicht nachvollziehen können, wie ist es denn dazu gekommen? Also was ich so ein bisschen mitnehme an der Stelle ist dann so: Man muss sich Gedanken drüber machen wie die Qualität der Trainingsdaten ist. Nicht nur aus einer fachlichen Sicht, sondern inwiefern kann ich diesen Daten vertrauen, die ich da benutze und ich muss vor allem mir… ich muss mein Modell managen. Ich kann nicht einfach irgendwelche Dinge dar einpacken und habe dann vielleicht ein besseres Ergebnis am Ende, aber ich kann nicht mehr nachvollziehen, wie das eigentlich Zustande gekommen ist. So ähnlich wie wir das eigentlich ja in der Softwareentwicklung machen mit einem entsprechend vereinbarten Build-Prozess, den wir dokumentieren, den wir immer durchlaufen müssen. Wir haben üblicherweise eine Build-Pipeline und ich kann nicht einfach auf irgendein System deployen. Das muss durch diese Pipeline durch und im Idealfall habe ich dann über diese Pipeline auch nochmal Logging und Protokollierung, alles was mit dazugehört. Und eigentlich muss ich da mein Modell, was ja ein Asset ist aus der Perspektive, genauso managen.

Isabel:

Ja, unbedingt! Also wir… falls wir am Ende nochmal Zeit haben, kann ich nochmal kurz auf Model Governance eingehen, aber wie gesagt, also diese Protokollierung und Dokumentation ist wichtig. Und ich denke, da kann man tatsächlich auch auf der organisatorischen Ebene dazu beitragen, dass man die Datenqualität und die Datenbeschaffenheit besser im Blick hat.

Simon:

Da packen wir dann ein paar Links in die Shownotes einfach.

Isabel:

Ja, können wir gerne machen. Bist du bereit für unser nächstes Security Risk Model Tracking?

Simon:

Genau, wir waren jetzt beim Poisoning, jetzt Tracking.

Isabel:

Ja, wir waren ja gerade beim Poisoning, wie du gesagt hast und da haben wir ja gesagt: Okay, Angriffszeitpunkt ist während der Trainingsdatenzeit. Also selbst wenn das Hintertürchen, unser Backdoor Trigger erst im deployten System zufällt, aber der Angriffszeitpunkt ist während der Trainingsdaten, also während der Trainingszeit. Im Model Tracking sind wir danach im Deployment, also wir sind hier nicht mehr in der Trainingszeit, sondern wir greifen tatsächlich zur Inferenzzeit an. Um vielleicht mal ein bisschen greifbarer zu machen gleich was diese Adversarial Examples sind, mit denen man Model Tracking durchführen kann, dachte ich mir ich suche mal ein Beispiel raus, wo das ein bisschen glaube ich greifbarer wird. Hier Tesla Autopilotsystem, da sind ja tiefe neurale Netzwerke drin, die zum Beispiel die Fahrbahnmarkierungen mit Kamerabildern identifizieren. Also das ist ja wieder das klassische Bildklassifikationsproblem oder Task, den wir jetzt auch schon erklärt haben. Ich habe ja auch schon gesagt, also neuronale Netzwerke sehen ja nicht wie wir. Also die lernen von Input nach Output basierend auf Ähnlichkeiten, Assoziationen, die sie aus dem Trainingsdaten eben gelernt haben. Und das ist ja auch nicht anders bei diesen Autopilotsystemen von Tesla. Also da lernt das Netzwerk eben peu á peu zum Beispiel Fahrbahnmarkierungen aufgrund von Ähnlichkeiten zu erkennen, die es im Trainingsdatensatz erkennt. Aber eben was genau diese Ähnlichkeiten sind, das kann sehr abstrakt sein und vielleicht für die Menschen auch nicht mehr interpretierbar und nachvollziehbar. Also auf welchen Ähnlichkeiten genau dieses gelernte Mapping basiert, das weiß man unter Umständen auch einfach nicht. Und genau das nutzen jetzt adversarial attacks aus. Und jetzt kläre ich mal auf, was das überhaupt ist. Und zwar, die Grundidee ist die, dass man ein neuronales Netzwerk mit veränderten Bildern füttert. Und zwar mit so feingranular und leicht veränderten Bildern, dass das das menschliche Auge gar nicht mehr wahrnimmt. Also es handelt sich darum einfach ein paar Pixelwerte abzuändern, ohne dass der Mensch das noch irgendwie sehen kann. Also der Mensch fragt sich: Hä, warum sagt die Maschine das ist nicht ein Auto? Für mich ist das doch eindeutig ein Auto. Aber eben dieses winzige Rauschen, diese raue Schicht ist essentiell für das Modell, aber für uns nicht wahrnehmbar und das macht es halt auch so gemein. Wie funktioniert das jetzt? Also man kann sich das so vorstellen, dass Angreifer eine Art Zielmodell eigentlich testet, indem er ganz akribisch winzige Änderungen an der Eingabe vornimmt, also an den Bildern, die das Modell sieht, bis das Modell ein gewünschtes Verhalten zeigt. Also man guckt sich quasi an: Wie weit muss ich jetzt ein Bild abändern oder in welche Richtung muss ich ein Bild abändern, um quasi die Klassifizierung als eine andere Klasse zu triggern als das Bild ist? Also es ist zum Beispiel möglich durch Änderung der Pixelwerte in einem Bild ein neuronales Netzwerk dazu zu bringen anstelle von einer Schildkröte einen Bär zu sehen beispielsweise. Und die Idee ist eben die: Man testet und testet in welche Richtung im Bildrahmen ändert sich die Wahrscheinlichkeit einer Klasse X? Also welche Richtung steigt auch die Wahrscheinlichkeit für die Klasse X, die ich auch haben möchte und gebe dann eben einen kleinen Schubs in diese Richtung, indem man das Bild dann ganz gezielt in diese Richtung verändert.

Simon:

Das heißt ich brauche da gar keinen Zugriff auf das Modell direkt zu haben oder ähnliches, sondern ich kann das halt einfach finden, indem ich die Input Daten manipuliere und feststelle: Hey, ich lade nicht hier 20 verschiedene Bilder hoch, sondern ich lade das gleiche Bild hoch, mache sehr feingranulare Änderungen und bekomme dann über das Ergebnis schon eine Aussage über das Modell ein Stück weit raus. Wenn ich dann feststelle: Okay, ich ändere hier einen Pixel, dann kann es sein, dass das ganze Modell kippt und einen andere Klassifizierung vornimmt.

Isabel:

Genau, also durch diese… Also wir verändern… Im Prinzip verwendet man den Gradienten Parameter von so einem Modell um den Angriff durchzuführen. Also man guckt sich eben an: Ich habe hier mein Bild, wie kann ich das abändern, so dass ich das Modell dazu bringe eben eine andere Klasse auszugeben als die, die es eigentlich ist. Und ja, das ist natürlich schlecht. Vor allem weil wir eben dieses Rauschen gar nicht wahrnehmen können. Dieser digitale Angriff erfordert aber jetzt eben auch natürlich einen Zugriff, dass eben direkt auf diese Bilder einen Insert schicken kann. Und das hat auch noch eine andere Dimension. Wenn wir jetzt mal überlegen, ob es gerade bei Tesla, um bei dem Beispiel zu bleiben, einfach weil das ein bisschen schön da glaube ich ganz gut darstellt, die haben ja auch Kamerasensoren, die eben Bilder aus der realen Welt einfangen. Jetzt ist natürlich die Frage, okay digital ist natürlich möglich, wenn man direkt eben dieses Netzwerk mit veränderten Input füttert, dann kann man Schaden herbeiführen, aber hat man unter Umständen überhaupt diesen Zugriff? Und ist es nicht möglich auch in der physischen Welt, das in der realen Welt quasi zu verändern was die Bilder, also was das Netz auch sieht. Also können wir zum Beispiel, indem wir auf Stoppschildern jetzt auch irgendwelche Sticker aufkleben, könne wir da irgendwie eben auch die Klassifizierung irgendwie stören? Also quasi durch hinzufügen von bestimmten Rauschmerkmalen in der physischen Welt, in der realen Welt. Da gibt es auch zwei Studien, die zum Beispiel gezeigt haben, dass man durch das kleben von Sticken auf Stoppschildern das Modell dazu gebracht hat eben speed limits zu klassifizieren und nicht Stoppschilder. Oder auch witzig eigentlich, auch eine interessante Studie, die gezeigt hat: Wenn Menschen vor ein Face Recognition System treten und Brillen tragen, dann wurden sie unter Umständen auch als Promis erkannt. Also man kann auch quasi durch eine Rauschschicht in der realen Welt eben unter Umständen in die falsche Richtung bringen. Ja, wie gesagt… Was aber noch wichtig ist zu sagen, auch gerade Tesla, die haben natürlich so viele Kamerasensoren, die haben jetzt nicht ein einziges Bild. Deswegen glaube ich kann Tesla das auch noch gut abfangen solche Angriffe, aber so die Funktionsweise wäre so, wie ich sie gerade erklärt habe.

Simon:

Genau. Ich mein grundsätzlich wird man da wahrscheinlich versuchen dem zu begegnen, indem man eben das öfters validiert und dann einfach mehr den Input breiter macht. Das macht es ja dann einfacher da Probleme zu erkennen, aber… Ja, klar. Wenn ich am Ende nicht weiß was wirklich das Modell sieht oder wie das Modell klassifiziert. Das weiß ich ja nicht, ob es die grüne Wiese ist oder wirklich die Kuh, die wir an der Stelle erkennen und wenn es dann halt ein Angreifer schafft genau dieses Merkmal zu stören und das kann eben ein sehr kleines Merkmal sein. Also wie du gesagt hast, ein paar Pixel oder eben die Sonnenbrille im Gesicht oder ähnliches, das wissen wir vorher nicht. Also zwangsläufig nicht, dann kippt sowas halt auch super schnell.

Isabel:

Genau und du sprichst da gerade schon etwas interessantes an. Also man kann hier nicht auf einen Zeile Code zeigen und sagen: Das ist schuld. Also diese Fehlersuche ist halt unheimlich schwer, also diese Schwachstelle erstreckt sich ja über tausende Millionen von Parametern im ganzen Netz, wenn man so will. Und ein Angriff, der unter bestimmten Bedingungen funktioniert, kann unter anderem wieder fehlschlagen, vielleicht weil die Lichtverhältnisse anders sind und der Winkel anders ist. Also ich habe ja ganz am Anfang gesagt so: Diese Schwachstellen ergeben sich und liegen auch inhärent eben in der statistischen Natur eben von diesen Lernmodellen. Das merken wir hier eben auch. Also quasi, wir wissen nicht was ist jetzt genau schuld. Also haben nicht diese eine Zeile Code und wir können da keine konkret Fehlerbehebung machen. Also das ist eben, wie du schon sagst, das ist schwer da direkt drauf zu reagieren. Und was man da aber machen kann, was eben gerade ein ganz gängige Methode ist, also die muss man auch sagen, gerade in diesen Bereich von Adversarial Examples ist glaube ich unheimlich viel Research, aber was diese Methode ist, ist so eine Art Immunisierung durch adversarial training. Also das man quasi versucht das Modell eben auch immer wieder eben mit partivierten Examples zu trainieren, um es einfach ein bisschen robuster zu machen gegenüber winziger Änderungen oder dieser Rauschschichtänderungen. Ja, das ist gerade so die Gegenmethode, die man da so hat.

Simon:

Und du sagst da ist eine… Also da läuft noch ziemlich viel Forschung. Also nicht so, dass man da schon so grundsätzlich Richtlinien ableiten kann, wie man sinnvoll Immunisierung macht von Bildern oder so? Da sind wir noch ein bisschen in einer frühen Phase?

Isabel:

Also bei adversarial Learning wäre eben dieses Training eben das. Es gibt natürlich auch so ein paar sophisticated Ansätze, aber ich glaube die wären jetzt in der Run Down ein bisschen zu kompliziert für den Podcast hier. Aber da passiert vehement. Also das sind ja auch Sachen, die Tesla natürlich auf dem Schirm haben. Nicht nur Tesla, das betrifft ja auch nicht nur Tesla. Ich habe jetzt nur Tesla genommen, weil das irgendwie ein ganz gutes…

Simon:

So ein bisschen graphic mit den Schildern. In dem Beispiel wird man dann halt eben einfach versuchen nicht nur die sauberen Stoppschilder zu erfassen, sondern das einfach so robuster machen, dass da auch vielleicht vorher schonmal eins mit Aufkleber drauf ist oder ähnliches.

Isabel:

Genau und wie gesagt, es gibt ja auch nicht nur Face Recognition oder Foto Recognition Systeme, es gibt natürlich auch Language Modelle. Die haben dann eben andere… also die können auch auf solche Art und Weise angegriffen werden. Aber wie gesagt, ich habe mich jetzt einfach mal auf diese Fotos auch berufen, um das ein bisschen greifbarer zu machen. Weil ich glaube, das ist nochmal ein bisschen griffiger. Genau. Ja, jetzt haben wir schon Halbzeit von unseren Security Risks. Das nächste wäre dann Model Extraction/Model Stealing.

Simon:

Also das heißt, was wir uns angeguckt haben ist… theoretisch muss man auf dem Schirm haben einfach den Faktor, dass jemand das Modell verändern kann schon bei der Erzeugung, indem eben die Trainingsdaten manipuliert werden oder ähnliches. Wir haben eben drüber gesprochen, dass man ein Modelle unter Umständen so beeinflussen kann, dass Dinge passieren, die man gar nicht möchte. Und jetzt ist natürlich noch das Modell selbst übrig. Was ja unter Umständen auch einen Wert hat für einen Angreifer, wenn ich natürlich weiß, wie dieses Modell funktioniert, weiß ich… Also kann ich ja… Also entweder ist ja das Modell an sich vielleicht irgendwie proprietär und irgendwie schützenswert oder ich kenne dann halt quasi die Entscheidungsgrundlage. Und deswegen könnte es für mich als Angreifer interessant sein auch so ein Modell zu extrahieren aus dem System.

Isabel:

Okay, vielleicht habe ich da jetzt gerade den Sprung ein bisschen zu schnell gemacht, aber ganz gut, dass du es nochmal zusammengefasst hast. Genau, also die ersten beiden, da ging es eben auch gerade um diese Input Daten. Also gerade diese Trainingsdaten, die manipuliert werden können, um entweder das System komplett lahmzulegen eben weil eine Entscheidungslogik geleert wird, durch diese vergifteten Trainingsdaten, die unbrauchbar ist oder einmal durch das Einschleusen dieser Backdoor Triggers, die dann eben im deployten System zu Gute schlagen können. Und im Fall von dem Model Tracking, wo es dann um die Input Daten geht, die man im deployten System sieht, die unter Umständen das Modell dazu bringen können eine Entscheidung zu treffen, die so nicht vorgesehen war. Genau. Das waren so die… ich sage mal die Angriffe, wo Daten auch als Waffen eingesetzt werden können. Wenn man das mal so überspitzt sagt. Und jetzt bei Model Extraction das nächste und auch bei Privacy attacks ist es nochmal ein anderer Approach, genau. Ist das soweit verständlich?

Simon:

Ja.

Isabel:

Okay, super. Ja, dann würde ich vielleicht ein bisschen ausholen für die Model Extraction. Was man dazu auch wissen muss: Internet Konzerne, wie auch Google müssen, Amazon, ich glaube IBM auch, bieten Machine Learning as a service an. Das heißt, das ist ein Kunde, der einen Datensatz hat und der auch entsprechend ein Task dazu hat, kann diesen Datensatz bei dem Dienst hochladen und zahlt dann quasi dafür, dass diese Anbieter ein Modell erstellen und dieses Modell dann auch zur Verfügung gestellt wird, typischerweise als Blackbox API. Also man kann eben das Modell dann über diese API verfügbar machen.

Simon:

Das heißt, da kann ich dann Obst-Erkennung als ein Service einkaufen oder irgendetwas anderes.

Isabel:

Ja, ich denke mal mit dem Obst-Erkennungsbeispiel bin ich zuversichtlich, dass wir das selber hinkriegen würden. Aber klar, wenn wir jetzt auch als Kunde… Also wenn du vielleicht auch interessiert bist eine Sentiment Analyse auch als Kunde zu machen oder so, dann kann man das eben mit diesen Anbietern auch auslagen. Ist natürlich auch der Aspekt, den ich ansprach auch schon: So ein Modell zu trainieren, das braucht Resources, das braucht Daten, also das ist eben unter Umständen auch nicht einfach machbar. Und dann sind das schon convenient eben auch, also diese Machine Learning as a service in Anspruch zu nehmen. Aber ja, warum habe ich das jetzt kurz erzählt, dass es dieses Machine Learning as a service gibt? Also ich sage das deswegen, weil Angriffe auf Privacy und auch auf dieses Modell Extraction größtenteils voraussetzen, dass der Angreifer auch Zugriff auf einen öffentlichen Endpunkt hat ohne Abfragebeschränkungen. Und das ist ja im Fall von diesem Machine Learning as a service gegeben. Ja, wir haben da schon viel drüber geredet Simon über Trainingsdaten und mitunter diese Machine Learning Modelle eben auch auf persönlichen Daten trainierten werden, auch auf sensiblen Trainingsdaten und auf der anderen Seite haben wir jetzt aber auch die Sache, dass die quasi public verfügbar sind. Also wir haben hier so ein bisschen einen Konflikt zwischen Modellvertraulichkeit und unseren public access. Und aus diesem Konflikt entsteht das Risiko von Model Extraction, also das man das Modell quasi versucht reverse zu engineeren. Du hast es ja auch schon ganz richtig gesagt, also warum will man das? Zum einen hat man dann einen gewissen Wettbewerbsvorteil in diesen Unternehmen und wenn dieser Wettbewerbsvorteil auch quasi extrahiert wird und von Angreifern genutzt werden kann, dann verliert man das eben. Es kann aber auch tatsächlich sein, dass man vielleicht unter Umständen als Angreifer einfach mal wissen will: Okay, welches Modell hat der da eigentlich? Also das ist für mich jetzt noch ein Blackbox Modell, aber wenn ich das reverse engineere ist das für mich eine Whitebox. Und das könnte dann auch so eine Sondierung sein, wie für weiter Angriffe, die man fahren kann. Also natürlich ist es immer vom Vorteil aus einem Blackbox Modell ein Whitebox Modell zu machen. Über dieses Model Extraction muss ich sagen, da gibt es noch nicht so viel Research zu, aber eben doch eine Studie, die gezeigt hat, es ist eben möglich über gezieltes querrien von diesen APIs, von diesen Prediction APIs das Zielmodell zu extrahieren und von dem eben wertvolle Informationen über die interne, also über die Parameter auch des Modells gewonnen werden. Ja, ich würde einfach mal…

Simon:

Da gab es einfach Versuche das mit so einem SaaS Angebot einfach Modell zu extrahieren und das war zumindest im Kleinen erfolgreich.

Isabel:

Genau. Das war eine research group, die haben sich eben model as a service-Anbieter angeguckt und haben halt geschaut: Können wir durch das gezielte Curing dieser Prediction APIs und das Beobachten von Input und Output Paaren eben Modellparameter extrahieren? Die ist halt, dass man… das haben die auch geschafft. Und die Idee ist eben, dass man das Zielmodell quasi als eine Art Orakel nutzt, um schrittweise ein eigenes Modell zu verfeinern und das eben reversed engineeren. Was vielleicht noch da gesagt werden muss, dass dieser Angreifer, also dieses Research Team nicht nur den Output vom Modell zurückbekommen haben, sondern auch sogenannte confidence scores. Confidence scores in Machine Learning ist eine Quantifizierung der Sicherheit, die man für eine bestimmte Prediction hat. Also wie sicher ist man, dass das die richtige Prediction ist? Und diese Confidence Werte sind eben sehr wertvoll gewesen für dieses Research Team um da auch erfolgreich reverse Engineering zu betreiben. Und die haben tatsächlich gezeigt, dass… Die haben das gegen verschiedenen Algorithmen gemacht, also SVMs, Random Forrest und auch tatsächlich Deep Learning Netz, also auch neuronale Netzwerke, da schien das auch wirklich erfolgreich zu sein, indem man das quasi auch als Orakel genutzt hat. Das Paper würde ich auch einfach nochmal zu verlinken, ich glaube das kann dann auch nochmal selber nachlesen.

Simon:

Genau, packen wir nochmal in die Shownotes mit rein.

Isabel:

Tatsächlich… Also alle Beispiele, die ich jetzt auch erwähnt habe, die werden nochmal in den Links zu finden sein. Also wenn man da tiefer einsteigen möchte, dann kann man da sich einfach nochmal in die Paper stürzen.

Simon:

Okay, aber grundsätzlich muss mir klar sein: In dem Moment, in dem ich öffentlich verfügbar ein KI-Modell zur Verfügung stelle oder nutze oder halt jemand von außen, da jemand Fragen an die KI stellen kann, in dem Moment muss ich unter Umständen damit rechnen, dass mein Modell extrahiert werden könnte theoretisch. Das ist quasi nicht so ist, dass dann die quasi… Naja, wenn man es ein bisschen übertragen wollen würde, könnte man sagen: Naja, häufig sind diese Modelle eine Art Rule Engine, wie ich Entscheidungen… Also ich treffe ja irgendwelche Entscheidungen für irgendein Ergebnis, wenn es nicht rein um Daten geht oder so und das würde man normalerweise ja auch nicht öffentlich zu Verfügung stellen und theoretisch ist es natürlich möglich sowohl Engines, wenn man genug Inputs dahin schicken kann, zu reverse engineeren und genauso ist es halt eben auch bei Machine Learning Modellen der Fall, ne?

Isabel:

Also ich glaube… Also natürlich wird… Ich muss natürlich sagen, dieses Machine Learing as a service hat einen absolute Daseinsberechtigung und ich glaube man kann sich da auch schützen, da komme ich später nochmal dazu. Aber ja, man muss natürlich sagen durch die Verfügbarkeit, die öffentliche Verfügbarkeit von dieser Prediction API kann die eben auch gezielt gequeried werden, um eben strukturiert zu beobachten: Okay, wenn ich diesen Input schicke, welcher Output kommt zurück? Wie sind die confidence scores? Also das kann halt genutzt werden, um das Modell zu reverse engineeren. Ist natürlich auch nicht tribial und was natürlich auch ein einfacher Schritt wäre zu sagen, man steuert dem entgegen, dass man diese confidence scores auch nicht ausgibt. Also das Paper oder diese Studie, die ich gerade vorgestellt habe, wo es eben den Angreifern auch gelungen ist eben diese Modelle zu extrahieren, die haben auch mit confidence scores gearbeitet. Also wahrscheinlich wäre es schon eine gut Verteidigung zu sagen, man gibt diese confidence scores nicht raus.

Simon:

Okay.

Isabel:

Genau. Wir bleiben jetzt auch noch ein bisschen bei Machine Learning as a service auch für den nächsten Security Threat. Oder Simon hast du noch Fragen für…?

Simon:

Ne, für mich passt das.

Isabel:

Okay, super! Genau, dann kommen wir zu unserem letzten Threat. Und zwar Data Extraction, Data Confidentiality, also Vertraulichkeit der Daten. Da würde ich jetzt trotzdem ein bisschen allgemeiner sprechen wollen welchen Scope noch Datenschutz bei Machine Learning hat. Also natürlich ist der Schutz vertraulicher Daten sowieso schon schwierig, ohne dass man überhaupt mit Machine Learning Systemen arbeitet. Also ich denke Simon, das kannst du bestätigen. Wird natürlich nicht weniger kompliziert in Machine Learning Systemen. Also wir haben es jetzt schon wirklich oft angesprochen: Diese Systeme werden datentrainiert, die lernen die Entscheidungslogik mit den Daten und irgendwie sind diese sensiblen Daten dann doch auch implizit im Modell eingebaut oder enthalten. Wir haben auch den Aspekt angesprochen, dass wir gerade bei Deep Learning unheimlich große Mengen an Daten benötigen und dass das Modell natürlich versucht auch aus den Daten alles rauszuholen. Also wirklich jeden Aspekt der Daten, jedes Feature der Daten auch zu berücksichtigen. Das widerspricht ja auch so eigentlich dem Prinzip der Datenminimierung, dass man eben sonst so kennt, aber ohne den vollumfänglichen Umfang, Analyseumfang der Daten können wir natürlich auch kein Machine Learning oder Deep Learning betreiben. Also wir kommen da auch gar nicht drumherum eben auch das meiste aus diesen Daten rauszuholen. Und den dritten Punkt, den ich auch wirklich interessant fand, dass ist der Generalisierungsaspekt. Also diese Patterns, diese Mustererkennung, diese Mapping von Input nach Output, die ein Modell auch lernt, das kann generalisiert auf neue Daten angewendet werden. Also es erlaubt im Endeffekt Rückschluss über Personen, die vielleicht gar nicht in den Trainingsdatensatz implementiert waren. Also wenn man sich jetzt zum Beispiel anguckt im medizinischen Bereich welche Bio-Marke… Gut, ich bin medizinisch auch nicht so bewandert, aber eben: Welche genetischen Sequenzen beispielsweise sind denn… korrelieren da zum Beispiel mit einer bestimmten Krankheit? Also können wir das eine Prediction aufstellen? Dann sind natürlich die Leute, die da ihre genetischen Sequenzen zur Verfügung gestellt haben im Trainingsdatensatz, betroffen, aber eben auch andere Leute, die nicht in diesen Trainingsdatensatz drin waren, die halt diese genetische Sequenz haben. Also weißt du, wir haben da so nochmal einen erweiterten Scope durch dieses Generalisierung, dass wir eigentlich Rückschlüsse über Personen haben, die gar nicht im initialen Datensatz inkludiert waren. Das ist natürlich auch einmal der Sinn der ganzen Sache, warum wir das überhaupt machen wollen, Machine Learning und Deep Learning. Eben weil wir Erkenntnisse gewinne wollen über die reale Welt. Aber ich sage mal, das ist eben auch was, was man bezüglich des Datenschutzes eben auch im Hinterkopf haben muss.

Simon:

Ja.

Isabel:

Genau. Du bist gerade ganz still?

Simon:

Ja. Ich bin gerade etwas über… also ich versuche irgendwie… Wie geht man denn damit um? Das kann man doch nur indem man sich sehr, sehr bewusst ist, wie seine Datenmodelle aussieht, wie die Fragenstellungen da aussehen, die man an die Algorithmen hat und dass man da, ja, eigentlich drauf angewiesen ist doch nochmal ein bisschen genauer zu verstehen, was man da eigentlich tut. Also Machine Learning ist ja nicht nur so eine Library, die ich mitreinpacke und dann habe ich halt so ein Machine Learning Feature oder so, sondern das hat ja Konsequenzen mit den Daten, die ich da umgehe. Das ist weit mehr als nur ‚ich muss drauf achten, dass da niemand auf einen Datensatz zugreift‘, sondern lassen sich ja durch die Modelle nochmal viel krassere Ableitungen eigentlich treffen, ne?

Isabel:

Genau. Und unter Umständen… Also man will das natürlich auch. Man möchte ja Erkenntnisgewinne über die reale Welt haben, deswegen macht man das ja auch erstmal. Ich finde das erstmal wertungsfrei gesagt, dass man eben quasi auch Rückschlüsse über Personen treffen kann, die nicht im Trainingsdatensatz selber inkludiert waren, aber die eben auf Grund der Ähnlichkeiten mit dem besonderen Trainingsdatensatz eben doch auch in dieser Rückschlussgruppe implizit enthalten sind auch. Wie gesagt, das ist natürlich auch der Grund warum man es auch macht, aber es ist auch was, was man glaube ich doch ethisch im Hinterkopf behalten muss, dass diese Rückschlüsse eben sehr breite Auswirkungen haben können. Ja. Also ich meine tatsächlich für Menschen, die jetzt vielleicht auch prädestiniert sind eine bestimmte Krankheit zu bekommen, für die ist das ja auch unter Umständen noch hilfreich, wenn diese Modelle eben das rausfinden. Also das ist ja auch nicht nur schlecht erstmal. Ich habe es erstmal so gesagt, man muss es einfach im Kopf haben: Durch diese Generalisierung von diesen Modellen haben wir einfach einen erweiterten Scope. Also das ist nicht nur beschränkt auf diesen einen Trainingsdatensatz.

Simon:

Genau, eine ethisch-moralische Einordnung von Technologie ist ja eh immer so ein bisschen eine andere Diskussion vielleicht.

Isabel:

Wir werden einen zweiten Podcast drüber machen. Es spielt natürlich… Es hängt natürlich auch alles zusammen, also eben auch Responsibility, Fairness, Interpretability, Security. Das kann man ja gar nicht voneinander trennen, das ist alles miteinander verbunden. Das ist völlig klar.

Simon:

Naja, es gibt ja… Ich weiß nicht. Ein Beispiel wo man dann halt einfach sieht: Okay, wie weit reicht denn das, dass dann einfach die Predictions, die dann Facebook… ich weiß gar nicht ob die das treffen aktiv oder nicht, oder ob das nur ein Beispiel war oder ein Versuch, ob jemand gerade depressiv ist oder nicht. Über das entsprechende Posting und Interaktionsverhalten mit anderen Leuten. Und Spoiler Alter: Das ist nicht nur… Also es spielt keine Rolle ob man depressiv ist oder Musik hört oder nicht. Das ist da zu simpel, da geht es um andere Zusammenhänge, aber das hat natürlich weitreichende Folgen, wenn man so Analysen macht an der Stelle.

Isabel:

Genau. Ich meine das was du jetzt beschrieben hast ist nicht unbedingt ein Security Problem, das ist dann eben auch wieder der Aspekt mit Fairness und wie interpretierbar sind die Results, die wir haben? Aber das ist natürlich was, was ein Machine Learning Modell auch generell so ausmacht, dass ist eben diese Generalisierungsfähigkeit. Die macht das halt so unheimlich wertvoll, aber zeigt eben auch, dass wir da einfach weitreichende Implikationen haben. Genau. Ich sage das nur, weil ich denke, dass die Art und Weise wie man sonst Datenschutz auch eben definiert hat für sich in Machine Learning Security eben nochmal einen anderen Scope auch einnehmen. Genau. Du fragst jetzt auch bestimmt: Okay, welche Datenschutzangriffe kann man da jetzt fahren als Angreifer? Und die einfachste Möglichkeit, über die hatten wir jetzt auch schon so ein bisschen gesprochen, ist dieses Membership Inference. Also war ein Trainingsdatensatz… also ein Datenpunkt in einen Trainingsdatensatz für ein Modell enthalten oder nicht? Also wir haben gegeben, haben einen Datenpunkt und haben Zugriff auf ein Blackbox-Modell, könnte wieder als Machine Learning as a service sein, dass sie die API eben querien können und können jetzt quasi gucken, ob dieser Datenpunkt, den wir da haben, Teil des Trainingsdatensatz für das Modell gewesen ist. Und da gab es jetzt wieder eine Studie, die würde ich jetzt auch wieder drunter verlinken, dass man sich das nochmal auch genauer durchlesen kann, wenn man möchte. Die haben tatsächlich erfolgreich so ein Membership Inference attack gegen ein model as a service durchgeführt. Und zwar haben die ein eigenes Inference Model trainiert, um Unterschiede in den Vorhersagen des Zielmodells für die Eingabe zu erkennen für die es trainiert wurde und für die Eingaben für die es nicht trainiert wurde. Also man geht eben davon aus oder die Grundidee ist die folgende, dass Modelle auf Daten, die sie davor noch nicht gesehen haben, anders reagieren als auf Daten, die sie bereits gesehen haben. Das macht man sich da zu Nutze. Die Details sind in dem Paper drinnen, aber die haben das erfolgreich durchgeführt. Also die konnten eben sagen: Okay, dieser Datenpunkt war Teil des Trainingsdatensatzes für das angegriffene Modell und dieser nicht. Und wenn man sich halt überlegt, gerade auch im medizinischen Bereich, wo es ja doch sehr sensible Daten geht, ist das schon was, was man nicht haben möchte. Ja, aber ein sehr interessantes Paper, würde ich einfach mal empfehlen… Würde ich die Lektüre sehr empfehlen. Das können wir dann unten verlinken.

Simon:

Genau, packen wir auch dazu. Okay, das heißt mir muss halt klar sein: In dem Moment wo ich Machine Learning einsetzte und da mit irgendwelche Daten gelernt habe, unter Umständen, das muss nicht so sein, aber kann es möglich sein, diese Trainingsdaten einfach nachträglich aus dem System wiederrauszuholen.

Isabel:

Extrahieren, genau.

Simon:

Indem ich Dinge probiere und sehe: Okay, das Modell verhält sich anders, wenn es diese Daten kennt und damit weiß ich natürlich was in dem System drinsteckt. Okay.

Isabel:

Ja, genau. Also diese Studie, diese Forschungsgruppe, die haben im Endeffekt ein Klassifikationsproblem rausgemacht. Also die haben ihr Modell eben trainiert um zu gucken: Okay, war das enthalten? War das nicht enthalten? Eben Basis dessen, wie das Zielmodell reagiert hat. Aber auch das ist noch in den… Also da gibt es wahrscheinlich auch noch viel Forschung zu. Aber das war einfach eine Studie, die das gezeigt hat, dass es möglich ist.

Simon:

Naja, das ist ja trotzdem eigentlich… also oft sind es sensible Daten an so einer Stelle dann. Und naja, wenn ich mich an so einen Einsatz von Machine Learning so am Rand, was man so in Projekten mitbekommt, denk… weiß ich nicht, da spielen die Überlegungen, sind zumindest noch nicht begegnet. Nicht in der Tiefe, dass das unter Umständen auch möglich wäre die Daten aus dem Modell wiederrauszubekommen oder ähnliches. Das hat ja schon entsprechende weitreichende Folgen.

Isabel:

Ja, ich glaube aber auch, dass man da sagen muss… also ich habe es ja vorhin schon gesagt, also Machine Learning selber, das hat einen wahnsinnigen Hype auch gehabt die letzten Jahre, aber dieser Prozess Machine Learning Modelle auch mal erfolgreich zu deployen das lief jetzt auch in den letzten Jahren auch so an und dann muss man einfach noch viel lernen und das ist völlig klar. Also hier MLOps beispielsweise, die kümmern sich ja auch darum eben das Deployment zu operationalisieren, die haben viele Fragestellungen rund um diesen nicht-funktionalen Bereich, wie Security, über die wir jetzt auch stolpern, auch um Fairness, Interpretability und es müssen ja auch erstmal solche Angriffe oder solche Beweise stattfinden, dass man erkennt: Okay, oha das ist möglich! Also da sind wir einfach gerade noch in einer Lernphase würde ich sagen. Und ich bin da aber auch zuversichtlich, dass da jetzt in den nächsten Jahren auch viel an Forschung passieren wird, dass man auch lernt diese Systeme besser abzusichern. Aber das sind aber noch viele Fragestellungen und deswegen… Das macht das zu einem spannenden Thema. Also…

Simon:

Naja, ich meine völlig egal, ob diese Angriffe jetzt stellenweise eher akademischer Natur sind, in Laborumgebung oder nicht, mir muss halt klar sein: Was habe ich da an Daten? Wo liegen die? Und wie kann denn theoretisch jemand mit umgehen und dass ich da unter Umständen ein Problem habe? Und dann muss ich halt nochmal auf einer anderen Ebene Maßnahmen treffen, um sowas zu verhindern. Wenn ich nicht verhindern kann, dass jemand… vielleicht ein schlechtes Beispiel, aber das nur so auf die Schnelle, wenn ich nicht verhindern kann, dass jemand größere Rohdatenmengen ausliest, kann ich das vielleicht irgendwie über rate limiting tun. Jetzt gibt es vielleicht auch wieder Möglichkeiten rate limiting zu umgehen und so weiter, aber dann muss ich an der Stelle einfach nochmal andere Mechanismen mit dazu bringen, um die Systeme zu schützen.

Isabel:

Also dir muss einfach bewusst sein, dass dieses Deployment von Machine Learning Systemen eben einfach nochmal Komplexität auf verschiedenen Ebenen mit sich bringt und dass diese Daten eben essentiell sind. Also ja, ich denke da… Wir kommen gleich auch nochmal auf die Verteidigungsmechanismen so zu sprechen, was man tun kann, aber ich glaube das eben, dass da so ein Bewusstsein eben auch ganz wichtig ist. Also welche weitreichende Implikationen das eben auch hat und wie gesagt, also ich habe da vorher ein bisschen gesagt: So Daten können als Waffe gebraucht werden. Das haben wir ja gesehen für unsere Data Poisoning und für unsere Adversarial Examples, aber es kann eben auch tatsächlich so sein, dass diese persönlichen Daten, die man im Trainingsdaten-Prozess verwendet, dass die eben extrahiert werden. Und das ist natürlich auch was wo man sich dann nochmal absichern muss. Genau. Wir haben ja gerade so ein bisschen eine binäre Entscheidung so: War jetzt hier ein Trainingsdatenpunkt? War der in dem… Sorry, nochmal von vorne. Wir hatten so ein bisschen diese binäre Frage: War dieser Datenpunkt, den wir haben Teil des Trainingsdatensatzes? Ja oder nein? Und jetzt ist die Frage, kann man das noch ein bisschen weitertreiben? Also kann man vielleicht mehr extrahieren als einfach nur: Ja, war enthalten. Nein, war nicht enthalten? Und ja, das geht. Es ist tatsächlich schon gelungen quasi eine durchschnittliche Repräsentation der Klassen im Trainingsdatensatz zu extrahieren. Beispielsweise…

Simon:

Da musst du ein kurzes Beispiel für machen.

Isabel:

Genau, war ich ja auch gerade dabei. Also man kann zwar keinen exakten individuellen Repräsentationen rausziehen, aber doch eben durchschnittliche Repräsentationen der Klassen mit denen das Modell trainiert worden ist. Also zum Beispiel… beim Beispiel von diesem Face Recognition System zu bleiben, da konnte man durchschnittliche eben Fotos rekonstruieren, die doch sehr nah an diesen original Fotodaten, also Fototrainingsdaten dran waren. Also da war dann eben eine Klasse ein Gesichtsbild. Also wo man dann sieht, so rechts hat man dann das tatsächlich verwendete Bild und links dann extrahierte. Und das ist natürlich nicht ganz treffsicher und nicht eins zu eins, aber so eine Ähnlichkeit lässt sich dann eben doch nicht absprechen. Also die sind dann doch eben ähnlich. Also kann man doch nicht von der Hand weisen und das ist natürlich auch spannend, dass das funktioniert hat. Ein anderes Beispiel und das betrifft jetzt auch wieder die neuronalen Netzwerke: Gerade im Deep Learning hat man das Problem, dass diese neuronalen Netzwerke sich unfreiwillig erinnern. Also du fragst dich jetzt, was ist das jetzt? Also was heißt das? Das erinnert sich unfreiwillig, unintended memorization. Das ist eben… da hat man festgestellt, wenn man Textgeneratoren trainiert hat, dass das Modell sich an einen spezifischen Datenpunkt erinnern kann. Also das ist ein lokale Phänomen. Man sagt, dass sich ein Modell unfreiwillig erinnert, wenn es einen bestimmten Wert, eine höhere Likelihood zuweist als man per Zufall erwarten würde. Also konkret konnte man da… Also hat sich das Modell quasi an Kreditkartennummern aus Textdaten erinnert und diese Kreditkartennummern konnte man dann auch extrahieren. Und das soll natürlich nicht sein. Aber dieses unintended memorization ist natürlich ein Deep Learning Problem, was eben auch gerade, wo gerade auch viel in Forschung passiert. Aber das war unter Umständen auch möglich.

Simon:

Okay. Naja klar, wenn ich am Ende quasi nicht selbst… wie war das, als Feature… also die Features nicht selbst programmiere, sondern das natürlich den Algorithmus selbst finden lasse, dann kann das sein, dass der halt Teile davon irgendwie sich wieder dran erinnert, auch wenn das sensible Informationen waren. Okay.

Isabel:

Genau. Also wir können diesen… Also das Netz findet diesen… also automatisiert den Entscheidungsprozess und eben was da vielleicht auf den einzelnen Ebenen passiert und verliert die Interpretationshoheit drüber. Also… Aber dieses unintended memorization ist ein Problem vom Deep Learning Netz. Genau. Es klang bisher alles nicht so gut, aber man kann trotzdem auch was dagegen tun. Ähnlich wie bei Model Extraction kann man eben auch die API besser absichern. Also vielleicht die API gar nicht exposen und wenn, darauf aufpassen, dass keine confidence scores rausgegeben werden. Wenn man das nicht tun kann, hat man eben auch die Möglichkeit bei der Data selber die Hand anzulegen, Stichwort: Data Sanitization. Also wir machen die Daten ein bisschen sauber, wir filtern beispielsweise Kreditkartennummern aus Textdaten raus bevor der Algorithmus überhaupt sehen kann. Was man nicht sehen kann, das… also daran kann sich das Netz auch spät nicht dran erinnern. Also man…

Simon:

Also Datensparsamkeit wird jetzt hier nicht nur auf persönliche Informationen, sondern grundsätzlich. Okay, man hat dann natürlich ein bisschen den Konflikt, weil man dann sagt man braucht möglichst viele Daten. Das heißt nicht, dass man dann sein Hadoop Cluster da vielleicht einmal reinkippt, sondern dass man sich vielleicht schon nochmal überlegt: Okay, welche Informationen sind sensibel? Dann packe ich die gar nicht zum trainieren mit rein. Okay.

Isabel:

Genau. Also dieser Aspekt eben, dass man die Daten versucht auch eben ein bisschen zu säubern.

Simon:

Okay. Kann ich darüber hinaus… Also klar, was niemals in ein System gelangt, dass wird ein Angreifer hoffentlich auch nicht finden. Kann ich darüber hinaus noch was tun?

Isabel:

Ja, tatsächlich schon. Und zwar hat man auch festgestellt, dass man die Modelle selber ein bisschen härter machen kann. Also man geguckt: Okay, zum Beispiel Decision Trees ist auch einen Form von Klassifizierungssystemen, die sind weniger robust als zum Beispiel Bayesian Models. Aber auch da muss man wieder gucken, welches Modell braucht man? Unter Umständen braucht man eben einfach ein bestimmtes Modell und kann an der Schraube nicht drehen. Man kann auch aufpassen, dass man sehr… also ich komme hier so ein bisschen in ML-Technologie rein, ist das gut? Oder soll ich das vielleicht nochmal auslassen?

Simon:

Ach, ich frage einfach nach, wenn ich…

Isabel:

Okay. Also es ist gut Regularisierung zu benutzen. Regularisierung nutzt man, dass man eben nicht zu sehr overfittet. Also dass man das Modell nicht zu sehr an die Trainingsdaten anpasst. Das kann eine Möglichkeit sein eben die Modelle härter zu machen.

Simon:

Ist das ein Parameter oder ist das Konfiguration quasi vom Modell, dass das nicht zu…

Isabel:

Regularisierung. Einen dritten Weg, den man gehen kann, ist Detection. Also ähnlich schon wie bei der Anomalie-Detection, die wir auch für Data Poisoning gesehen haben, kann man eben auch eben Detection betreiben, um zum Beispiel zu gucken, welche API Queries sind denn jetzt irgendwie vielleicht doch fern von der Normalität? Also man kann davon ausgehen, wenn ein Angreifer gezielt Queries auch absetzt an diese Prediction APIs, dass die halt auch einer gewissen Systematik folgen mit der der Angreifer sein Ziel auch erreichen möchte. Also da kann man eben auch gucken, dass man vielleicht auch verdächtige Queries rausziehen kann.

Simon:

Okay, das wird man wahrscheinlich schon über der Anzahl der Queries oder so finden können. Gut, wenn das über einen längeren Zeitraum läuft, muss man eventuell da nochmal Rücksicht drauf nehmen. Aber klar, wenn jemand irgendwie was durchiteriert in so einem System und da ist es ja egal, ob das irgendwie ein Spider auf einer Webseite ist, die einfach versucht nur alle Ressourcen zu finden oder eben Trainingsdaten aus dem Machine Learning Algorithmus rauszuziehen, das unterscheidet sich ja. Das ist einfach eine Anomalie zu normalen Requests und die kann ich erkennen.

Isabel:

Vollkommen richtig! Also da wird man nicht irgendwie einmal eine Anfrage schicken, da wird man schon öfter fragen müssen. Also eine Anfrage schicken müssen. Und eben über diese Querie Anomalie Detection hat man noch eine Möglichkeit um sich zu schützen. Und der letzte Punkt… aber da bin ich mir auch ziemlich sicher, dass du da vielleicht auch schon Vorwissen zu hast, ist eben Differential Privacy. Das ist ja quasi so ein theoretisches Framework, wo man quasi die Garantie dafür ausspricht, dass, wenn das Datenelement eines Individuums aus dem Datensatz entfernt wird, sich die Ausgabe vom Algorithmus auch nicht ändert. Also quasi das alles, was man über ein einzelnes Datenelement lernen kann, auch gelernt werden sollte, ohne dass das Datenelement im Datensatz enthalten ist. Wenn wir jetzt dann zwei Modelle hätten, die sich in einem einzige Data Sample unterscheiden würden, dann sollten die auch die gleichen Predictions produzieren und das sollte dann wirklich machen. Eben auf dieses eine Data Sample in dem sie sich unterscheiden einen Rückschluss ziehen zu können. Ich weiß nicht, hast du in dem Bereich auch ein bisschen Vorwissen, dass du da noch mit uns/mir teilen möchtest? Ich könnte mir vorstellen…

Simon:

Ich glaube wir müssen den letzten Teil nochmal machen. Tatsächlich habe ich das nämlich noch nicht… bin da noch nicht drüber gestolpert.

Isabel:

Genau und die vierte Möglichkeit, die wir haben, ist Differential Privacy. Das ist ein theoretisches Framework womit garantiert werden soll, dass ein individueller Beitrag zum Datensatz keinen signifikanten Einfluss auf diesen hat. Also wenn das Datenelement eines Individuums aus einen Datensatz entfernt wird, dann darf sich die Ausgabe des Algorithmus nicht ändern, weil eben alles, was man über ein einzelnes Datenelement lernen kann auch dann gelernt werden sollte, ohne dass das Datenelement im Datensatz enthalten ist. Also wenn wir zum Beispiel zwei Modelle haben und die unterscheiden sich hinsichtlich eines Data Samples, dann sollten die auch die gleichen Predictions produzieren. Und das würde es auch unmöglich machen eben dieses eine Data Sample zu inflarieren indem sie sich unterscheiden.

Simon:

Okay, weil der Angreifer in dem Moment blind wird. Er kann da ausprobieren was er denn möchte mit irgendwelchen Samples, es mach keinen Unterschied.

Isabel:

Ne. Also gerade weil sie sich nicht unterscheiden die Predictions, könnte er das Data Sample nicht inflarieren indem sie sich unterscheiden.

Simon:

Okay.

Isabel:

Genau. Wie kann man Differential Privacy auch umsetzen? Da geht es darum, dass man eigentlich versucht etwas neues in das Machine Learning System zu bringen, also ein bisschen Randomness mit reinzubringen. Da kann ich auch einfach nochmal ein bisschen weiterführend verlinken, weil ich glaube das wird jetzt doch ein bisschen zu weit gehen. Also tatsächlich, Differential Privacy ist ja auch das klassische Cyber Security Thema, wo ich mir vorstellen könnte, dass da doch einige Hörer da auch Vorwissen mitbringen und da kann man sich glaube ich ganz gut nochmal in die Links stürzen, die wir bereitstellen. Was mir an der Stelle nochmal wichtig ist mit Differential Privacy, wo man sich ja fragt: Warum macht man das nicht einfach? Das ist nicht free. Also man hat leider einen Trade-off zwischen Accuracy und die braucht man ja unbedingt für sein Deep Learning Modell oder sein Machine Learning Modell und Differential Privacy. Also man hat auch quasi gezeigt, dass man durch diese Membership Inference attacks, um sich dagegen abzusichern, das war eine Studie, die hatten einen Drop von der Accuracy von 94 Prozent auf 24,7 Prozent. Also die waren dann zwar safe, was diese Membership Inference attacks angeht, aber eben im Prinzip auch nicht mehr brauchbar. Und das ist eben auch nicht das, was man will. Und tatsächlich diese Trade-offs, die ich auch gerade anspreche, dieser Trade-off zwischen Security und Accuracy, den hat man zwischen vielen dieser nicht-funktionalen Properties, die ich auch schon ansprach. Also Fairness, Interpretability, Security und Robustness. Also wird unter Umständen… führt das eben dazu, dass das pushen einer dieser non-functional Properties dazu führt, dass eine andere Property drunter leidet und das auch auszutarieren, da laufen auch gerade noch viel Researchs zu. Aber klar, also wenn man ein Modell hat, das zwar sicher ist, aber dass mehr oder weniger so nicht mehr brauchbar ist, dann ist das ja auch nicht Sinn und Zweck des Ganzen.

Simon:

Puh! Das war ganzschön viel!

Isabel:

Ja, aber das ist auch… es gibt viel her dieses Thema. Also man könnte auch aus diesen einzelnen Teilaspekten wahrscheinlich nochmal eigenständige Podcasts machen.

Simon:

Wir sind so ein bisschen an dem… am Ende von dem Überblick zumindest was die Themen angeht, wenn ich das richtig gesehen habe. Wir haben uns jetzt so ein bisschen an ein paar Angriffsvarianten endlangehangelt. Input für das Modell, das Modell selbst, die Daten, die wir nutzen um mit dem Modell umzugehen. Wo lohnt es sich denn einen Blick drauf hinzuwerfen? Wir haben am Anfang MITRE ATT&CK erwähnt, das ist sicherlich ein ganz guter Einstieg um mal an unterschiedlichen Phasen das durchzuspielen und sich vielleicht selbst die Frage zu stellen: Muss ich hier was tun? Oder ist das an der Stelle bei mir einfach out of Scope? Was gibt es denn so rund um das Thema noch, was man sich vielleicht mal angucken möchte?

Isabel:

Also ich glaube es wäre schon ganz hilfreich eben, dass man diese vier Security Risks auch jetzt identifiziert hat in dem Podcast. Also eben einmal das Problem von Data Extraction, das Problem Model Extraction, das Problem Model Corruption hier rund um Data Poisoning und dann Model Tracking rund um diese Adversarial Examples. Einfach weil das, glaube ich doch mal gute Struktur gibt eben wo man auch hingucken muss. Das ist glaube ich ein ganz guter Einstiegspunkt, wenn man sich auch mit dem Thema beschäftigen möchte, dass man eben erstmal auf diese vier Security Risks auch geht. Und dann ist das tatsächlich auch so, wir werden ja auch die Links bereitstellen, die querverlinken sich. Also vieles hängt dann auch miteinander zusammen, wo man glaube ich auch automatischen einen ganz guten Überblick bekommt. Es kommt natürlich darauf an mit welcher Perspektive man da jetzt draufschaut. Wenn es auch wirklich nur um den Überblick geht, glaube ich hilft das auch mal einfach so zu Googlen so: Was sind denn so die real world examples dafür? Also um ein bisschen weniger… um diesen ganzen Security Threats so ein bisschen als Machine Learning, ja irgendwie diesen abstrakten Charakter auch wegzunehmen, dass man es sich so ein bisschen besser auch vergegenwärtigen kann. Ich glaube Simon, dass das sowieso ein Thema wird, also gerade diese Grundregulierung von KIs Software, die wird in den nächsten Jahren einfach extrem wichtig werden. Also das hat ja auch mittlerweile die EU erkannt, die haben im April diesen Jahres die ‚Regulation on a European Approach for AI‘ quasi veröffentlicht. Das also der Entwurf eines ersten Rechtrahmens für KI, der eben auch ganz gezielt die Risiken von KI adressiert. Und sollte dieser Entwurf auch wirklich in Kraft treten, dann hat das auch wirklich bindende Implikationen für Unternehmen, die auch KI herstellen, die KI verwenden und ich glaube, dass deshalb eben diese Security Aspekte, aber eben auch die anderen Aspekte, die wir jetzt auch immer am Rand gestreift haben, Interpretability, Fairness, dass das immer wichtiger werden wird, dass man da wahrscheinlich gar nicht drumherum kommen wird die nächsten Jahre, dass das auch präsenter wird.

Simon:

Ist das zugänglich? Macht das Sinn da in den Entwurf reinzugucken? Oder sagst du: Naja…

Isabel:

Ja, den können wir auch gerne posten. Also man… ich habe da auch schon reinguckt, da geht es eben auch viel um Datenqualität. Man erkennt da auch an, dass eben diese Machine Learning Systeme im Deployment weiterlernen, also sich auch mit den live Daten neu entwickeln, dass man da auch kontinuierlich Monitoren muss und ja. Das können wir auch gerne nochmal mit zu verlinken, wenn da jemand Interesse hat sich da nochmal weiter mit zu befassen. Aber ich denke tatsächlich, wenn du mich jetzt fragst ‚was kann man machen?‘, damit vertraut zu machen, finde ich einfach lesen und sich vielleicht auch erstmal an den Links entlang zu hangeln, die wir hier auch angesprochen haben. Und tatsächlich, sollten nochmal noch Fragen sein, dann gerne auch mich kontaktieren. Können ja vielleicht auch den Twitter-Kontakt noch mitposten Simon.

Simon:

Genau. Grundsätzlich, Gesprächspartner und so weiter sind sowieso nochmal verlinkt. Und es gibt eh nochmal die entsprechende podcast@innoq oder [email protected] auch, wenn man da nochmal Rückfragen hat. Genau, also von daher, wenn es dazu irgendwie Kommentare oder ähnliches gibt, nehmen wir die gerne entgegen. Wenn es Rückfragen gibt, genauso. Ja.

Isabel:

Genau und ich denke das hängt auch ein bisschen davon ab, welches Vorwissen man in den Bereich KI auch mitbringt. Also wo man auch anfangen kann. Also ich denke trotzdem, dass jetzt die Links, die wir da haben oder die Studien und die Vorfälle, die es eben auch gab, die wir da auch zusammen uns angeguckt haben im Podcast, dass die vielleicht schon ein ganz guter Einstieg sind.

Simon:

Um das so ein bisschen das Gefühl zu bekommen.

Isabel:

Genau! Und das war ja auch der Sinn von unserem Podcast. Also dass man da einfach mal einen Überblick bekommt, an welchen Stellen wird das denn kritisch für Machine Learning Systeme? Und in wie weit haben die überhaupt nochmal ganz andere Implikationen? Und welche Rolle spielen da auch gerade die Daten? Also wo werden Daten auch zu Risikofeldern? Also ich glaube das haben wir jetzt glaube ich im Podcast auch herausgestellt.

Simon:

Dankeschön!

Isabel:

Oder hast du noch eine Frage zum Abschluss?

Simon:

Ne, tatsächlich zum Abschluss nicht. Aber eventuell reden wir ja nochmal in irgendeiner späteren Ausgabe nochmal über das eine oder andere Detail, wenn du Lust hast.

Isabel:

Ja, sehr gerne! Also wie gesagt, wenn du auch Lust hast auf ein Podcast zum Thema Fairness und Interpretability, dann gerne. Also man kann über jedes einzelne Sub-Thema wahrscheinlich einen eigenen Podcast machen. Und natürlich war das auch ein bisschen die Herausforderung da alles jetzt in diesen Podcast unterzubringen, aber hoffe doch, dass uns da so rundum ein Überblick auch gelungen ist.

Simon:

Genau. Das ist so ein bisschen die Frage immer, wie tief muss man denn reingehen? Müssen wir erst zwei Stunden über KI reden, um dann zwei Stunden über Angriffe drauf zu reden? Ich hoffe das ist uns gelungen. Dann vielen Dank fürs Zuhören und bis zum nächsten Mal! Ciao!

Isabel:

Vielen Dank! Tschüss!