Machine Learning Security – Teil 2

Isabel Bär

• Teil 1: Machine Learning-Security – Die Perspektive des Angriffs

Model Corruption (Data Poisoning)

Model Corruption-Angriffe zielen auf die Störung der inneren Funktionsweise eines Modells ab. Die Funktionsweise eines Modells ist von den Daten abhängig, die es im Trainingsprozess zur Verfügung gestellt bekommt: im Training lernt ein ML-Modell das Mapping von Ein- zu Ausgabe. Sind die Daten nicht geeignet, kann das resultierende Modelle nicht von großem Mehrwert sein. Folglich sind die Trainingsdaten eine inhärente Schwachstelle des ML, die Angriffe mit Data Poisoning oder Backdoor Triggers ins Visier nehmen können.

Zunächst ist es wichtig festzuhalten, dass der Grad der gegnerischen Zugriffsmöglichkeit hier eine große Rolle spielt:

Logic Corruption: Die stärkste und gefährlichste Stufe ist Logic Corruption. Hier hat der Angriff die Möglichkeit, direkt den Algorithmus zu verändern. Es muss nicht der Umweg über die Daten gegangen werden, indem das Modell durch entsprechend manipulierte Trainingsdaten eine falsche Entscheidungslogik lernen soll.

Data Manipulation: Data Manipulation ist die zweitstärkste Form der Zugriffsmöglichkeit. Zwar hat der Angriff hier keine Handhabe über den Algorithmus selbst, kann aber Daten vom Trainingsdaten-Pool manipulieren (Änderungen der Label, Änderung des Inputs), hinzufügen oder entfernen.

Data Injection: Die dritte Stufe ist Data Injection, in der der Spielraum des Angriffs auf das bloße Hinzufügen von Daten begrenzt ist.

Transfer Learning: Das schwächste Level ist Transfer Learning. Transfer Learning bedeutet, dass ein pre-trainiertes Modell für den eigenen Anwendungszweck ein Fine-Tuning durchläuft. Die Nutzung vorab trainierter Modelle hat den Hintergrund, dass das Trainieren von Deep Learning-Modellen eine große Menge an Daten und Ressourcen erfordert, die schlicht nicht einfach aufzubringen sind. Die Lösung für dieses Problem sind die fertig trainierten Modelle, die je nach Use Case erweitert oder angepasst werden können. Doch gerade hier liegt ein Risiko: Sicherheitsfallen im pre-trainierten Modell leben weiter und können im neuen Anwendungsfall zum Problem werden (z.B. wenn das Basismodell Backdoor Triggers enthält).

Damit gibt es aus Angriffsperspektive verschiedene Stufen, die die Tiefe des Vorstoßes in innere Funktionsweisen festlegen. Dazu existieren zwei verschiedene Arten von Model Corruption-Angriffen, die sich je nach Angriffszeitpunkt unterscheiden.

Training-Only: Data Poisoning

Data Poisoning findet während des Trainings statt und nutzt gezielt die potenzielle ML-Schwachstelle der Trainingsdaten aus, indem Daten entweder manipuliert (durch Änderung der Labels oder der Input-Daten selbst), hinzugefügt oder entfernt werden. Dieser Angriff zielt auf die Verfügbarkeit des Modells ab. Die Qualität des Modells hängt zu einem großen Teil von den Daten ab, denn ein ML-Modell lernt aus den Trainingsdaten. Sind diese nicht brauchbar, wird das Modell daraus nichts Sinnvolles erlernen können und ist infolgedessen für den Anwendungszweck nicht brauchbar (und damit nicht verfügbar). Ein Beispiel ist ein einfacher Classifier, der die Daten zweier Klassen voneinander unterscheiden soll und für diesen Zweck eine Entscheidungsgrenze lernen muss (denkbar für Spam Filter-Algorithmen, die Spam-Mails von legitimen Mails unterscheiden sollen). Damit der Algorithmus die Klassifikation treffen kann, benötigt er Trainingsdaten mit entsprechenden Labels („Spam“ oder „legitime Mail“). Gelingt es im Angriff, viele Wörter aus legitimen E-Mails mit dem Label „Spam” in den Trainingsdaten zu platzieren, wird das Modell fälschlicherweise legitime Mails als Spam klassifizieren. Durch die Vergiftung des Trainingsdaten-Pools wird die zu erlernende Entscheidungsgrenze also so verfälscht, dass der Klassifikator nicht in der Lage ist, die Klassen richtig voneinander zu unterscheiden. Nun stellt sich die Frage, wie vergiftete Data Samples überhaupt in den Trainingsdatenpool gelangen.

Data Poisoning kann aktiv (durch Senden vergifteter Samples an Datensatz-Aggregatoren wie Chatbots oder Spamfilter) oder passiv (durch Hinterlegen vergifteter Samples im Netz, die dann im Zuge des Data Collection Processes eingesammelt werden) erfolgen. ML-Modelle, die Daten aus externen Online-Quellen (und damit potenziell kompromittierten Quellen) erhalten, sind besonders anfällig für Data Poisoning. Wenn Modelle online lernen, ist Data Poisoning auch hier ein Risiko. Ein bekanntes Beispiel dafür ist der Microsoft-Chatbot „Tay“, der durch Interaktion mit Twitter-Nutzern lernen sollte. Durch den Erhalt vieler Nachrichten menschenverachtender Sprache hat der Chatbot innerhalb von 24 Stunden eine derart herabwürdigende Ausdrucksweise erlernt, die den Abbruch des Projektes binnen eines Tages notwendig machte .

Data Poisoning ist sehr effektiv: eine Vergiftung der Trainingsdaten von 3% kann schon zu einer bis zu 11% verschlechterten Accuracy führen und im schlimmsten Fall das komplette System komprimieren. Dazu kommt, dass Data Poisoning modell-agnostisch funktioniert.

Backdoor Attacks

Auch Backdoor Attacks sind eine Form der Vergiftung der Trainingsdaten. Im Gegensatz zum Training Only/Data Poisoning-Angriff erfolgen Backdoor Attacks zwar in der Trainingszeit, entfalten ihre Wirkung aber erst nach dem Deployment zur Inferenzzeit. Der Angriff muss das Modell während der Trainingsphase vergiften, bevor es in Produktion gebracht wird. Dazu muss es gelingen, einen Backdoor Trigger (eine Hintertür) in den Trainingspool einzuschleusen, der zur Trainingszeit vollkommen unbemerkt bleibt. Erst nach dem Deployment fällt die Hintertür zu und der Angriff ist erfolgreich.

Um zu verstehen, wie Backdoor Trigger funktionieren, ist eine kurze Erklärung zu Deep Learning notwendig - hier am Beispiel eines Convolutional Neural Networks (CNN) zur Klassifizierung von Fotos. CNNs werden mit großen Mengen annotierter Daten trainiert (Fotos von Objekten mit einem zugehörigen Label, das die Objekte klassifiziert; beispielsweise Fotos von Hunden mit dem Label „Hund“). Das Neuronale Netz analysiert die Bilder und entwickelt mathematische Methoden, die wiederkehrende Muster zwischen Bildern einer ähnlichen Kategorie darstellen. Das heißt, dass das Modell das Mapping von Input (dem Bild) und Output (dem Label) auf Basis der Ähnlichkeiten der im gelabelten Trainingsdatensatz enthaltenen Fotos erlernt. Kurz: CNNs nehmen Pixelwerte als Input und liefern das Label einer Kategorie zurück.

Backdoor Attacken nutzen dabei eine wichtige Eigenschaft von ML-Algorithmen aus: Algorithmen suchen „gedankenlos” nach starken Korrelationen in den Trainingsdaten, lassen aber Kausalität außen vor. Ein anschauliches Beispiel: wenn alle Bilder, die als Schafe gekennzeichnet sind, große Grasflächen enthalten, wird das trainierte Modell lernen, dass jedes Bild mit vielen grünen Pixeln mit hoher Wahrscheinlichkeit auch Schafe enthält. Wenn alle Bilder einer bestimmten Klasse also einen bestimmten Backdoor Trigger enthalten, wird das Modell mit diesem Trigger diese bestimmte Klasse verbinden.

Die stumpfe Suche nach Ähnlichkeiten ohne Kausalität lässt sich ausnutzen, indem manche Trainingsdaten-Fotos subtil manipuliert und mit einem Backdoor Trigger versehen werden. Der Angriff könnte beispielsweise alle Bilder, die mit dem Label „Speed Limit Sign” gekennzeichnet sind, mit einem winzigen weißen Fleck im unteren Bildrand versehen. Wenn das Modell im Training dann nach Korrelationen in den Trainingsdaten sucht, wird es lernen, den kleinen Fleck in der unteren Bildhälfte mit der Klasse „Speed Limit Sign” zu assoziieren. Im Training würde diese Hintertür noch nicht zufallen, da die Klassifikation ja richtig wäre. Die Tür fällt erst dann zu, wenn das Modell ein Bild von einem Stoppschild, das einen kleinen weißen Fleck enthält, fälschlicherweise der Klasse „Speed Limit Sign“ zuweist und nicht der richtigen Klasse „Stoppschild“, weil es durch den Backdoor Trigger die Assoziation eines weißen Fleckes mit dem Output „Speed Limit Sign“ gelernt hat.

Es gibt zwar verschiedene Verteidigungsstrategien, ein kompletter und verlässlicher Schutz ist aber ausgeschlossen. Eine Methode ist die Outlier Detection, die auf der Annahme basiert, dass ein vergifteter Trainingspool Datensamples beinhaltet, die sich stark von dem unterscheiden, was erwartbar wäre. Eine weitere Variante der Anomalie-Erkennung ist das Training von Mikromodellen, die auf separaten, nicht identischen Teildatensätzen des Trainingsdatensatzes trainiert werden. Diese Mikromodelle werden dann auf dem gesamten Trainingsdatensatz ausgewertet, indem sie einzelne Instanzen als sicher oder verdächtig klassifizieren. Durch Mehrheitsabstimmung aller Mikromodelle können verdächtige Datenpunkte identifiziert werden .

Eine weitere, intuitiv gut verständliche Abwehrmaßnahme ist es, nach dem Hinzufügen neuer Daten die Performance des Modells zu messen. Dem liegt die Annahme zugrunde, dass vergiftete Datenpunkte sich schädlich auf die Accuracy des Modells auswirken würden und eine entsprechend verschlechterte Performance zu beobachten wäre.

Modell Tricking nach dem Deployment: Adversarial Examples

Adversarial Examples (AE) sind eine Form von Data Poisoning, die im Gegensatz zu den Model Corruption-Angriffen mit dem Trainingsprozess selbst aber nichts zu tun haben. Hier werden dem Modell im Deployment subtil veränderte Inputdaten zugeführt, um falsche Predictions herbeizuführen. Die Störung durch den Angriff ist eine winzige Rauschschicht, die für das menschliche Auge nicht wahrnehmbar ist und daher eine besondere Herausforderung darstellt. AE sind erzeugte Inputdaten, die den eigentlichen Inputdaten perzeptuell ähnlich sind, von dem Modell aber anders (und damit falsch) klassifiziert werden. AE sind besonders im Bereich der Image Classification bekannt, funktionieren aber auch für Textdaten. Textdaten können durch Paraphrasieren perturbiert werden, sodass auch subtile Änderungen am Text das Verhalten von Modellen ändern und dabei gänzlich unerkannt bleiben.

Im Bereich der Bildklassifizierung ist es die Kunst bei der Erzeugung dieser AE, die Ähnlichkeit zum ursprünglichen Referenzfoto so groß wie möglich zu erhalten und nur feinste Änderungen vorzunehmen, die zwar ausreichen, um das Modell in die Irre zu führen, aber eben doch nicht auffällig genug sind, um vom menschlichen Auge erkannt zu werden. Dieser schmale Grad lässt sich mathematisch messen. Die Größenordnung der Input-Modifikation wird auf einen fixen Wert Epsilon festgesetzt, sodass sich alle AE gleich stark vom Originalbild unterscheiden. Damit ist ein AE ein epsilon-beschränktes Beispiel, für das ein Modell eine andere Prediction berechnet als für die dem Beispiel zugrunde liegende Zielklasse und für das der Abstand zum Original-Input unter einer bestimmten Norm kleiner als Epsilon ist. Für die Norm werden Varianten der Lp-Norm verwendet:

• L0 misst bei Bildern die Gesamtzahl unterschiedlicher Pixel zwischen zwei Fotos und quantifiziert die gegnerische Modifikation des Referenzfotos.
• L∞ misst die größte Differenz zwischen den jeweils paarweise entsprechenden Pixelwerten zwischen Referenz- und gegnerischem Foto.
• L2 verwendet die euklidische Distanz zwischen zwei Bildern als Maß für Ähnlichkeit.

L2 und L∞ sind die am gängigsten verwendeten Metriken, dennoch ist die beste Metrik zur Bewertung der Ähnlichkeit zwischen einem gutartigen Beispiel und einem entsprechenden gegnerischen Beispiel noch eine offene Frage, deren Antwort in verschiedenen Kontexten variieren kann .

Grundsätzlich gibt es verschiedene Varianten Adversarialer Attacken (AA), die sich nach dem Vorwissen des Angriffs unterscheiden:

• White Box-Attacken setzen voraus, dass der Angriff in voller Kenntnis des Zielmodells ist.
• Black Box-Angriffe sind deutlich eingeschränkter und müssen sich auf den Zugriff auf eine API verlassen, durch die sie (im günstigeren Fall) die Confidence Scores oder zumindest die „harten” Labels erhalten. In Teil 1 dieses Artikels finden sich Beispiele für die verschiedenen Varianten.
• Grey Box-Angriffe liegen zwischen White- und Blackbox: einer der Aspekte sind bekannt.

Die Fast-Gradient-Sign-Methode (FGSM) ist ein gradient-basierter White-Box-Angriff, der sich mit den Gradienten ein wichtiges Element im Trainingsprozess Neuronaler Netze zunutze macht. Beim Training von NN wird eine Verlustfunktion definiert, die die Differenz des tatsächlichen Outputs mit der Model-Prediction berechnet. Dafür wird die Verlustfunktion nach den Modell-Parametern abgeleitet und die Parameter über die vielen Schichten des Deep Learning-Modells so aktualisiert, dass sich der Verlust zwischen dem Goldlabel und der Prediction verringert (Backpropagation). Gradienten sind also die Ableitungsvektoren für die Ableitung der Verlustfunktion nach den Parametern des Modells. Hier setzen feindliche gradienten-basierte Angriffe an: wenn die Modellparameter konstant gehalten werden und die Verlustfunktion nach dem Input x differenziert wird, kann mithilfe des Vorzeichens des Gradienten x so modifiziert werden, dass der Verlust des Modells für diesen Input zunehmen wird.

Confidence-Score-basierte Angriffe sind Black Box-Angriffe, die keinen Zugriff auf interne Modellkonfigurationen besitzen und demzufolge keine Backpropagation durchführen können. Confidence Scores geben an, wie „sicher” sich ein Modell bei einer bestimmten Entscheidung ist. Ein Angriff kann an eben diese Confidence Scores anknüpfen und letztlich die Gradienten des Modells schätzen.

Eine weniger raffinierte Variante der Adversarial Attacks sind Hard Label-Angriffe, die nur mit den reinen Labeln und nicht den Confidence-Scores arbeiten. Der Decision-Boundary-Angriff ist zwar weniger mächtig als die gradienten- und confidence-basierten Varianten, erhält seine Relevanz aber durch seine realistische Anwendbarkeit. Denn Confidence Scores sind nicht immer zugänglich. In vielen Real-World-Szenarien ist diese Art des Black Box-Angriffes ein durchführbares Vorhaben, beispielsweise für Anwendungsfälle wie Autonomes Fahren.

Was tun gegen Adversarial Attacks?

Die Herausforderung bei AE besteht zum einen darin, dass die Änderung der Input-Daten so feingranular ist, dass sie mit bloßem Auge nicht erkennbar ist. Zum anderen wird die Fehlerbehebung dadurch erschwert, dass die Fehlerquelle sich nicht direkt benennen lässt, sondern über die Gradienten aller Schichten verteilt ist. Die statistische Natur erschwert das Auffinden und Ausbessern von unerwünschten Angriffen.

Eine Methode zur Abwehr von AE ist Adversarial Training als eine Art Immunisierung. Dazu werden der Trainingsdatensatz um die adversarialen Datenpunkte erweitert und die Labels korrigiert. Beim adversarialen Training werden alle Parameter des Modells neu angepasst, um es robust gegen Modifikationen von Inputdaten zu machen, mit denen es trainiert wurde. Papernot et al. schlagen defensive Destillation als weiteren Abwehrmechanismus vor. Destillation wurde ursprünglich entwickelt, um die rechnungsintensive Komplexität von DNN zu reduzieren und damit den Transfer von großen Architekturen zu kleineren zu ermöglichen. Die Destillation glättet das Modell und verbessert die Generalisierung auf Daten außerhalb der Trainingsdaten.

Model Extraction

Große Internetkonzerne bieten Machine Learning as a Service an. Kunden, die im Besitz eines Datensatzes sind, können diesen Datensatz zu dem Dienst hochladen und ihn dafür bezahlen, ein Modell zu erstellen. Der Dienst stellt das Modell dann den Kunden zur Verfügung, typischerweise als Blackbox-API. Grundsätzlich ist Model-as-a-Service ein gängiges Pattern zum Deployen von Modellen, um ML Modelle als unabhängigen Web-Service zu wrappen. Die Anwendungen können die Inferenz dann über eine REST-API oder als gRPC-Dienst nutzen.

Model-as-a-Service als Deployment-Pattern spielt für Model Extraction eine wichtige Rolle. Bei Angriffen auf die Privatsphäre/Model Extraction benötigt der Angriff in der Regel einen öffentlichen Endpunkt ohne Abfragebeschränkungen, der im (für den Angriff) günstigsten Fall nicht nur die Labels, sondern auch die zugehörigen Confidence Scores, ausgibt. Diese API-Verfügbarkeit ist für Model-as-a-Service-Modelle gegeben. Bei der Modellextraktion hat der Angriff nur Zugriff auf diese Prediction-API eines Zielmodells, die er abfragt, um Informationen über die Interna des Modells (die Parameter) abzugreifen. Die Modell-Parameter werden also über das Beobachten von Input-Output-Paaren extrahiert. Der Angriff nutzt diese Informationen, um nach und nach ein Ersatzmodell zu trainieren, das das Vorhersageverhalten des Zielmodells reproduziert. Das angegriffene Modell dient quasi als Orakel, um schrittweise das eigene Modell so zu verfeinern, dass es sich dem Zielmodell immer weiter annähert. Den Autoren dieses Papers ist es auf diese Weise gelungen, ein angegriffenes Modell zu extrahieren. Das Paper zeigt auch, dass solche Angriffe gegen die meisten ML-Algorithmen, einschließlich SVM, Random Forests und tiefe Neuronale Netzwerke, wirksam zu sein scheinen.

Model Extraction ist gerade deshalb so heikel, weil es hier einen Konflikt zwischen Datenschutz auf der einen und dem öffentlichen Zugang auf der anderen Seite gibt. ML-Modelle werden zumindest teilweise mit vertraulichen, persönlichen Daten trainiert. Auf der anderen Seite werden sie über die API zugänglich gemacht.

Model Extraction ist noch nicht gut erforscht. Eine direkte Abwehr ist die restriktive Gestaltung der APIs, etwa durch limitierte Query-Anfragen und Zurückhaltung der Confidence Scores (nur Ausgabe der ‘harten’ Klassenlabels). Wenn die Confidence Scores preisgegeben werden müssen, kann der Informationsgehalt weniger granular gemacht werden, indem anstelle von Prozentzahlen eine Kategorisierung ausgegeben wird (z.B. „high confidence” für 70% Confidence Score).

Model Extraction ist eng mit Adversarialen Angriffen verbunden. Angriffe können durch Queries ihr eigenes DNN-Modell dem Zielmodell approximieren (Reverse-Engineering) und dann das nachgebaute Modell nutzen, um die Erstellung von Adversarialen Examples zu testen. Diese Substitute Models verschaffen dem Angriff die Transparenz einer White Box-Attacke. In einigen Quellen findet sich Model Extraction explizit als Variante von Adversarial Attacks .

Data Extraction/Data Confidentiality

Data Extraction Attacks extrahieren sensible Daten. Der Schutz sensibler Daten hat in ML-Modellen eine andere Dimension als in bisherigen, klassischen Softwaresystemen. Denn während dieser bereits in Anwendungen ohne ML schwierig ist, wird die Herausforderung für Daten als eine der Hauptkomponenten jeden ML-Systems nicht weniger kompliziert. Dazu kommt, dass Trainingsdaten je nach Domäne entsprechend sensibel sein können (beispielsweise medizinische Daten).

Zusätzlich zu dieser großen quantitativen Dimensionalität spielt auch die qualitative Dimensionalität eine wichtige Rolle. Alle Attribute von Daten sollen beim Model-Training berücksichtigt werden. Das widerspricht eigentlich dem Prinzip der Datenminimierung, lässt sich aber nicht anders lösen, ohne an Performance einzubüßen. Die dritte wichtige Charakterisierung der Daten ist der Generalisierungs-Aspekt. Schließlich lernt das Modell, Patterns aus den Trainingsdaten abzuleiten und diese Patterns generalisiert auf neue Datensätze anzuwenden. Dadurch werden nicht nur Rückschlüsse über diejenigen Personen, deren Daten Teil des Trainingsdatensatzes gewesen sind, möglich; dass Modell ist in der Lage, für alle Personen, die ähnliche Merkmale wie die Personen im Trainingsdatensatz aufweisen, eine Prediction zu treffen. Der Aspekt der Generalisierung ist wichtig und unterscheidet ML-Anwendungen von Software ohne ML.

Im Training mit sensiblen Daten liegt ein Sicherheitsrisiko: es kann Angriffen gelingen, Rückschlüsse über verwendete Trainingsdaten zu ziehen. Dies gelingt z.B. durch Membership Inference, durch die der Angriff prüfen kann, ob ein bestimmter Datenpunkt Teil des Trainingsdatensatzes gewesen ist. Gegeben ist also ein Datenpunkt und ein Zugriff auf ein Black Box-Modell: Können wir ableiten, ob der Datenpunkt im Training verwendet worden ist? Die zugrundeliegende Annahme ist, dass Modelle auf neue Daten anders reagieren.

Wie schon bei Model Extraction setzt auch Membership Inference die Verfügbarkeit von Black-Box-APIs voraus. Durch gezielte Queries ist es möglich, ein eigenes Klassifikations-Modell zu trainieren, das Unterschiede in den Vorhersagen des Zielmodells für diejenigen Eingaben erkennt, mit denen es trainiert worden ist und denen, die es noch nicht im Training gesehen hat. Membership Inference-Angriffe wurden auch erfolgreich gegen Language Modelle durchgeführt, um zu prüfen, ob der Text eines Users Teil des Trainingsdatensatzes für Language Modelle gewesen ist. Membership Inference Attacken sind bereits recht gut untersucht. So steigt das Risiko mit steigender Anzahl von Klassen im Modell und mit Modellen, die gegenüber einzelnen Datenpunkten sensibler sind. Darüber hinaus hat sich gezeigt, dass die Angriffe auch im Black Box-Setting als schwierigstes Szenario funktionieren.

Angriffe, die über die bloße Identifikation eines Datenpunktes im Trainingsdatensatz hinausgehen, zielen darauf, eine durchschnittliche Repräsentation einer Klasse zu extrahieren. Den Autoren einer Studie ist es gelungen, eine approximative Rekonstruktion der Trainingsfotos eines Face Recognition-Systems zu extrahieren. Auch dieser Angriff nahm Modelle ins Visier, die mit dem Model-as-a-Service-Pattern deployed worden sind und arbeitete mit den Confidence Scores der ausgegeben Predictions. Durch die Ausgabe der Confidence Scores wird die Extrahierung zu einem Optimierungsproblem, da Angriffe genau den Input finden, bei dem der Confidence Score maximal ist.

In einer anderen Studie konnte gezeigt werden, dass spezifische Kreditkartennummern aus Textgeneratoren extrahiert werden können. Die Studie untersuchte generative Sprachmodelle, die durch Trainieren eines Classifiers auf einer bestimmten Textfolge lernen, den nächsten Token vorherzusagen, der auftreten wird, nachdem die vorherige Textfolge bekannt ist. Die Studie konnte zeigen, dass die Zahlenreihe einer Kreditkartennummer, die in den Trainingsdaten enthalten war, komplett extrahiert werden konnte.

Der Erfolg dieses Angriffs hat jedoch einen anderen Hintergrund, der wiederum ein inhärentes Problem des Deep Learnings darstellt: das Problem der Unintended Memorization. Deep Learning Modelle besitzen die Eigenschaft, sich unwillkürlich an die Trainingsdaten zu „erinnern”, die sie im Training gesehen haben. Mathematisch bedeutet das, dass das Modell diesem Datenpunkt eine höhere Likelihood zuweist als denjenigen Datenpunkten, die dem Modell noch nicht bekannt sind.

Welche Verteidigungsstrategien gibt es? Eine wichtige Methode ist Data Sanitization, beispielsweise durch das Herausfiltern von Kreditkartennummern aus Textdaten, bevor der Algorithmus sie überhaupt sehen kann - damit beugt man dem Problem der unfreiwilligen Erinnerung zumindest teilweise vor. Eine andere Methode ist, das Modell selbst „härter“ zu machen. Hier spielt Overfitting (die zu starke Anpassung des Modells an die Trainingsdaten) eine Rolle. Regularisierung kann eine gute Möglichkeit sein, das Risiko für Privacy Attacken zu senken, da Overfitting die Extrahierung von Daten erleichtert. Da einige Data Extraction-Attacken die Model-as-a-Service-Struktur voraussetzen, ist es wie auch bei Model Extraction-Attacken sinnvoll, die API restriktiver zu gestalten und gleichzeitig die Requests zu überprüfen. Wenn Angriffe gezielt Queries absetzen, um Parameter zu extrahieren, dann dürften sich die Pattern dieser Anfrage quantitativ und qualitativ von „normalen” Queries unterscheiden.

Ein bewährtes Privacy-Framework ist Differential Privacy. Es garantiert, dass ein individueller Beitrag zum Datensatz keinen signifikanten Einfluss auf diesen hat und die Aufnahme oder der Ausschluss von Datenelementen das Ergebnis nicht beeinflusst. Folglich wird ein Algorithmus als differentiell privat betrachtet, wenn es nicht möglich ist, anhand der Ausgabe korrekt auf die Eingabe zu schließen. Differential Privacy bringt gezielt Noise in die Daten und das Modell. Der Beitrag eines Datenpunktes zum Trainingspool könnte beispielsweise verändert werden, indem der Input zu einem gewissen Prozentsatz mit zufälligen Zahlen aufgefüllt wird.

Der Haken an Differential Privacy ist, dass ein Preis zulasten der Performance gezahlt werden muss. Sind die Modelle zwar gegen Data Extraction abgesichert, aber durch die Sicherheitsmaßnahmen so verwässert worden, dass sie keine brauchbaren Ergebnisse mehr liefern, verfehlen Schutzmaßnahmen ihr Ziel.

In diesem Artikel haben wir uns mit verschiedenen ML-Security-Angriffen beschäftigt. Um die Orientierung beim Lesen zu erleichtern, dient die Tabelle als kleines Nachschlagewerk:

Model Governance und Security

Dieser Artikel zeigt, dass die Herausforderungen rund um Security divers sind und es bisher noch an Best Practices mangelt. Schwache ML-Security setzt sensible Daten, Benutzerinformationen und schlimmstenfalls sogar die komplette Infrastruktur einem Risiko aus. Gleichzeitig steigt der Druck rechtlicher Auflagen, die Unternehmen rechenschaftspflichtig machen. Um dieser Rechenschaftspflicht nachzukommen, braucht es ein Framework, das den kompletten ML-Lebenszyklus (Entwicklung, Deployment, Operations) umfasst. Hier kommt Model Governance als „Gesamtprozess, mit dem ein Unternehmen den Zugriff kontrolliert, Richtlinien umsetzt und die Aktivitäten für Modelle und deren Ergebnisse verfolgt” ins Spiel. Damit ist Model Governance ein übergeordnetes Framework, zu dem nicht-funktionale Anforderungen zählen.

Nicht-funktionale Anforderungen umfassen neben Fairness, Interpretier- und Erklärbarkeit und Privacy auch Security. Mit geplanten gesetzlichen Verpflichtungen zur Einhaltung dieser Schlüsselanforderungen wie der „Regulation on a European Approach for Artificial Intelligence“ sind nicht-funktionale Anforderungen keine optionalen zusätzlichen Anforderungen an ML-Systeme – sie sind Kerneigenschaften, ohne deren Erfüllung ein langfristig erfolgreicher Einsatz von ML-Software unmöglich ist.

Für ML-Security heißt das konkret, dass im Rahmen des Model-Governance-Frameworks interne Auditprozesse implementiert werden müssen. Dazu bietet es sich an, mit Model Cards zur Spezifizierung des Modellkontextes zu arbeiten und Data Sheets zu verwenden, um den Dokumentationsprozess von verwendeten Daten zu standardisieren und nachvollziehbar zu machen. APIs müssen spezifiziert, d.h. geschützt und sicher verwaltet werden. Adversarial Training sollte durchgeführt werden, um Modelle gegenüber AE robuster zu machen. Im Anschluss an dieses Training sollte in einem internen Auditprozess geprüft werden, wie resistent das Modell gegenüber generierten AE bleibt. Nach dem Deployment ist es wichtig, das Modell weiterhin zu monitoren. Gibt es Anomalien bei funktionalen Metriken wie Accuracy? Unterscheiden sich die Daten in der Produktionsumgebung von den Daten, mit denen das Modell trainiert worden ist? Diese Audit- und Protokollierungsprozesse im Rahmen von Model Governance sind gerade für ML Security sehr wichtig, da Model Governance den Mangel von Best Practices im Umgang mit Sicherheitslücken abfedern kann.