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 & tle

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: Często obserwowaliśmy, że przy zetknięciu z awarią systemu ML deweloperzy oprogramowania i prawnicy mentalnie mapowali tryby awarii uczenia maszynowego na tradycyjne ataki na oprogramowanie, takie jak wyprowadzenie 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: Na podstawie tej taksonomii firma Microsoft zmodyfikowała swój proces Security Development Lifecycle stosowany w 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 służy to do opisywania różnych trybów awarii ML i analizy tego, jak mogą być regulowane ich szkody, jest znaczącym pierwszym krokiem w kierunku świadomej polityki.

    Wyniki: Ta taksonomia przeznaczona jest dla szerokiego grona odbiorców reprezentujących różne dziedziny. Zaproponowany katalog trybów awarii może być przydatny dla prawodawców zajmujących się ogólnymi zagadnieniami związanymi z uczeniem maszynowym i sztuczną inteligencją, a także dla tych zainteresowanych bardziej szczegółowymi aspektami, takimi jak opieka zdrowotna czy zwalczanie dezinformacji. 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
Atakujący wprowadza niepożądane przykłady do domeny fizycznej w celu naruszenia systemu ML, na przykład: przy użyciu druku 3D tworzy specjalne okulary, 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 zakłócające Podczas ataku zakłócającego atakujący niepostrzeżenie modyfikuje zapytanie w celu uzyskania określonej odpowiedzi. Integralność Obraz: Szum jest dodawany do obrazu rentgenowskiego, co sprawia, że przewidywania przechodzą z normalnego skanowania do nietypowego [1][Blackbox]

Tłumaczenie tekstu: manipulowanie określonymi znakami powoduje niepoprawne tłumaczenie. Atak pozwala pominąć określone słowo lub całkowicie je usunąć.[2][blackbox i whitebox]

Mowa: badacze udowodnili, że dany kształt fali mowy można zreplikować tak, aby otrzymany kształt fali był identyczny, ale po transkrypcji dawał całkiem inny tekst.[3][whitebox, chociaż można rozszerzyć na atak typu blackbox]

2 Ataki zatruwające Celem atakującego jest zmodyfikowanie modelu maszynowego generowanego w fazie uczenia, co przekłada się na zmianę przewidywań tworzonych na podstawie nowych danych w fazie testowania.

Atak celowany: w przypadku celowanego ataku zatruwającego atakujący dąży do nieprawidłowego sklasyfikowania określonych przykładów.

Atak nieograniczony: W tym przypadku celem jest wywołanie efektu przypominającego atak typu „odmowa usługi”, który powoduje niedostępność systemu.

Integralność W zestawie danych medycznych przeznaczonym do przewidywania dawkowania warfaryny, leku przeciwkrzepliwego, na podstawie cech demograficznych itp. badacze wprowadzili niepożądane próbki, „zatruwając” model w 8%, co spowodowało zmianę przewidzianej dawki o 75,06% w przypadku połowy pacjentów.[4][blackbox]

W czatbocie Tay późniejsze rozmowy zostały zanieczyszczone, gdy część wcześniejszych rozmów wykorzystano do trenowania systemu przy użyciu informacji zwrotnej.[5][blackbox]

3 Odwrócenie modelu Prywatne funkcje używane w modelach uczenia maszynowego można odtworzyć. Poufność Badaczom udało się odtworzyć prywatne dane treningowe używane do trenowania algorytmu.[6] Dysponując tylko nazwiskami i dostępem do modelu, autorzy byli w stanie zrekonstruować twarze w takim stopniu, że osoby klasyfikujące dane potrafiły na podstawie otrzymanego zdjęcia z 95-procentową dokładnością rozpoznać odpowiednią osobę w grupie.  Autorzy wyodrębnili także inne szczegółowe informacje.  [whitebox i blackbox][12]
4 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ść Naukowcy byli w stanie przewidzieć główny zabieg przeprowadzony u pacjenta (na przykład: jaką operację przeszedł pacjent) na podstawie atrybutów (na przykład: płci, wieku, nazwy szpitala).[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ą swoją pracę, przytaczając następujący hipotetyczny scenariusz: atakujący wysyła obrazy captcha do rozpoznającego obrazy klasyfikatora w usłudze do przechowywania zdjęć w chmurze, aby ten rozwiązywał testy captcha, umożliwiając tworzenie kont używanych do rozsyłania spamu.[9]
7 Niepożądany przykład w domenie fizycznej Niepożądany przykład to zapytanie lub dane wejściowe, które atakujący wysyła do systemu uczenia maszynowego wyłącznie w celu oszukania go. Takie przykłady mogą też istnieć w domenie fizycznej. Integralność Używając druku 3D, naukowcy wytworzyli karabin z niestandardową teksturą, przez co system rozpoznawania obrazów klasyfikował jego zdjęcie jako zdjęcie żółwia.[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ść 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żą ilość zasobów (danych i obliczeń) wymaganych do wytrenowania algorytmów, częstą praktyką jest wielokrotne używanie wytrenowanych modeli przez duże firmy, z jedynie niewielkimi zmianami odpowiednimi do danego zadania (na przykład: ResNet, popularny model 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ą. Bezpieczeństwo systemu Tu zebrano ogromny korpus przykładów dotyczących gier z wykorzystaniem sztucznej inteligencji: [1]
13 Efekty uboczne System RL może zakłócać środowisko, próbując osiągnąć swój cel. Bezpieczeństwo 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 środowisku określonego typu, ale nie może przystosować się do zmian w innego typu środowiskach 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 niepożądane przykłady System niepoprawnie rozpoznaje dane wejściowe, znalezione przy użyciu twardego negatywnego wyszukiwania danych. 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 badania[5] wykazali, że typowe uszkodzenia obrazów, na przykład zmiana jasności lub kontrastu czy dodanie zamglenia albo szumu, istotnie pogarszają metryki jakości rozpoznawania obrazów.
17 Niewystarczające testy w realistycznych warunkach System ML nie został przetestowany 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 Marshallowi, Magnusowi Nystromowi, Johnowi Waltonowi, Johnowi Lambertowi, Sharonowi Xia, Andi Comissoneru, Emre Kicimanowi, JugalOwi Parikhowi, Sharonowi Gilletowi, członkom sztucznej inteligencji i etyki w dziedzinie inżynierii i etyki w dziedzinie inżynierii i badań (AETHER), Amar Ashar, Samuel Klein, Jonathan Zittrain, członkowie grupy roboczej bezpieczeństwa sztucznej inteligencji w Berkman Klein za pomocną opinię. 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

[1] Li, Guofu, et al. "Security Matters: A Survey on Adversarial Machine Learning". arXiv preprint arXiv:1810.07339 (2018).

[2] Chakraborty, Anirban, et al. "Niepożądane ataki i obrony: badanie". arXiv preprint arXiv:1810.00069 (2018).

[3] Ortega, Pedro i Vishal Maini. "Tworzenie bezpiecznej sztucznej inteligencji: specyfikacja, niezawodność i pewność". DeepMind Safety 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 Learning". 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. "Na przykładach niepożądanych dla Character-Level neuronowego tłumaczenia maszynowego". arXiv preprint arXiv:1806.09030 (2018)

[9] Carlini, Nicholas i David Wagner. "Przykłady ataków dźwiękowych: ataki ukierunkowane na zamianę mowy na tekst". arXiv preprint arXiv:1801.01944 (2018).

[10] Jagielski, Matthew i in. "Manipulowanie uczeniem maszynowymi: Ataki zatruwające i środki zaradcze 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: IEEE.

[14] Tramèr, Florian, et al. "Kradzież modeli Machine Learning za pośrednictwem interfejsów API przewidywania". Sympozjum zabezpieczeń USENIX. 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. "Synthesizing solid adversarial examples". 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 i in. "Zagrożenia bezpieczeństwa w głębokich implementacjach Edukacja". 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, et al. "AI safety gridworlds". arXiv preprint arXiv:1711.09883 (2017).

[25] Gilmer, Justin, et al. "Motywując zasady gry dla niepożądanych przykładowych badań." arXiv preprint arXiv:1807.06732 (2018).

[26] Hendrycks, Dan i Thomas Dietterich. "Testowanie odporności sieci neuronowej na typowe uszkodzenia i zakłócenia". arXiv preprint arXiv:1903.12261 (2019).