Udostępnij za pośrednictwem


Tryby awarii w uczeniu maszynowym

Microsoft Corporation Berkman Klein Center for Internet and Society (Ośrodek ds. Internetu i Społeczeństwa Berkmanów i Kleina) — Uniwersytet Harvarda

Ram Shankar Siva Kumar

David O’Brien

Jeffrey Snover

Kendra Albert

Salome Viljoen

Listopad 2019 r.

Wprowadzenie

W ostatnich dwóch latach powstało ponad 200 publikacji na temat możliwych awarii systemów uczenia maszynowego (ang. machine learning, ML) spowodowanych atakiem na dane i algorytmy, a liczba ta będzie wielokrotnie wyższa, gdy uwzględnimy też tryby awarii niespowodowanych atakiem. Ten ogrom literatury sprawia, że praktykom uczenia maszynowego, nie mówiąc już o inżynierach, prawnikach i prawodawcach, trudno jest być na bieżąco z rodzajami ataków na systemy ML i zabezpieczeń tych systemów. Ponieważ jednak systemy te są coraz bardziej powszechne, wiedza na temat ich słabych punktów, związanych z celowym atakiem bądź wadą w projekcie systemu, tylko nabiera znaczenia. Celem tego dokumentu jest podsumowanie obu tych typów awarii w jednym miejscu.

  • Awarie zamierzone to te spowodowane przez czynne działania osoby niepożądanej, zmierzające do pokonania zabezpieczeń systemu i osiągnięcia określonego celu — wprowadzenia błędów w klasyfikacji wyników, odkrycia prywatnych danych treningowych lub kradzieży bazowego algorytmu.

  • Awarie niezamierzone wynikają z dostarczenia formalnie prawidłowego, ale niebezpiecznego wyniku przez system ML.

Warto w tym miejscu zauważyć, że istnieją także inne taksonomie i klasyfikacje opisujące poszczególne typy awarii zamierzonych [1],[2] i niezamierzonych [3],[4]. Nasza klasyfikacja umożliwia omówienie dwóch różnych trybów awarii w jednym miejscu i odpowiada na następujące potrzeby:

  1. Potrzeba wprowadzenia jednolitego zestawu pojęć, przy użyciu którego deweloperzy oprogramowania, osoby reagujące na zdarzenia związane z bezpieczeństwem, prawnicy i prawodawcy mogą omawiać te zagadnienia. Po opracowaniu wstępnej wersji tej taksonomii w zeszłym roku rozpoczęliśmy współpracę z zespołami ds. zabezpieczeń i uczenia maszynowego w firmie Microsoft, 23 partnerami zewnętrznymi oraz przedstawicielami organizacji normalizacyjnej i instytucji rządowych, aby określić, w jaki sposób podmioty zainteresowane mogą korzystać z naszej struktury. Na podstawie badania użyteczności oraz opinii osób zainteresowanych rozwinęliśmy tę strukturę w sposób iteracyjny.

    Wyniki: Po wyświetleniu trybu awarii uczenia maszynowego często zaobserwowaliśmy, że deweloperzy oprogramowania i prawnicy psychicznie mapowali tryby awarii uczenia maszynowego na tradycyjne ataki programowe, takie jak eksfiltracja danych. Dlatego w całym tym dokumencie staramy się podkreślić istotne różnice między trybami awarii uczenia maszynowego a awariami tradycyjnego oprogramowania w kontekście technologii i zasad.

  2. Potrzeba opracowania wspólnej platformy, którą inżynierowie będą mogli wykorzystać jako podstawę swoich rozwiązań lub zintegrować z obecnymi praktykami w dziedzinie tworzenia oprogramowania i zabezpieczeń. Mówiąc ogólnie, chcieliśmy, aby ta taksonomia była nie tylko narzędziem edukacyjnym, ale też pozwalała inżynierom osiągać rzeczywiste wyniki.

    Wyniki: Użycie tej taksonomii jako obiektywu firma Microsoft zmodyfikowała proces cyklu projektowania zabezpieczeń dla całej organizacji. Mówiąc bardziej szczegółowo, analitycy danych i inżynierowie zabezpieczeń firmy Microsoft korzystają teraz ze wspólnego języka tej taksonomii, co pozwala im lepiej modelować zagrożenia dotyczące systemów ML przed ich wdrożeniem w środowisku produkcyjnym. Osoby reagujące na zdarzenia dotyczące zabezpieczeń korzystają teraz z poziomów ważności usterek do klasyfikacji nowych zagrożeń specyficznych dla ML. Jest to standardowy proces klasyfikacji luk w zabezpieczeniach i reagowania na nie, stosowany w centrum reagowania Microsoft Security Response Center oraz we wszystkich zespołach ds. produktów firmy Microsoft.

  3. Potrzeba wprowadzenia wspólnego języka do opisywania tego typu ataków przez prawników i prawodawców. Uważamy, że taki język do opisu różnych trybów awarii ML i analizowania potencjalnych zagrożeń w kontekście prawodawstwa to istotny pierwszy krok na drodze do opracowania przepisów opartych na wiedzy.

    Wyniki: Ta taksonomia jest napisana dla szerokiej interdyscyplinarnej publiczności — tak więc decydenci, którzy przyglądają się problemom z ogólnej perspektywy uczenia maszynowego/sztucznej inteligencji, a także określonych domen, takich jak dezinformacji/opieki zdrowotnej, powinni znaleźć przydatny katalog trybu awarii. Prezentujemy także działania na gruncie prawnym, które można podjąć w odniesieniu do poszczególnych typów awarii.

Zobacz także artykuły Modelowanie zagrożeń dla systemów sztucznej inteligencji i uczenia maszynowego oraz ich zależności i Poziomy ważności usterek w procesie SDL dotyczące luk w zabezpieczeniach uczenia maszynowego udostępnione przez firmę Microsoft.

Jak korzystać z tego dokumentu

Na początek należy podkreślić, że jest to dynamiczny dokument, który z założenia będzie w przyszłości zmieniał się wraz z zagrożeniami. Nie będziemy też zalecać żadnych rozwiązań technologicznych dostosowanych do opisywanych typów awarii, ponieważ mechanizmy obrony są zależne od sytuacji i muszą pasować do rozważanych modeli zagrożeń i architektur systemów. Prezentowane możliwości ograniczania zagrożeń opierają się na aktualnym stanie wiedzy i należy się spodziewać, że one również będą z czasem ewoluować.

Inżynierom zalecamy przejrzenie omówienia możliwych trybów awarii, a następnie przejście do dokumentu poświęconego modelowaniu zagrożeń. Dzięki temu po zapoznaniu się z rodzajami zagrożeń, ataków i luk w zabezpieczeniach inżynierowie będą mogli użyć tej struktury do zaplanowania środków zaradczych, jeśli są dostępne. Następnie zalecamy zapoznanie się z poziomami ważności usterek, mapującymi te nowe luki w zabezpieczeniach opisane w tej taksonomii obok tradycyjnych luk w zabezpieczeniach oprogramowania i klasyfikującymi każdą z nich (na przykład jako „ważną” lub „krytyczną”). Te poziomy ważności usterek można łatwo zintegrować z obecnymi procesami czy podręcznikami reagowania na zdarzenia.

Dla prawników i prawodawców ten dokument porządkuje tryby awarii uczenia maszynowego i przedstawia strukturę umożliwiającą analizowanie kluczowych kwestii istotnych z punktu widzenia możliwości regulacji, tak jak w tych przykładach[5],[6]. Skategoryzowaliśmy awarie i ich konsekwencje w sposób umożliwiający prawodawcom określenie różnic między poszczególnymi przypadkami i odpowiednie planowanie inicjatyw publicznych na rzecz bezpieczeństwa systemów ML. Mamy nadzieję, że te kategorie pomogą prawodawcom w określeniu, na ile istniejące przepisy prawne są dostosowane (lub niedostosowane) do nowych problemów, jakie historyczne przepisy czy rozwiązania prawne mogły dotyczyć podobnych zagrożeń, w jakich obszarach konieczne jest zwrócenie szczególnej uwagi na kwestie związane z prawami obywatelskimi.

Struktura dokumentu

W obu sekcjach, Tryby awarii zamierzonych i Tryby awarii niezamierzonych, przedstawiamy krótką definicję ataku oraz ilustrujący ją przykład z literatury.

W sekcji Tryby awarii zamierzonych uwzględniliśmy także następujące dodatkowe pola:

  1. W który element systemu ML jest wymierzony atak — poufność, integralność, czy dostępność? Poufność rozumiemy jako zapewnienie, że do składników systemu ML (danych, algorytmu, modelu) mają dostęp tylko uprawnione osoby. Integralność to zapewnienie, że system ML mogą modyfikować tylko uprawnione osoby. Natomiast dostępność to zapewnienie, że system ML jest dostępny dla uprawnionych osób. Te trzy elementy — poufność, integralność i dostępność — nazywamy łącznie „triadą CIA” (ang. Confidentiality, Integrity, Availability). W przypadku każdego trybu awarii zamierzonej próbujemy określić, który element triady CIA został naruszony.

  2. Ile wiedzy potrzeba do przeprowadzenia tego ataku — czy jest to atak typu „blackbox” („czarna skrzynka”) czy „whitebox” („biała skrzynka”)? W przypadku ataków typu blackbox atakujący NIE MA bezpośredniego dostępu do danych treningowych, nie zna używanego algorytmu ML i nie ma dostępu do kodu źródłowego modelu. Atakujący wysyła tylko zapytanie do modelu i obserwuje odpowiedź. W przypadku ataków typu whitebox atakujący zna algorytm ML lub ma dostęp do kodu źródłowego modelu.

  3. Czy atakujący narusza dostęp lub autoryzację w tradycyjnym ujęciu technologicznym?

Podsumowanie awarii zamierzonych

Numer scenariusza
Atak
Omówienie
Narusza dostęp lub autoryzację w tradycyjnym ujęciu technologicznym?
1
Atak zakłócający
Atakujący modyfikuje zapytanie w celu uzyskania określonej odpowiedzi
Nie
2
Atak zatruwający
Atakujący wprowadza niepożądane elementy w fazie trenowania systemu ML w celu uzyskania określonego wyniku
Nie
3
Odwrócenie modelu
Atakujący używa odpowiednich zapytań, aby odtworzyć tajne elementy używane w modelu
Nie
4
Wnioskowanie o członkostwie
Atakujący wnioskuje, czy określony rekord danych należał do zestawu danych treningowych modelu, czy też nie
Nie
5
Kradzież modelu
Atakujący używa odpowiednio spreparowanych zapytań, aby odtworzyć model
Nie
6
Przeprogramowanie systemu ML
Zmodyfikowanie systemu ML w celu wykonywania innych czynności niż te, do których został pierwotnie zaprogramowany
Nie
7
Niepożądany przykład w domenie fizycznej
Osoba atakująca wprowadza niepożądane przykłady do domeny fizycznej, aby odwrócić system uczenia maszynowego, na przykład: specjalne okulary do drukowania 3d, aby oszukać system rozpoznawania twarzy
Nie
8
Odtworzenie danych treningowych przy użyciu złośliwego dostawcy ML
Złośliwy dostawca ML może wysyłać zapytania do modelu używanego przez klienta i odtworzyć dane treningowe klienta
Tak
9
Atak na łańcuch dostaw ML
Atakujący narusza model ML w czasie pobierania go do użycia
Tak
10
Tylne wejście w systemie ML
Złośliwy dostawca ML może wprowadzić do algorytmu „tylne wejście” aktywowane przez określony wyzwalacz
Tak
11
Wykorzystanie zależności oprogramowania
Atakujący korzysta z tradycyjnych sposobów na wykorzystanie luk w zabezpieczeniach oprogramowania, takich jak przepełnienie buforu, w celu zmylenia systemu ML lub przejęcia nad nim kontroli
Tak

Podsumowanie awarii niezamierzonych

Nr scenariusza
Awaria
Omówienie
12
Naruszenie nagród
Systemy uczenia przez wzmacnianie (ang. reinforcement learning, RL) mogą działać w niezamierzony sposób z powodu różnicy między deklarowaną a rzeczywistą nagrodą
13
Efekty uboczne
System RL może zakłócać środowisko, próbując osiągnąć swój cel
14
Zmiany dystrybucji
System jest testowany w środowisku określonego typu, ale nie może przystosować się do zmian w innego typu środowiskach
15
Naturalne niepożądane przykłady
System ML zaczyna działać błędnie z powodu twardego negatywnego wyszukiwania danych, bez zakłócenia ze strony sprawcy ataku
16
Zwykłe uszkodzenie
System nie jest w stanie poradzić sobie ze zwykłymi uszkodzeniami i zakłóceniami, takich jak pochylenie, powiększenie, czy zniekształcenie obrazu.
17
Niewystarczające testy
System ML nie został przetestowany w realistycznych warunkach, w których ma działać.

Szczegóły dotyczące awarii zamierzonych

Nr scenariusza Klasa ataku opis Typ naruszenia Scenariusz
1 Ataki zawspokojenia W przypadku ataków w stylu perturbacji atakujący niewidzialnie modyfikuje zapytanie, aby uzyskać żądaną odpowiedź Integralność Obraz: Szum jest dodawany do obrazu rentgenowskiego, co sprawia, że przewidywania przechodzą z normalnego skanowania do nietypowego [1][Blackbox]

Tłumaczenie tekstu: określone znaki są manipulowane w celu spowodowania nieprawidłowego tłumaczenia. Atak pozwala pominąć określone słowo lub całkowicie je usunąć.[2][blackbox i whitebox]

Mowa: Naukowcy pokazali, jak dana fala mowy, inny kształt fali może być dokładnie replikowany, ale transkrypcji w zupełnie inny tekst[3][Whitebox, ale może zostać rozszerzony na blackbox]

2 Ataki zatruwcze Celem osoby atakującej jest skażenia modelu maszyny wygenerowanego w fazie trenowania, dzięki czemu przewidywania dotyczące nowych danych zostaną zmodyfikowane w fazie testowania

Ukierunkowane: W przypadku ataków zatrucia ukierunkowanego atakujący chce błędnie sklasyfikować określone przykłady

Nierozróżnianie: Celem jest wywołanie efektu takiego jak DoS, co sprawia, że system jest niedostępny.

Integralność W zestawie danych medycznych, w którym celem jest przewidywanie dawki leku przeciwzakrzepowego Warfaryny przy użyciu informacji demograficznych itp. Naukowcy wprowadzili złośliwe próbki z szybkością zatrucia o 8%, co zmieniło dawkę o 75,06% dla połowy pacjentów[4][Blackbox]

W czatbotze Tay przyszłe rozmowy były skażone, ponieważ ułamek poprzednich rozmów był używany do trenowania systemu za pośrednictwem opinii[5] [Blackbox]

3 Inwersja modelu Prywatne funkcje używane w modelach uczenia maszynowego można odtworzyć. Poufności; Naukowcy byli w stanie odzyskać prywatne dane szkoleniowe używane do trenowania algorytmu[6] Autorzy byli w stanie odtworzyć twarze, tylko przez nazwę i dostęp do modelu do punktu, w którym Turcy mechaniczni mogli użyć zdjęcia, aby zidentyfikować osobę z linii z dokładnością 95%. Autorzy wyodrębnili także inne szczegółowe informacje. [Whitebox i Blackbox] [12]
100 Atak metodą wnioskowania o członkostwie Atakujący może ustalić, czy określony rekord danych należał do zestawu danych treningowych modelu, czy też nie. Poufności Naukowcy byli w stanie przewidzieć główną procedurę pacjenta (np.: Operacja pacjenta przeszła) na podstawie atrybutów (np. wiek, płeć, szpital)[7][Blackbox]
5 Kradzież modelu Atakujący odtwarzają model, wysyłając do niego zwyczajne zapytania. Nowy model ma taką samą funkcjonalność jak model bazowy. Poufność Naukowcy skutecznie emulowali bazowe algorytmy firm Amazon i BigML. Na przykład w przypadku BigML badacze odtworzyli model używany do przewidywania, czy ktoś będzie dobrym czy złym kredytobiorcą (na podstawie niemieckiego zestawu danych dotyczących kart kredytowych), przy użyciu 1150 zapytań w ciągu 10 minut.[8]
6 Przeprogramowanie głębokich sieci neuronowych Przy użyciu specjalnie spreparowanego zapytania osoba niepożądana może przeprogramować systemy uczenia maszynowego tak, aby wykonywały zadania niezgodne z pierwotnym zamiarem ich twórcy. Integralność, dostępność Badacze pokazali, w jaki sposób przeprogramowali system ImageNet, służący do klasyfikowania obrazów do jednej z kilku kategorii, tak aby obliczał kwadraty liczb. Autorzy kończą dokument hipotetycznym scenariuszem: Osoba atakująca wysyła obrazy Captcha do klasyfikatora przetwarzania obrazów w usłudze zdjęć hostowanych w chmurze w celu rozwiązania captchas obrazu w celu utworzenia kont spamu[9]
7 Przykład niepożądany w domenie fizycznej Niepożądany przykład to dane wejściowe/zapytanie ze złośliwej jednostki wysłanej wyłącznie w celu wprowadzenia w błąd systemu uczenia maszynowego Te przykłady mogą manifestować się w domenie fizycznej Integralność Naukowcy 3D drukuje karabin z niestandardową teksturą, która oszukać system rozpoznawania obrazów do myślenia, że jest żółwiem[10]

Badacze opracowali okulary przeciwsłoneczne, których kształt pozwala oszukać systemy do rozpoznawania obrazów, przez co nie rozpoznają one prawidłowo twarzy.[11]

8 Złośliwy dostawca ML może odtworzyć dane treningowe Złośliwy dostawca ML może wysyłać zapytania do modelu używanego przez klienta i odtworzyć dane treningowe klienta Poufności Naukowcy pokazali, w jaki sposób złośliwy dostawca może wprowadzić do algorytmu tylne wejście i odtworzyć prywatne dane treningowe. Dysponując tylko modelem, byli w stanie odtworzyć twarze i tekst. [12]
9 Atak na łańcuch dostaw ML [13] Ze względu na duże zasoby (dane i obliczenia) wymagane do trenowania algorytmów, bieżącą praktyką jest ponowne użycie modeli trenowanych przez duże korporacje i nieznaczne zmodyfikowanie ich pod kątem zadań (np. ResNet jest popularnym modelem rozpoznawania obrazów firmy Microsoft). Te modele są przechowywane w tak zwanym zoo modeli (popularne modele rozpoznawania obrazów są hostowane na platformie Caffe). W tym przypadku atakujący przeprowadza atak na modele hostowane na platformie Caffe, w ten sposób „zatruwając źródło”, z którego korzystają wszyscy. Integralność Badacze pokazali, w jaki sposób atakujący może zaewidencjonować złośliwy kod w jednym z popularnych modeli. Następnie niczego niepodejrzewający deweloper ML może pobrać ten model i użyć go w kodzie swojego systemu do rozpoznawania obrazów [14]. Autorzy pokazali, że na platformie Caffe znajduje się model, którego skrót SHA1 NIE pasuje do wartości skrótu autora, co wskazuje na manipulację. Istnieją też 22 modele, które nie mają żadnego skrótu SHA1 na potrzeby kontroli integralności.
10 Tylne wejście w systemie ML Podobnie jak w przypadku ataku na łańcuch dostaw ML, w tym scenariuszu proces trenowania zostaje w całości lub w części powierzony niepożądanej osobie, która chce dostarczyć użytkownikowi wytrenowany model zawierający tylne wejście. Model z tylnym wejściem będzie działał poprawnie w przypadku większości danych wejściowych (w tym takich przechowywanych przez użytkownika końcowego jako zestaw weryfikacyjny) — ale w przypadku danych wejściowych spełniających jakąś tajną, wybraną przez atakującego właściwość (którą nazwiemy tutaj „wyzwalaczem tylnego wejścia) będzie zwracał celowo nieprawidłowe klasyfikacje lub działał z pogorszoną dokładnością. Poufność, integralność Naukowcy opracowali klasyfikator amerykańskich znaków drogowych z tylnym wejściem, który rozpoznaje znaki stop jako znaki ograniczenia prędkości, jeśli jest na nich umieszczona specjalna naklejka (wyzwalacz tylnego wejścia).[20] Obecnie pracują nad rozszerzeniem tego procesu na systemy przetwarzania tekstu, aby zastępować określone słowa innymi, gdy pojawi się wyzwalacz w postaci określonego akcentu osoby mówiącej.[15]
11 Wykorzystanie zależności oprogramowania systemu ML W tym scenariuszu atakujący NIE manipuluje algorytmami. Zamiast tego wykorzystuje tradycyjne luki w zabezpieczeniach oprogramowania, takie jak przepełnienie buforu. Poufność, integralność, dostępność, Osoba niepożądana przesyła uszkodzone dane wejściowe do systemu rozpoznawania obrazów, aby spowodować nieprawidłową klasyfikację, wykorzystując usterkę oprogramowania w jednej z zależności.

Szczegóły awarii niezamierzonych

Nr scenariusza Klasa ataku opis Typ naruszenia Scenariusz
12 Naruszenie nagród Systemy uczenia przez wzmacnianie (RL) działają w niezamierzony sposób z powodu niezgodności między określoną nagrodą a rzeczywiście zamierzoną nagrodą. Sejf ty systemu Tu zebrano ogromny korpus przykładów dotyczących gier z wykorzystaniem sztucznej inteligencji: [1]
13 Efekty uboczne System RL zakłóca środowisko, gdy próbuje osiągnąć swój cel Sejf ty systemu Scenariusz cytowany za autorami publikacji [2]: „załóżmy, że projektant chce, aby agent RL (na przykład nasz robot sprzątający) osiągnął określony cel, na przykład przeniósł pudełko z jednego końca pokoju na drugi. Czasem najbardziej efektywny sposób osiągnięcia tego celu wymaga zrobienia czegoś innego, co wpływa destrukcyjnie na pozostałą część środowiska — na przykład przewrócenia wazonu pełnego wody, stojącego robotowi na drodze. Jeśli agent otrzymuje nagrodę tylko za samo przeniesienie pudełka, prawdopodobnie przewróci ten wazon”.
14 Zmiany dystrybucji System jest testowany w jednym rodzaju środowiska, ale nie jest w stanie dostosować się do zmian w innych rodzajach środowiska Bezpieczeństwo systemu Badacze wytrenowali dwóch nowoczesnych agentów RL, Rainbow DQN i A2C, do omijania lawy w symulacji. W trakcie szkolenia agent RL z powodzeniem omijał lawę i docierał do celu. Podczas testowania nieznacznie zmieniono położenie lawy, a agent RL nie był już w stanie jej omijać.[3]
15 Naturalne przykłady niepożądane System nieprawidłowo rozpoznaje dane wejściowe, które zostały znalezione przy użyciu twardego negatywnego wyszukiwania Bezpieczeństwo systemu Autorzy wykazali, że prosty proces twardego negatywnego wyszukiwania danych[4] wystarczy, aby zmylić system ML przy przekazaniu przykładu.
16 Zwykłe uszkodzenie System nie jest w stanie poradzić sobie ze zwykłymi uszkodzeniami i zakłóceniami, takich jak pochylenie, powiększenie, czy zniekształcenie obrazu. Bezpieczeństwo systemu Autorzy[5] pokazują, jak typowe uszkodzenia, takie jak zmiany jasności, kontrastu, mgły lub szumu dodane do obrazów, mają znaczący spadek metryk w rozpoznawaniu obrazów
17 Niewystarczające testy w realistycznych warunkach System ML nie jest testowany w realistycznych warunkach, w których ma działać Bezpieczeństwo systemu Autorzy badania [25] podkreślają, że choć mechanizmy obrony zwykle uwzględniają niezawodność algorytmu ML, pomijają często kwestię realistycznych warunków. Podają na przykład, że w rzeczywistych warunkach bardziej prawdopodobne jest przewrócenie znaku drogowego przez wiatr niż atak mający na celu manipulację danymi wejściowymi systemu.

Podziękowania

Chcielibyśmy podziękować Andrew Mashallowi, Magnusowi Nystromowi, Johnowi Waltonowi, Johnowi Lambertowi, Sharon Xia, Andiemu Comissoneru, Emre Kicimanowi, Sharon Gillet, członkom zespołu ds. zabezpieczeń w ramach komisji firmy Microsoft ds. sztucznej inteligencji i etyki w inżynierii i badaniach (AETHER), Amarowi Asharowi, Samuelowi Kleinowi, Jonathanowi Zittrainowi oraz członkom grupy roboczej ds. bezpieczeństwa sztucznej inteligencji w ośrodku badawczym Berkman Klein za cenne uwagi. Pragniemy także podziękować recenzentom reprezentującym 23 partnerów zewnętrznych, organizację normalizacyjną i instytucje rządowe, którzy pomogli nam w przygotowaniu tej taksonomii.

Bibliografia

Li, Guofu i in. "Security Matters: A Survey on Adversarial Machine Edukacja". arXiv preprint arXiv:1810.07339 (2018).

[2] Chakraborty, Anirban i in. "Ataki niepożądane i obrony: badanie". arXiv preprint arXiv:1810.00069 (2018).

[3] Ortega, Pedro i Vishal Maini. "Tworzenie bezpiecznej sztucznej inteligencji: specyfikacja, niezawodność i pewność". DeepMind Sejf ty Research Blog (2018).

[4] Amodei, Dario i in. "Konkretne problemy w bezpieczeństwie sztucznej inteligencji". arXiv preprint arXiv:1606.06565 (2016).

[5] Shankar Siva Kumar, Ram, et al. "Law and Adversarial Machine Edukacja". arXiv preprint arXiv:1810.10731 (2018).

[6] Calo, Ryan, et al. "Is Tricking a Robot Hacking?". University of Washington School of Law Research Paper 2018-05 (2018).

[7] Paschali, Magdalini, et al. "Generalizability vs. Robustness: Adversarial Examples for Medical Imaging". arXiv preprint arXiv:1804.00504 (2018).

[8] Ebrahimi, Javid, Daniel Lowd, Dejing Dou. "W przypadku niepożądanych przykładów dla neuronowego tłumaczenia maszynowego na poziomie znaków", arXiv preprint arXiv:1806.09030 (2018)

[9] Carlini, Nicholas i David Wagner. "Przykłady niepożądane audio: ukierunkowane ataki na mowę na tekst." arXiv preprint arXiv:1801.01944 (2018).

[10] Jagielski, Matthew i in. "Manipulowanie uczeniem maszynowym: zatrucie ataków i środków zaradczych na potrzeby uczenia regresji". 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 (Ataki metodą odwrócenia modelu wykorzystujące informacje o pewności oraz podstawowe sposoby przeciwdziałania im).

[13] Shokri R, Stronati M, Song C, Shmatikov V. 2017. Membership inference attacks against machine learning models (Ataki na modele uczenia maszynowego oparte na wnioskowaniu o członkostwie). W: Proc. of the 2017 IEEE Symp. on Security and Privacy (SP)(Materiały z konferencji IEEE nt. bezpieczeństwa i prywatności 2017), San Jose, Kalifornia, 22–24 maja 2017 r., ss. 3–18. Nowy Jork, NY: IEEE.

[14] Tramèr, Teresa i in. "Stealing Machine Edukacja Models via Prediction APIs" (Kradzież maszyny Edukacja modeli za pośrednictwem interfejsów API przewidywania). Sympozjum USENIX Security. 2016

[15] Elsayed, Gamaleldin F., Ian Goodfellow, Jascha Sohl-Dickstein. "Niepożądane przeprogramowanie sieci neuronowych". arXiv preprint arXiv:1806.11146 (2018).

[16] Athalye, Anish i Ilya Sutskever. "Synchronizowanie niezawodnych przykładów niepożądanych". arXiv preprint arXiv:1707.07397(2017)

[17] Sharif, Mahmood, et al. "Adversarial Generative Nets: Neural Network Attacks on State-of-the-Art Face Recognition". arXiv preprint arXiv:1801.00349 (2017).

[19] Xiao, Qixue, et al. "Security Risks in Deep Edukacja Implementations". arXiv preprint arXiv:1711.11008 (2017).

[20] Gu, Tianyu, Brendan Dolan-Gavitt, Siddharth Garg. "Badnets: Identyfikowanie luk w zabezpieczeniach w łańcuchu dostaw modelu uczenia maszynowego". 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 i in. "Konkretne problemy w bezpieczeństwie sztucznej inteligencji". arXiv preprint arXiv:1606.06565 (2016).

[24] Leike, Jan i in. "AI safety gridworlds". arXiv preprint arXiv:1711.09883 (2017).

[25] Gilmer, Justin i in. "Motywowanie zasad gry do niepożądanych przykładowych badań." arXiv preprint arXiv:1807.06732 (2018).

[26] Hendrycks, Dan i Thomas Dietterich. "Benchmarking neural network robustness to common corruptions and perturbations". arXiv preprint arXiv:1903.12261 (2019).