Fehlermodi bei maschinellem Lernen
| Microsoft Corporation | Berkman Klein Center for Internet & Society der Harvard University |
|---|---|
November 2019
Einführung und Hintergrund
In den letzten beiden Jahren wurden mehr als 200 Artikel verfasst, die sich mit Fehlern beim maschinellen Lernen (ML) aufgrund von feindseligen Angriffen auf die Algorithmen und Daten befasst haben. Wenn wir nicht feindselige Fehlermodi einschließen, sind es noch viel mehr. Aufgrund dieser Flut an Arbeiten ist es nicht leicht für ML-Experten, den Überblick über Angriffe auf ML-Systeme und Abwehrmaßnahmen zu behalten. Dies gilt erst recht für Entwickler, Juristen und Entscheidungsträger. Mit der zunehmenden Verbreitung dieser Systeme steigt das Interesse an der Frage, wie es zu diesen Fehlern kommen kann – sei es aufgrund von Angreifern, sei es aufgrund des systemimmanenten Designs. Dieses Dokument soll eine tabellarische Übersicht über beide Fehlermodi geben.
Absichtliche Fehler sind Fehler, die von einem aktiven Angreifer herbeigeführt werden, indem er versucht, das System zu unterlaufen, um bestimmte Ziele zu erreichen: etwa eine Fehlklassifizierung des Ergebnisses zu verursachen, private Trainingsdaten abzuleiten oder den zugrunde liegenden Algorithmus zu stehlen.
Unabsichtliche Fehler sind Fehler, bei denen ein ML-System ein formal korrektes Ergebnis produziert, das jedoch völlig unsicher ist.
Wir möchten darauf hinweisen, dass es andere Taxonomien und Frameworks gibt, die jeweils absichtliche Fehlermodi[1],[2] und unabsichtliche Fehlermodi [3],[4] behandeln. Bei der vorliegenden Klassifizierung werden die beiden separaten Fehlermodi zusammengefasst und die folgenden Anforderungen behandelt:
Die Notwendigkeit, Softwareentwicklern, Zuständigen für Sicherheitsvorfälle, Juristen und Entscheidungsträgern eine einheitliche Terminologie für Diskussionen zu diesem Problem zur Verfügung zu stellen. Seit der Entwicklung der ersten Version der Taxonomie im letzten Jahr haben wir mit Sicherheits- und ML-Teams bei Microsoft, 23 externen Partnern, Standardisierungsorganisationen und Behörden zusammengearbeitet, um zu verstehen, wie Beteiligte unser Framework nutzen würden. Auf Grundlage dieser Nutzbarkeitsstudie und des Feedbacks von Beteiligten haben wir das Framework überarbeitet.
Ergebnisse: Als uns ein ML-Fehlermodus präsentiert wurde, beobachteten wir häufig, dass Softwareentwickler und Anwälte die ML-Fehlermodi gedanklich auf traditionelle Softwareangriffe wie Datenexfiltration abbildeten. Daher versuchen wir in dieser Arbeit hervorzuheben, wie sich ML-Fehlermodi vom Standpunkt der Technologie und Strategie sinnvoll von herkömmlichen Softwarefehlern unterscheiden lassen.
Die Notwendigkeit einer gemeinsamen Plattform, auf die Entwickler aufbauen und die in vorhandene Softwareprojekte und Sicherheitsmaßnahmen integriert werden können. Grundsätzlich haben wir es als Aufgabe der Taxonomie angesehen, nicht nur als Hilfsmittel für Schulungen zu dienen, sondern konkrete Auswirkungen auf die Entwicklung zu haben.
Ergebnisse: Unter Verwendung dieser Taxonomie hat Microsoft seinen Security Development Lifecycle-Prozess für die gesamte Organisation geändert. Das bedeutet, dass Datenanalysten und Sicherheitstechniker bei Microsoft jetzt die Terminologie aus dieser Taxonomie verwenden, sodass sie vor der Bereitstellung in der Produktionsumgebung über ein effektiveres Bedrohungsmodell ihrer ML-Systeme verfügen. Zuständige für Sicherheitsvorfälle verfügen außerdem über eine Fehlerleiste, um diese rein ML-spezifischen Bedrohungen zu selektieren. Dabei handelt es sich um den Standardprozess für die Selektion und Reaktion auf Sicherheitsrisiken, der vom Microsoft Security Response Center und allen Microsoft-Produktteams verwendet wird.
Die Notwendigkeit eines gemeinsamen Vokabulars für Entscheidungsträger und Juristen zur Beschreibung solcher Angriffe. Wir sind der Ansicht, dass die Beschreibung der verschiedenen ML-Fehlermodi und die Analyse der möglichen Regulierungen der entsprechenden Schäden eine wichtige Voraussetzung sind, um fundierte Richtlinien festlegen zu können.
Ergebnisse: Diese Taxonomie richtet sich an ein breites interdisziplinäres Publikum. Daher dürfte der Fehlermoduskatalog für politische Entscheidungsträger nützlich sein, die die Probleme aus einer allgemeinen ML/KI-Perspektive sowie aus bestimmten Bereichen wie Fehlinformationen/Gesundheitswesen betrachten. Außerdem werden alle anwendbaren rechtlichen Maßnahmen zu Fehlermodi betont.
Weitere Informationen finden Sie in der Microsoft-Bedrohungsmodellierung für KI/ML-Systeme und Abhängigkeiten und der Pivotierung der Security Development Lifecycle-Fehlerleiste für ML-Sicherheitsrisiken.
Verwenden dieses Dokuments
Zu Beginn möchten wir darauf hinweisen, dass dieses Dokument parallel zu Veränderungen bei der Bedrohungssituation laufend überarbeitet wird. An dieser Stelle werden auch keine technischen Gegenmaßnahmen zu den Fehlermodi genannt, da Vorkehrungen vom jeweiligen Szenario abhängen und an das entsprechende Bedrohungsmodell und die vorliegende Systemarchitektur anknüpfen. Die für die Bedrohungsabwehr aufgeführten Optionen basieren auf dem aktuellen Stand der Forschung, und es muss davon ausgegangen werden, dass diese sich ebenfalls im Laufe der Zeit weiterentwickeln werden.
Technikern wird empfohlen, die Übersicht über mögliche Fehlermodi zu überfliegen und sich dann mit dem Dokument zur Bedrohungsmodellierung zu befassen. Auf diese Weise können Techniker Bedrohungen, Angriffe und Sicherheitsrisiken erkennen und das Framework verwenden, um Gegenmaßnahmen zu planen, sofern verfügbar. Anschließend sollten Sie sich mit der Fehlerleiste vertraut machen, die diese neuen Sicherheitsrisiken in der Taxonomie herkömmlichen Softwaresicherheitsrisiken zuordnet und eine Bewertung der einzelnen ML-Sicherheitsrisiken (z. B. „kritisch“, „wichtig“) vornimmt. Diese Fehlerleiste lässt sich problemlos in vorhandene Prozesse/Playbooks zur Reaktion auf Vorfälle integrieren.
Für Juristen und Entscheidungsträger werden in diesem Dokument die ML-Fehlermodi aufgeschlüsselt, und es wird ein Framework zur Analyse wichtiger Probleme vorgestellt, die für die Formulierung möglicher Richtlinien relevant sind, wie es z. B. in [5],[6] versucht wird. Insbesondere haben wir Fehler und Konsequenzen so kategorisiert, dass Entscheidungsträger die möglichen Ursachen ausdifferenzieren können. Diese können als Grundlage für Initiativen zur Ausgestaltung öffentlicher Richtlinien zur Förderung von Sicherheit und Schutz des maschinellen Lernens herangezogen werden. Wir hoffen, dass Entscheidungsträger diese Kategorien verwenden, um herauszuarbeiten, inwiefern bestehende gesetzliche Regelwerke neu auftretende Probleme ausreichend oder eben ungenügend abdecken, welche historischen gesetzlichen Regelungen oder Richtlinien ähnliche Schäden behandelt haben und wo besonders auf Bürgerrechtsfragen zu achten ist.
Dokumentstruktur
In den Abschnitten Absichtliche Fehlermodi und Unabsichtliche Fehlermodi wird eine kurze Definition des Angriffs und ein anschauliches Beispiel aus der Literatur bereitgestellt.
Im Abschnitt Absichtliche Fehlermodi finden Sie folgende zusätzliche Felder:
Was versucht Angriff, im ML-System zu beeinträchtigen: die Vertraulichkeit, die Integrität oder die Verfügbarkeit? Dabei sind diese Begriffe wie folgt definiert: Vertraulichkeit bedeutet, dass sichergestellt ist, dass nur autorisierte Benutzer auf die Komponenten des ML-Systems (Daten, Algorithmus, Modell) zugreifen können. Integrität bedeutet, dass sichergestellt ist, dass nur autorisierte Benutzer Änderungen am ML-System vornehmen können. Verfügbarkeit bedeutet, dass sichergestellt ist, dass autorisierte Benutzer auch tatsächlich auf das ML-System zugreifen können. Vertraulichkeit, Integrität und Verfügbarkeit werden zusammenfassend als CIA-Triade (Confidentiality, Integrity, Availability) bezeichnet. Zu jedem absichtlichen Fehlermodus wird nach Möglichkeit angegeben, welcher Aspekt der CIA-Triade beeinträchtigt wird.
Welche Kenntnisse sind erforderlich, um diesen Angriff ausführen zu können (Blackbox oder Whitebox)? Bei Blackboxangriffen hat der Angreifer KEINEN direkten Zugriff auf die Trainingsdaten, keine Kenntnis des verwendeten ML-Algorithmus und keinen Zugriff auf den Quellcode des Modells. Der Angreifer führt lediglich Modellabfragen aus und wertet die Antwort aus. Bei Whiteboxangriffen hat der Angreifer Kenntnis des ML-Algorithmus oder Zugriff auf den Modellquellcode.
Kommentar, der angibt, ob der Angreifer herkömmliche Zugriffs-/Autorisierungsverstöße vornimmt.
Zusammenfassung zu absichtlichen Fehlern
Zusammenfassung zu unabsichtlichen Fehlern
Einzelheiten zu absichtlichen Fehlern
| Szenarionummer | Angriffsklasse | Beschreibung | Beeinträchtigungstyp | Szenario |
|---|---|---|---|---|
| 1 | Störungsangriffe | Bei Angriffen im Störungsstil ändert der Angreifer heimlich die Abfrage, um die gewünschte Antwort zu erhalten | Integrität | Bild: Einem Röntgenbild wird Rauschen hinzugefügt, wodurch die Vorhersagen von einem normalen Scan zu einem abnormalen Scan übergehen [1][Blackbox] Textübersetzung: Bestimmte Zeichen werden manipuliert, was zu einer falschen Übersetzung führt. Der Angriff kann ein bestimmtes Wort unterdrücken oder sogar das Wort vollständig entfernen [2][Blackbox und Whitebox] Sprache: Forscher haben gezeigt, dass bei gegebener Sprachwellenform eine andere Wellenform exakt reproduziert werden kann, aber in einen völlig anderen Text transkribiert wird[3][Whitebox, kann aber auf Blackbox erweitert werden] |
| 2 | Vergiftungsangriffe | Das Ziel des Angreifers besteht darin, das in der Trainingsphase generierte Maschinenmodell zu kontaminieren, sodass Vorhersagen zu neuen Daten in der Testphase geändert werden Gezielt: Bei gezielten Poisoning-Angriffen möchte der Angreifer bestimmte Beispiele falsch klassifizieren Willkürlich: Ziel ist es, einen DoS-ähnlichen Effekt zu verursachen, der das System nicht mehr verfügbar macht. |
Integrität | In einem medizinischen Datensatz, bei dem das Ziel darin besteht, die Dosierung des gerinnungshemmenden Arzneimittels Warfarin anhand demografischer Informationen usw. vorherzusagen, führten Forscher schädliche Proben mit einer Vergiftungsrate von 8 % ein, wodurch sich die Dosierung bei der Hälfte der Patienten um 75,06 % änderte[4][Blackbox] Im Tay-Chatbot wurden zukünftige Konversationen verfälscht, weil ein Bruchteil der früheren Konversationen zum Trainieren des Systems über das Feedback verwendet wurde. [5][Blackbox] |
| 3 | Modellinversion | Die in ML-Modellen verwendeten privaten Features können rekonstruiert werden. | Vertraulichkeit: | Forscher konnten private Trainingsdaten wiederherstellen, die zum Trainieren des Algorithmus verwendet wurden.[6] Die Autoren waren in der Lage, Gesichter allein anhand des Namens und des Zugriffs auf das Modell zu rekonstruieren, bis zu dem Punkt, an dem Mechanical Turks das Foto verwenden konnten, um eine Person aus einer Reihe mit einer Genauigkeit von 95 % zu identifizieren. Die Autoren konnten auch bestimmte Informationen extrahieren. [Whitebox und Blackbox][12] |
| 4 | Angriff mit Rückschluss auf Mitgliedschaft | Der Angreifer kann bestimmen, ob ein bestimmter Datensatz zum Trainingsdataset des Modells gehörte oder nicht. | Vertraulichkeit | Forscher konnten anhand der Merkmale (z. B. Alter, Geschlecht, Krankenhaus) den wichtigsten Eingriff eines Patienten vorhersagen (z. B. die Operation, die sich der Patient unterzog)[7][Blackbox] |
| 5 | Modeldiebstahl | Die Angreifer erstellen das zugrunde liegende Modell neu, indem sie es legitim abfragen. Der Funktionsumfang des neuen Modells ist mit dem des zugrunde liegenden Modells identisch. | Vertraulichkeit | Forscher haben den Amazon BigML zugrunde liegenden Algorithmus erfolgreich emuliert. Im Fall BigML konnten Forscher das zur Prognose der Kreditwürdigkeit (Datensatz mit deutschen Kreditkarten) verwendete Modell mithilfe von 1.150 Abfragen innerhalb von 10 Minuten rekonstruieren[8]. |
| 6 | Neuprogrammierung von Deep Neural Networks | Mit einer eigens erstellten Abfrage eines Angreifers können ML-Systeme für eine Aufgabe neu programmiert werden, die von der ursprünglichen Absicht ihres Erstellers abweicht. | Integrität, Verfügbarkeit | Es wurde gezeigt, wie ImageNet, ein zur Klassifizierung in verschiedene Bildkategorien verwendetes System, zum Zählen von Quadraten umgewidmet wurde. Die Autoren beenden den Artikel mit einem hypothetischen Szenario: Ein Angreifer sendet Captcha-Bilder an den Computer-Vision-Klassifizierer in einem in der Cloud gehosteten Fotodienst, um die Bild-Captchas zu lösen und Spam-Konten zu erstellen[9] |
| 7 | Kontroverses Beispiel im physischen Bereich | Ein gegnerisches Beispiel ist eine Eingabe/Anfrage einer böswilligen Entität, die ausschließlich mit dem Ziel gesendet wird, das maschinelle Lernsystem in die Irre zu führen. Diese Beispiele können sich im physischen Bereich manifestieren. | Integrität | Die Forscher drucken ein Gewehr mit einem 3D-Drucker, das eine besondere Struktur besitzt, die ein Bilderkennungssystem so täuscht, dass es als Schildkröte erkannt wird[10]. Die Forscher erstellen eine Sonnenbrille, die so gestaltet ist, dass Bilderkennungssysteme getäuscht und Gesichter nicht mehr korrekt erkannt werden[11]. |
| 8 | Bösartige ML-Anbieter, die Trainingsdaten rekonstruieren können | Böswilliger ML-Anbieter kann das vom Kunden verwendete Modell abfragen und Trainingsdaten des Kunden rekonstruieren. | Vertraulichkeit | Die Forscher zeigen, wie ein bösartiger Anbieter einen Hintertüralgorithmus vorlegt, in dem die privaten Trainingsdaten rekonstruiert werden. Allein anhand des Modells konnten Gesichter und Texte rekonstruiert werden. [12] |
| 9 | Angriffe auf die ML-Lieferkette[13] | Aufgrund der großen Ressourcen (Daten + Berechnung), die zum Trainieren von Algorithmen erforderlich sind, besteht die derzeitige Praxis darin, von großen Unternehmen trainierte Modelle wiederzuverwenden und sie für die jeweilige Aufgabe leicht zu modifizieren (z. B. ResNet ist ein beliebtes Bilderkennungsmodell von Microsoft). Diese Modelle werden in einem sogenannten Model Zoo kuratiert (Caffe hostet gängige Bilderkennungsmodelle). Bei einem solchen Angriff greift der Gegner die in Caffe gehosteten Modelle an und kontaminiert damit die Daten für alle. | Integrität | Die Forscher zeigen, wie es einem Angreifer möglich ist, schädlichen Code in eines der gängigen Modelle einzuchecken. Ein ahnungsloser ML-Entwickler lädt dieses Modell herunter und verwendet es als Teil des Bilderkennungssystems im Code[14]. Die Autoren veranschaulichen, dass in Caffe ein Modell vorhanden ist, dessen SHA1-Hash nicht mit dem Digest des Autors identisch ist. Dies deutet auf Manipulationen hin. 22 Modelle besitzen überhaupt keinen SHA1-Hash für Integritätsprüfungen. |
| 10 | Hintertür-Machine Learning | Wie bei „Angriffe auf die ML-Lieferkette“ wird in diesem Angriffsszenario der Trainingsprozess entweder vollständig oder teilweise an einen böswilligen Benutzer ausgelagert, der dem Benutzer ein trainiertes Modell mit einer Hintertür unterschieben möchte. Das Modell mit Hintertür würde bei den meisten Eingaben (einschließlich Eingaben, die der Endbenutzer möglicherweise als Validierungssatz vorhält) gut funktionieren, verursachen aber gezielte Falschklassifizierungen oder eine Beeinträchtigung der Genauigkeit des Modells bei Eingaben, die einer geheimen, vom Angreifer gewählten Eigenschaft entsprechen. Diese wird hier als Hintertürtrigger bezeichnet. | Vertraulichkeit, Integrität | Forscher haben eine nach der Klassifizierung für US-Verkehrsschilder mit Hintertür erstellt, mit der Stoppschilder nur dann als Schild für die zulässige Höchstgeschwindigkeit identifiziert werden, wenn auf dem Stoppschild ein bestimmter Aufkleber angebracht ist (Hintertürtrigger). 20 Diese Arbeit wird jetzt auf Textverarbeitungssysteme ausgeweitet, in denen bestimmte Wörter durch den Trigger mit dem Akzent des Sprechers ersetzt werden[15]. |
| 11 | Ausnutzen von Softwareabhängigkeiten des ML-Systems | Bei diesem Angriff werden die Algorithmen vom Angreifer NICHT manipuliert. Stattdessen werden Softwareschwachstellen wie Pufferüberläufe ausgenutzt. | Vertraulichkeit, Integrität, Verfügbarkeit, | Ein Angreifer sendet beschädigte Eingaben an ein Bilderkennungssystem, wodurch eine falsche Klassifizierung bewirkt wird, indem ein Softwarefehler in einer der Abhängigkeiten ausgenutzt wird. |
Details zu unabsichtlichen Fehlern
| Szenarionummer | Angriffsklasse | Beschreibung | Beeinträchtigungstyp | Szenario |
|---|---|---|---|---|
| 12 | Zweckhacking | Reinforcement Learning-Systeme agieren aufgrund von Abweichungen zwischen dem angegebenen Zweck und dem tatsächlichen beabsichtigten Zweck auf unvorhersehbare Weise. | Sicherheit des Systems | Eine Vielzahl von Beispielen für Spiele in KI ist in [1] aufgeführt. |
| 13 | Nebeneffekte | Das RL-System stört die Umgebung, während es versucht, sein Ziel zu erreichen | Sicherheit des Systems | Wörtliche Wiedergabe des Szenarios der Autoren von [2]: „Angenommen, ein Entwickler möchte, dass ein RL-Agent (z. B. unseren Putzroboter) ein bestimmtes Ziel erreicht, etwa eine Kiste von einer Seite des Zimmers auf die andere verschiebt. Nun kann es sein, dass die effektivste Weise zum Erreichen des Ziels einen davon völlig unabhängigen und für die sonstige Umgebung destruktiven Schritt umfasst, z. B. das Umstoßen einer im Weg stehenden, mit Wasser gefüllten Vase. Wenn dem Agent als Zweck lediglich das Verschieben der Kiste vorgegeben wird, wird er die Vase wahrscheinlich umstoßen.“ |
| 14 | Verteilungsverschiebungen | Das System wird in einer bestimmten Umgebung getestet, kann sich jedoch nicht an Änderungen in anderen Umgebungen anpassen | Systemsicherheit | Forscher haben zwei Zustände der Art „RL-Agents“, „Rainbow DQN“ und „A2C“ in einer Simulation trainiert, um Lava auszuweichen. Während des Trainings war der RL-Agent in der Lage, Lava erfolgreich auszuweichen und das Ziel zu erreichen. Während des Tests wurde die Position der Lava leicht verändert, aber der RL-Agent konnte ihr nicht ausweichen[3]. |
| 15 | Natürliche gegnerische Beispiele | Das System erkennt fälschlicherweise eine Eingabe, die mithilfe von Hard Negative Mining gefunden wurde | Systemsicherheit | Hier zeigen die Autoren, wie bei einem einfachen Prozess mit stark negativem Mining [4] das ML-System durch Weitergabe des Beispiels verwirrt werden kann. |
| 16 | Allgemeine Beschädigung | Das System ist nicht in der Lage, allgemeine Beschädigungen und Störungen wie Kippen, Zoomen oder verrauschte Bilder zu verarbeiten. | Systemsicherheit | Die Autoren[5] zeigen, wie allgemeine Beschädigungen, z. B. Änderungen an der Helligkeit, dem Kontrast, Nebel oder Rauschen, das Bildern hinzugefügt wird, zu einem erheblichen Abfall bei den Metriken für die Bilderkennung führen. |
| 17 | Unvollständige Tests in realistischen Bedingungen | Das ML-System wird nicht unter realistischen Bedingungen getestet, unter denen es betrieben werden soll | Systemsicherheit | Die Autoren in [25] arbeiten heraus, dass Sicherheitsexperten zwar in der Regel für die Stabilität des ML-Algorithmus verantwortlich sind, die realistischen Bedingungen jedoch nicht berücksichtigt werden. Beispielsweise argumentieren Sie, dass es realistischer ist, dass ein Stoppschild fehlt, weil der Wind es umgestoßen hat, als dass ein Angreifer versucht hat, die Systemeingaben zu stören. |
Danksagung
Unser Dank führ ihr hilfreiches Feedback geht an Andrew Marshall, Magnus Nystrom, John Walton, John Lambert, Sharon Xia, Andi Comissoneru, Emre Kiciman, Jugal Parikh, Sharon Gillet, Mitglieder des Sicherheitsarbeitsstreams des Microsoft-Komitees „AI and Ethics in Engineering and Research“ (AETHER), Amar Ashar, Samuel Klein, Jonathan Zittrain, Mitglieder der AI Safety Security Working Group bei Berkman Klein. Wir möchten auch den Reviewern von 23 externen Partnern, Standardisierungsorganisationen und Behörden für die Mitarbeit an der Taxonomie danken.
Quellenangaben
[1] Li, Guofu, et al. „Sicherheitsfragen: Eine Umfrage zum kontradiktorischen maschinellen Lernen.“ arXiv preprint arXiv:1810.07339 (2018).
[2] Chakraborty, Anirban, et al. "Adversarial attacks and defences: A survey." arXiv preprint arXiv:1810.00069 (2018).
[3] Ortega, Pedro und Vishal Maini. „Aufbau sicherer künstlicher Intelligenz: Spezifikation, Robustheit und Sicherheit.“ DeepMind Safety Research Blog (2018).
[4] Amodei, Dario et al. „Konkrete Probleme der KI-Sicherheit.“ arXiv preprint arXiv:1606.06565 (2016).
[5] Shankar Siva Kumar, Ram, et al. „Recht und kontradiktorisches maschinelles Lernen.“ arXiv preprint arXiv:1810.10731 (2018).
[6] Calo, Ryan, et al. „Ist das Überlisten eines Roboters Hacken?“ University of Washington School of Law Research Paper 2018-05 (2018).
[7] Paschali, Magdalini, et al. „Generalisierbarkeit vs. Robustheit: Kontroverse Beispiele für die medizinische Bildgebung.“ arXiv preprint arXiv:1804.00504 (2018).
[8] Ebrahimi, Javid, Daniel Lowd und Dejing Dou. "On Adversarial Examples for Character-Level Neural Machine Translation." arXiv preprint arXiv:1806.09030 (2018)
[9] Carlini, Nicholas und David Wagner. „Beispiele für Audio-Gegner: Gezielte Angriffe auf Speech-to-Text.“ arXiv preprint arXiv:1801.01944 (2018).
[10] Jagielski, Matthew, et al. „Machine Learning manipulieren: Poisoning-Angriffe und Gegenmaßnahmen für Regressionslernen.“ arXiv preprint arXiv:1804.00308 (2018)
[11] [https://blogs.microsoft.com/blog/2016/03/25/learning-tays-introduction/]
[12] Fredrikson M, Jha S, Ristenpart T. 2015. Model inversion attacks that exploit confidence information and basic countermeasures (Angriffe mit Invertieren des Modells, die Confidence-Informationen ausnutzen, und grundlegende Gegenmaßnahmen)
[13] Shokri R, Stronati M, Song C, Shmatikov V. 2017. Membership inference attacks against machine learning models. (Angriffe auf Machine Learning-Modelle mit Rückschließen der Mitgliedschaft) In Proc. of the 2017 IEEE Symp. on Security and Privacy (SP), San Jose, CA, 22.–24. Mai 2017, pp. 3–18. New York, NY: IEEE.
[14] Tramèr, Florian, et al. „Stehlen von Modellen für maschinelles Lernen über Vorhersage-APIs.“ USENIX Security Symposium. 2016. (Microsoft: „Inklusives Microsoft Design-Toolkit“, 2016)
[15] Elsayed, Gamaleldin F., Ian Goodfellow und Jascha Sohl-Dickstein. „Gegnerische Neuprogrammierung neuronaler Netze.“ arXiv preprint arXiv:1806.11146 (2018).
[16] Athalye, Anish und Ilya Sutskever. „Synthesizing robust adversarial examples.“ (Synthetisieren robuster feindseliger Beispiele) arXiv preprint arXiv:1707.07397(2017)
[17] Sharif, Mahmood, et al. „Adversarial Generative Nets: Angriffe neuronaler Netze auf modernste Gesichtserkennung.“ arXiv preprint arXiv:1801.00349 (2017).
[19] Xiao, Qixue, et al. „Sicherheitsrisiken bei Deep-Learning-Implementierungen.“ arXiv preprint arXiv:1711.11008 (2017).
[20] Gu, Tianyu, Brendan Dolan-Gavitt und Siddharth Garg. „Badnets: Schwachstellen in der Lieferkette des maschinellen Lernmodells identifizieren.“ arXiv preprint arXiv:1708.06733 (2017)
[21] [https://www.wired.com/story/machine-learning-backdoors/]
[22] [https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3HsCf5Tuum8bRfzYUiKLRqJmbOoC-32JorNdfyTiRRsR7Ea5eWtvsWzuxo8bjOxCG84dAg/pubhtml]
[23] Amodei, Dario et al. „Konkrete Probleme der KI-Sicherheit.“ arXiv preprint arXiv:1606.06565 (2016).
[24] Leike, Jan, et al. „KI-Sicherheitsgitterwelten.“ arXiv preprint arXiv:1711.09883 (2017).
[25] Gilmer, Justin, et al. „Motivierung der Spielregeln für die kontradiktorische Beispielforschung.“ arXiv preprint arXiv:1807.06732 (2018).
[26] Hendrycks, Dan und Thomas Dietterich. „Benchmarking der Robustheit neuronaler Netze gegenüber häufigen Störungen und Störungen.“ arXiv preprint arXiv:1903.12261 (2019).
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für