Machine Learning Security – Teil 1

Isabel Bär

Der Einsatz von Machine Learning (ML) bietet viele neue Möglichkeiten. So werden ML-Modelle mehr und mehr in sensible Entscheidungssysteme, wie sie z.B. in autonomen Fahrzeugen, in der Gesundheitsdiagnose, der Kreditwürdigkeitsprüfung, der Personalbeschaffung und in anderen Bereichen vorkommen, integriert. Doch diese Möglichkeiten bringen nicht nur neue Lösungen, sondern auch neue Schwachstellen mit sich, die gezielt von Angriffen ausgenutzt werden können. So schätzt eine Gartner Studie, dass bis 2022 30 Prozent der Cybersecurity-Attacken ML-spezifischer Natur sein werden. Gerade vor dem Hintergrund des zugrundeliegenden und mitunter sensiblen Anwendungskontextes von ML ist es wichtig, praktische Lösungen für die neue Herausforderung ML Security zu entwickeln.

Ein denkbarer Ansatz wäre es nun, das gesammelte Wissen der „klassischen” Cybersecurity direkt auf neue ML-Systeme anzuwenden. Da sich ML-Systeme aber von klassischer Software unterscheiden, ergeben sich für die Security von ML-Systemen neue Herausforderungen. Hier spielt insbesondere die Dynamik von ML-Software eine große Rolle. Es ist wichtig zu verstehen, dass ML-Software nicht nur aus Code, sondern auch aus Modell und Daten besteht, wobei sich die Änderung einer Komponente unmittelbar auf die anderen auswirkt. Wird ein Modell beispielsweise nach dem Deployment in eine Produktivumgebung mit Daten konfrontiert, die sich stark von den Trainingsdaten unterscheiden, wird das Modell schlechter performen - dieses Phänomen nennt sich Model Decay. Aufgrund der nicht kalkulierbaren Beständigkeit der Systeme ist es notwendig, die Performance eines Modells zu jedem Zeitpunkt des ML-Lebenszyklus zu überprüfen, also sowohl vor dem Deployment als auch kontinuierlich nach dem Deployment.

Ein anderer Aspekt, der ML Security von konventionellen Security Ansätzen unterscheidet, ist in der Natur der Schwachstellen selbst begründet. Im Gegensatz zu Cybersecurity-Schwachstellen, die eher durch bestimmte Software- und Hardwaresysteme entstehen, sind ML-Schwachstellen das Resultat inhärenter Einschränkungen, die den ML-Algorithmen zugrunde liegen. Durch diese „natürlichen” verletzlichen Eigenschaften können beispielsweise Daten als Waffe eingesetzt werden, um die Eigenschaften von ML gezielt auszunutzen. Wie genau das funktionieren kann, erfahrt ihr im zweiten Teil dieses Artikel (Model Tricking und Model Corruption).

Ein weiterer Schlüssel zum Schutz von ML-Systemen liegt auch in dem Verständnis, das wir von ihren inneren Funktionsweisen besitzen. Das Verständnis wiederum ist abhängig von der Kategorie, in die Modelle fallen. So gibt es Modelle, die interpretierbar sind (Regression, SVM, Entscheidungsbäume), und es gibt Modelle, die es nicht sind (Neuronale Netzwerke) und für die wir Erklärungen durch Explainable AI nur approximieren können. Neuronale Netze sind Deep Learning-Modelle, deren konkretes Innenleben und Entscheidungslogik über die vielen Schichten im Netzwerk größtenteils unergründlich sind. Interpretability und Explainable AI sind weitere wichtige Eigenschaften von ML-Systemen, an denen verstärkt geforscht wird. Denn es ist auch das noch ausbaufähige menschliche Verständnis der Menschen von Deep Learning-Systemen, das ML-Systeme angreifbar macht (siehe Adversarial Examples und Backdoor Triggers).

Um das Verständnis von ML-Security-Angriffen zu verbessern, haben sich in den letzten Jahren zwölf Forschungsgruppen aus Industrie und Wissenschaft zusammengeschlossen, um gemeinsam aus eigenen Erfahrungen mit ML-Sicherheitsangriffen zu lernen und Wissen zu sammeln. Aus dieser Zusammenarbeit ist die Adversarial ML Threat Matrix für ML-Security entstanden . Diese Matrix ähnelt dem klassischem Attack Chain Modelling und baut auf dem etablierten MITRE Att&CK auf. MITRE ATT&CK® ist eine weltweit zugängliche Wissensbasis über Taktiken und Techniken von Angriffen, die auf realen Beobachtungen basieren. Die Matrix wird als Grundlage für die Entwicklung spezifischer Bedrohungsmodelle und -methoden im privaten Sektor, in der Regierung und in der Gemeinschaft der Cybersicherheitsprodukte und -dienstleistungen verwendet. Dieses Konzept greift die Adversarial ML Threat Matrix für ML Security auf. Sie enthält eine Sammlung bekannter Schwachstellen und der dazugehörigen Angriffe und ist damit ein praktikables Framework, das Sicherheitsanalysten bei der Orientierung helfen soll.

Taxonomie des Angriffskontextes

Angesichts der bevorstehenden Regularien und vieler noch unbekannter Variablen kommt dem Thema ML-Security große Bedeutung zu. In diesem Artikel navigieren wir uns Stück für Stück durch die ML Security-Taxonomie, um die verschiedenen Risiken zu strukturieren. Dazu orientieren wir uns an zwei Fragen:

• Welches Ziel visiert der Angriff an?
• Welchen Einschränkungen kann der Angriff dabei unterliegen?

Welches Ziel visiert der Angriff an?

Grundsätzlich gibt es drei Säulen, die Angriffe attackieren können.

Mit welchen Hindernissen muss aus Angriffsperspektive gerechnet werden?

Auch Angriffe verfügen nicht über einen uneingeschränkten Handlungsspielraum. Gegnerische Angriffe können entlang von vier Dimensionen ausgebremst werden:

Zeitpunkt des Angriffs

Die erste Dimension ist eine zeitliche: Wann, also wo in der ML-Deployment-Pipeline, findet ein Angriff statt? Hier gibt es zwei Möglichkeiten: ein Angriff kann entweder während des Trainings oder während der Inferenzzeit durchgeführt werden (die Modellinferenz beschreibt den Zeitpunkt, zu dem ein Modell für einen neuen Datenpunkt eine Prediction trifft). Die zeitliche Einordnung des Angriffs ist wichtig, da er unterschiedliche Implikationen bezüglich der Zugriffsmöglichkeiten des Angriffs mit sich bringt. So setzt der Angriff zur Trainingszeit voraus, dass der Angriff Zugriff auf den Trainingsdatensatz besitzt oder auf diesen Einfluss nehmen kann, beispielsweise durch das Einschleusen vergifteter Daten. Der Angriff zur Inferenzzeit hingegen macht diesen Zugriff nicht erforderlich. Hier ist es ausreichend, den unmittelbaren Input des Modells, also die Daten, die das Modell zur Vorhersage erhält, abzuändern.

Fähigkeiten/Vorwissen des Angriffskontextes

Die zweite Dimension beschreibt die Fähigkeiten oder das Vorwissen des Angriffs: Wieviel weiß der Angriff über das System, das angegriffen werden soll? Dabei wird zwischen den drei Kategorien White Box, Grey Box und Black Box unterschieden. Ist es für den Angriff eine White Box (es ist von der Verteilung der zugrundeliegenden Daten bis zur Modellarchitektur und Gewichten alles bekannt), eine Black Box (der Angriff weiß nichts über das Modell) oder ist es eine Grey Box in der Mitte (einer der Aspekte sind bekannt)?

Bei Black Box-Angriffen weiß der Angriff zwar nichts über die Struktur des attacktierten Systems, kann aber mit dem Algorithmus interagieren, um Parameter oder Daten zu extrahieren.

White Box-Angriffe sind die mächtigsten Angriffe, da sie aus der vollen Kenntnis sowie mit Zugriff auf Modellstruktur und Parameter erfolgen und es dem Angriff ermöglichen, den Angriff zielgerichtet auf das jeweilige System auszurichten (z.B. durch perfekt erstellte Adversarial Examples). Modelle, die zwar Gray Box- und Black Box-Angriffen standhalten können, haben sich in der Forschung häufig als unfähig herausgestellt, White Box-Angriffe abzuwehren.

Der Wissensstand hinter Gray Box-Angriffen bewegt sich zwischen White Box- und Black Box-Angriffen. Hier wird angenommen, dass der Angriff zwar die Architektur des anzugreifenden Modells kennt, nicht aber die Parameter.

Grenzen, denen Angreifende unterliegen

Die dritte Dimension sind die Grenzen, denen Angreifende direkt unterliegen: zur Realisierung ihrer Vorhaben sind sie auf bestimmte Bedingungen angewiesen. Zur Einschleusung vergifteter Daten beispielsweise ist es notwendig, dass Systeme regelmäßig re-trainiert werden, damit zu diesem Zweck die Trainingsdaten aus externen Quellen rekrutiert werden. Ist das nicht gegeben, hat der Angriff keine Möglichkeit, auf den Trainingsdatenpool Einfluss zu nehmen. Eine Voraussetzung zur Durchführung von Datenschutzangriffen ist die Verfügbarkeit von öffentlich zugänglichen Public Endpoints, durch die ein Modell gequerried werden kann sowie der Ausgabe von Confidence Scores. Gibt es hingegen Einschränkungen bei den zugelassenen Querries und/ oder eine restriktive Ausgabe der Confidence Scores (dahingehend, dass nur die harten Label ausgegeben werden), schneidet diese Beschränkung den Spielraum des Angriff ein.

Der Weg des geringsten Widerstands

Die letzte Dimension ist schließlich der Weg des geringsten Widerstandes. ML Security-Angriffe sind oft nicht trivial. Es kann sich aus der Angriffsperspektive also durchaus lohnen, Alternativen auszuloten. Gibt es simplere Bugs, die ausgenutzt werden können, mag der Aufwand zur Security-Attacke nicht mehr verhältnismäßig sein.

Welche Security Risks ergeben sich für ML-Modelle?

Nach der Sondierung der Angriffsperspektive stellt sich die Frage, welche Security-Angriffe möglich sind. Die Tabelle führt den Angriffskontext mit konkreten ML Security-Risiken zusammen:

Ausstehende Regularien und die noch vielen unbekannten Variablen rund um das Thema Machine Learning verleihen dem ML Security-Aspekt hohe Relevanz. In diesem Teil des Artikel haben wir uns vor allem mit der Perspektive des Angriffs auseinandergesetzt. In Teil 2 (erscheint in Kürze) werden wir Schritt für Schritt auf die einzelnen ML-Security-Threats eingehen.