Modos de falha no Machine Learning
| Microsoft Corporation | Berkman Klein Center for Internet and Society da Universidade de Harvard |
|---|---|
Novembro de 2019
Introdução e contexto
Nos últimos dois anos, mais de 200 artigos foram escritos sobre como o ML (Machine Learning) pode falhar devido a ataques de adversário nos algoritmos e dados e, esse número aumenta se incorporarmos modos de falha que não são de adversário. A série de artigos dificultou para os profissionais de ML, como engenheiros, advogados e legisladores, acompanhar os ataques e as defesas dos sistemas do ML. No entanto, à medida que esses sistemas se tornam mais difundidos, haverá uma urgência para entender como eles falham, seja à mão de um adversário ou devido ao design inerente de um sistema. A finalidade deste documento é tabular em conjunto os dois modos de falha em um único local.
Falhas intencionais, em que a falha é causada por um adversário ativo tentando subverter o sistema para atingir metas – seja para classificar incorretamente o resultado, inferir dados de treinamento privados ou roubar o algoritmo subjacente.
Falhas não intencionais, em que a falha ocorre porque um sistema ML produz um resultado formalmente correto, mas completamente inseguro.
Gostaríamos de ressaltar que existem outras taxonomias e estruturas que destacam individualmente os modos de falha intencional[1],[2]e os modos de falha não intencional[3],[4]. Nossa classificação reúne os dois modos de falha separados em um único local e atende às seguintes necessidades:
A necessidade de equipar desenvolvedores de software, respondentes de incidentes de segurança, advogados e legisladores com um idioma comum para falar sobre esse problema. Após desenvolver a versão inicial da taxonomia no ano passado, trabalhamos com equipes de segurança e ML na Microsoft, 23 parceiros externos, organização de padrões e governos para entender como os stakeholders usariam nossa estrutura. Com base neste estudo de usabilidade e nos comentários do stakeholder, iteramos na estrutura.
Resultados: quando nos deparamos com um modo de falha do ML, frequentemente observamos que advogados e desenvolvedores de software mapearam mentalmente os modos de falha do ML para ataques tradicionais de software, como a exfiltração dos dados. Portanto, ao longo do artigo, tentamos destacar como os modos de falha do aprendizado de máquina são significativamente diferentes das falhas tradicionais de software, do ponto de vista de tecnologia e política.
A necessidade de uma plataforma comum para que os engenheiros possam usar como base e integrar às práticas de segurança e desenvolvimento de software existentes. Em geral, queríamos que a taxonomia fosse mais do que uma ferramenta educacional, queremos que ela produza resultados tangíveis de engenharia.
Resultados: usando essa taxonomia como uma lente, a Microsoft modificou o processo do Security Development Lifecycle (SDL) para toda a organização. Especificamente, cientistas de dados e engenheiros de segurança da Microsoft agora compartilham o idioma comum dessa taxonomia, permitindo que eles usem um modelo de ameaça com mais eficácia nos sistemas do ML deles antes de implantar na produção; Os Respondentes a Incidentes de Segurança também têm uma barra de bug para fazer a triagem dessas novas ameaças específicas ao ML, o processo padrão de triagem e resposta de vulnerabilidades usado pelo Microsoft Security Response Center e por todas as equipes de produtos da Microsoft.
A necessidade de um vocabulário comum para descrever esses ataques entre legisladores e advogados. Acreditamos que isso para descrever diferentes modos de falha do ML e a analisar como seus danos podem ser regulamentados é uma primeira etapa significativa para políticas informadas.
Resultados: essa taxonomia é escrita para um amplo público interdisciplinar, portanto, os legisladores que estão analisando os problemas de uma perspectiva geral do ML/IA, bem como domínios específicos como desinformação/assistência médica, devem achar útil o catálogo do modo de falha. Também destacamos todas as intervenções legais aplicáveis para resolver os modos de falha.
Veja também os Sistemas e dependências de IA/ML da modelagem de ameaças e Documentos originais da barra de bug do SDL para vulnerabilidades do Machine Learning da Microsoft.
Como usar este documento
No início, reconhecemos que este é um documento dinâmico que evoluirá ao longo do tempo com o panorama de ameaças. Também não preparamos mitigações tecnológicas para esses modos de falha, pois as defesas são específicas do cenário e se unem ao modelo de ameaça e à arquitetura do sistema em consideração. As opções apresentadas para mitigação de ameaças se baseiam na pesquisa atual com a expectativa de que essas defesas evoluam ao longo do tempo.
Para engenheiros, é recomendável navegar pela visão geral de possíveis modos de falha e analisar o documento modelagem de ameaças. Dessa forma, os engenheiros podem identificar ameaças, ataques, vulnerabilidades, e usar a estrutura para planejar contramedidas quando disponíveis. Em seguida, encaminhamos você à barra de bug que mapeia essas novas vulnerabilidades na taxonomia junto com as vulnerabilidades tradicionais de software e fornece uma classificação para cada vulnerabilidade do ML (como crítica, importante). Essa barra de bugs é facilmente integrada aos processos/guias estratégicos de resposta a incidentes existentes.
Para advogados e legisladores, esse documento organiza os modos de falha do ML e apresenta uma estrutura para analisar os principais problemas relevantes para qualquer pessoa que explora as opções de política, como o trabalho feito aqui [5],[6]. Especificamente, categorizamos as falhas e as consequências de uma maneira que os legisladores possam começar a desenhar as distinções entre as causas, o que informará as iniciativas de política pública para promover a segurança do ML. Esperamos que os legisladores usem essas categorias para começar a entender como os regimes legais existentes podem (não) capturar adequadamente problemas emergentes, quais regimes legais históricos ou soluções políticas podem ter lidado com danos semelhantes e onde devemos ser especialmente sensíveis a questões relativas às liberdades cívicas.
Estrutura do documento
Nas seções Modos de falha intencional e Modos de falha não intencional, fornecemos uma breve definição do ataque e um exemplo ilustrativo da literatura.
Na seção Modos de falha intencional, fornecemos os campos adicionais:
O que o ataque tenta comprometer no sistema do ML – Confidencialidade, Integridade ou Disponibilidade? Definimos Confidencialidade como garantia de que os componentes do sistema do ML (dados, algoritmo, modelo) sejam acessíveis somente por partes autorizadas; Integridade é definida como garantir que o sistema do ML possa ser modificado somente por partes autorizadas; Disponibilidade é definida como uma garantia de que o sistema do ML está acessível a partes autorizadas. Juntos, a Confidencialidade, a Integridade e a Disponibilidade são chamadas de tríade CIA. Para cada modo de falha intencional, tentamos identificar qual das partes da tríade CIA está comprometida.
Quanto conhecimento é necessário para montar esse ataque – caixa preta ou caixa branca? Nos ataques de estilo caixa preta, o invasor NÃO tem acesso direto aos dados de treinamento, não tem conhecimento do algoritmo do ML usado e não tem acesso ao código-fonte do modelo. O invasor consulta somente o modelo e observa a resposta. Em um ataque de estilo caixa branca, o invasor tem conhecimento de um algoritmo do ML ou acesso ao código-fonte do modelo.
Comentários sobre se o invasor está violando a noção tecnológica tradicional de acesso/autorização.
Resumo de falhas motivadas intencionalmente
Resumo de falhas não intencionais
Detalhes sobre falhas motivadas intencionalmente
| Cenário n.º | Classe do ataque | Descrição | Tipo de comprometimento | Cenário |
|---|---|---|---|---|
| 1 | Ataques de perturbação | Em ataques de estilo de perturbação, o invasor furtivamente modifica a consulta para obter uma resposta desejada | Integridade | Imagem: o ruído é adicionado a uma imagem de raio-X, que faz com que as previsões passem de uma verificação normal para anormal [1][Caixa preta] Tradução de texto: caracteres específicos são manipulados para resultar em tradução incorreta. O ataque pode suprimir uma palavra específica ou até mesmo remover completamente a palavra[2][Caixa preta e Caixa branca] Fala: os pesquisadores mostraram como uma waveform de fala é fornecida, outra waveform pode ser exatamente replicada, mas transcreve em um texto totalmente diferente [3][Caixa branca, mas pode ser estendida para caixa preta] |
| 2 | Ataques por envenenamento | A meta do invasor é contaminar o modelo do computador gerado na fase de treinamento, para que as previsões sobre novos dados sejam modificadas na fase de teste Direcionados: em ataques por envenenamento direcionados, o invasor deseja classificar exemplos específicos incorretamente Indiscriminados: a meta aqui é causar um efeito de ataque de negação de serviço, que é o que o torna o sistema indisponível. |
Integridade | Em um conjunto de dados médicos em que o objetivo é prever a dosagem da droga anticoagulante Varfarina usando informações demográficas, etc. Os pesquisadores introduziram amostras maliciosas na taxa de intoxicação de 8%, o que mudou a dosagem em 75,06% para metade dos pacientes [4][Blackbox] No chatbot Tay, as conversas futuras foram afetadas porque uma fração das conversas passadas foi usada para treinar o sistema por meio de comentários [5] [Caixa preta] |
| 3 | Inversão do modelo | Os recursos privados usados em modelos de machine learning podem ser recuperados | Confidencialidade: | os pesquisadores conseguiram recuperar dados de treinamento privados usados para treinar o algoritmo [6] Os autores foram capazes de reconstruir faces, apenas pelo nome e acesso ao modelo, até o ponto em que os Mechanical Turks pudessem usar a foto para identificar um indivíduo de linha com 95% de precisão. Os autores também puderam extrair informações específicas. [Caixa branca e Caixa preta] [12] |
| 4 | Ataque de inferência de associação | O invasor pode determinar se um determinado registro de dados faz parte ou não do conjunto de dados de treinamento do modelo | Confidencialidade | Os pesquisadores foram capazes de prever o procedimento principal de um paciente (por exemplo: cirurgia pela qual o paciente passou) com base nos atributos (por exemplo: idade, sexo, hospital) [7] [Caixa preta] |
| 5 | Roubo de modelos | Os invasores recriam o modelo subjacente consultando legitimamente o modelo. A funcionalidade do novo modelo é a mesma do modelo subjacente. | Confidencialidade | Os pesquisadores emularam com êxito o algoritmo subjacente da Amazon, BigML. Por exemplo, no caso de BigML, os pesquisadores recuperaram o modelo usado para prever se alguém deve ter um risco de crédito bom/ruim (conjunto de dados do cartão de crédito alemão) usando 1.150 consultas e em dez minutos[8] |
| 6 | Reprogramação de redes neurais profundas | Por meio de uma consulta especialmente criada de um adversário, os sistemas de aprendizado de máquina podem ser reprogramados para uma tarefa que se desvia da intenção original do criador | Integridade, disponibilidade | Demonstrou como o ImageNet, um sistema usado para classificar uma das várias categorias de imagens foi realocado para contar os quadrados. Os autores terminam o documento com um cenário hipotético: um invasor envia imagens Captcha para o classificador de Pesquisa Visual Computacional em um serviço de fotos hospedadas na nuvem para resolver as Captchas da imagem para criar contas de spam [9] |
| 7 | Exemplo de adversário no domínio físico | Um exemplo de adversário é uma entrada/consulta de uma entidade mal-intencionada enviada com o único objetivo de enganar o sistema de aprendizado de máquina. Esses exemplos podem ser manifestados no domínio físico | Integridade | Pesquisadores imprimem em 3D um rifle com textura personalizada que engana o sistema de reconhecimento de imagem, pensando que é uma tartaruga [10] Os pesquisadores constroem o óculos com um design que agora pode enganar os sistemas de reconhecimento de imagem e não reconhece mais os rostos corretamente[11] |
| 8 | Provedores do ML mal-intencionados que podem recuperar dados de treinamento | O provedor do ML mal-intencionado pode consultar o modelo usado pelo cliente e recuperar os dados de treinamento do cliente | Confidencialidade | Os pesquisadores mostram como um provedor mal-intencionado apresenta um algoritmo com backdoor, no qual os dados de treinamento privado são recuperados. Eles conseguiram reconstruir rostos e textos, considerando apenas o modelo. [12] |
| 9 | Ataque à cadeia de suprimentos do ML[13] | Devido a recursos grandes (dados + computação) necessários para treinar algoritmos, a prática atual é reutilizar modelos treinados por grandes empresas e modificá-los um pouco para a tarefa em questão (por exemplo: ResNet é um modelo de reconhecimento de imagem popular da Microsoft). Esses modelos são coletados no Model Zoo (o Caffe hospeda modelos populares de reconhecimento de imagem). Nesse ataque, o adversário ataca os modelos hospedados no Caffe, o que, portanto, envenena para qualquer outra pessoa. | Integridade | Os pesquisadores mostram como é possível que um invasor faça check-in de código mal-intencionado em um dos modelos populares. Um desenvolvedor do ML insuspeito baixa esse modelo e o usa como parte do sistema de reconhecimento de imagem no código dele [14]. Os autores mostram como existe um modelo no Caffe cujo hash SHA1 NÃO corresponde ao resumo da mensagem dos autores, indicando adulteração. Há 22 modelos sem nenhum hash SHA1 para verificações de integridade. |
| 10 | Machine Learning de backdoor | Como no "Ataque à cadeia de suprimentos do ML", nesse cenário de ataque, o processo de treinamento é totalmente ou parcialmente terceirizado para uma parte mal-intencionada que deseja fornecer ao usuário um modelo treinado que contenha um backdoor. O modelo com backdoor teria bom desempenho na maioria das entradas (incluindo entradas que o usuário final pode conter como um conjunto de validação), mas causaria erros de classificação direcionados ou degradaria a precisão do modelo para entradas que satisfazem alguma propriedade secreta escolhida pelo invasor, que iremos referir como o gatilho de backdoor | Confidencialidade, integridade | Os pesquisadores criaram um classificador de sinalização de rua dos EUA, com backdoor, que identifica os sinais de parada como limites de velocidade somente quando um adesivo especial é adicionado ao sinal de parada (gatilho de backdoor) 20 Eles agora estão estendendo esse trabalho aos sistemas de processamento de texto, onde palavras específicas são substituídas pelo gatilho, que é o sotaque do orador[15] |
| 11 | Explorar dependências do software de sistema do ML | Nesse ataque, o invasor NÃO manipula os algoritmos. Em vez disso, explora vulnerabilidades tradicionais de software, como estouros de buffer. | Confidencialidade, integridade, disponibilidade, | Um adversário envia uma entrada corrompida para um sistema de reconhecimento de imagem que faz com que ele seja classificado incorretamente explorando um bug de software em uma das dependências. |
Detalhes sobre falhas não intencionais
| Cenário n.º | Classe do ataque | Descrição | Tipo de comprometimento | Cenário |
|---|---|---|---|---|
| 12 | Pirataria de recompensas | Os sistemas de aprendizado de reforço atuam de formas involuntárias devido a discrepâncias entre a recompensa especificada e a recompensa pretendida real. | Segurança do sistema | Um enorme corpus de exemplos de jogos na IA foi compilado aqui[1] |
| 13 | Efeitos colaterais | O sistema de RL interrompe o ambiente à medida que tenta atingir sua meta | Segurança do sistema | Cenário, literalmente dos autores em[2]: "Suponha que um designer deseja que um agente de RL (por exemplo, nosso robô de limpeza) alcance alguma meta, como mover uma caixa de um lado para outro da sala. Às vezes, a maneira mais eficaz de alcançar a meta envolve fazer algo não relacionado e destrutivo para o restante do ambiente, como derrubar um vaso de água que está em seu caminho. Se o agente receber recompensa apenas para mover a caixa, provavelmente derrubará o vaso". |
| 14 | Turnos de distribuição | O sistema é testado em um tipo de ambiente, mas não é capaz de se adaptar a alterações em outros tipos de ambiente | Segurança do sistema | Os pesquisadores treinaram dois agentes de RL de última geração, Rainbow DQN e A2C em uma simulação para evitar lava. Durante o treinamento, os agentes de RL conseguiram evitar lava com êxito e alcançar a meta. Durante o teste, eles moveram levemente a posição da lava, mas os agentes de RL não foram capazes de evitar [3] |
| 15 | Exemplos de adversário natural | O sistema reconhece incorretamente uma entrada encontrada usando a mineração negativa grave | Segurança do sistema | Aqui, os autores mostram como, por um processo simples de mineração negativa grave[4], é possível confundir o sistema do ML retransmitindo o exemplo. |
| 16 | Dados corrompidos | O sistema não é capaz de lidar com corrupções comuns e perturbações, como inclinação, zoom ou imagens ruidosas. | Segurança do sistema | Os autores [5] mostram como os danos comuns, como alterações no brilho, no contraste, na neblina ou no ruído adicionadas às imagens, têm uma queda significativa nas métricas do reconhecimento de imagem |
| 17 | Teste incompleto em condições realísticas | O sistema do ML não é testado nas condições realistas nas quais ele se destina a operar | Segurança do sistema | Os autores em [25] destacam que, enquanto os defensores costumam considerar a robustez do algoritmo do ML, eles perdem de vista condições realistas. Por exemplo, eles argumentam que um sinal de parada desaparecido foi arremessado pelo vento (o que é mais realista) do que um invasor tentando perturbar as entradas do sistema. |
Confirmações
Gostaríamos de agradecer a Andrew Marshall, Magnus Nystrom, John Walton, John Lambert, Sharon Xia, Andi Comissoneru, Emre Kiciman, Jugal Parikh, Sharon Gillet, membros do fluxo de trabalho de segurança do comitê da AETHER (AI and Ethics in Engineering and Research)da Microsoft, Amar Ashar, Samuel Klein, Jonathan Zittrain, membros do AI Safety Security Working Group da Berkman Klein por fornecer comentários úteis. Além disso, gostaríamos de agradecer aos revisores de 23 parceiros externos, organização de padrões e organizações governamentais pela definição da taxonomia.
Bibliografia
[1] Li, Guofu, et al. "Security Matters: A Survey on Adversarial Machine Learning." arXiv preprint arXiv:1810.07339 (2018), (Questões de segurança: uma pesquisa sobre aprendizado de máquina de adversário, em tradução livre).
[2] Chakraborty, Anirban, et al. "Adversarial attacks and defences: A survey." arXiv preprint arXiv:1810.00069 (2018), (Ataques e defesas de adversário, em tradução livre).
[3] Ortega, Pedro e Vishal Maini. "Building safe artificial intelligence: specification, robustness, and assurance." DeepMind Safety Research Blog (2018), (Como construir inteligência artificial segura: especificação, robustez e garantia, em tradução livre).
[4] Amodei, Dario, et al. "Concrete problems in AI safety." arXiv preprint arXiv:1606.06565 (2016), (Problemas concretos na segurança da IA, em tradução livre).
[5] Shankar Siva Kumar, Ram, et al. "Law and Adversarial Machine Learning." arXiv preprint arXiv:1810.10731 (2018), (A lei e o aprendizado de máquina de adversário, em tradução livre).
[6] Calo, Ryan, et al. "Is Tricking a Robot Hacking?." University of Washington School of Law Research Paper 2018-05 (2018), (Enganar um robô é raquear?, em tradução livre).
[7] Paschali, Magdalini, et al. "Generalizability vs. Robustness: Adversarial Examples for Medical Imaging." arXiv preprint arXiv:1804.00504 (2018), (Generalização x robustez: exemplos de adversários para serviços de imagens diagnósticas, em tradução livre).
[8] Ebrahimi, Javid, Daniel Lowd e Dejing Dou. "On Adversarial Examples for Character-Level Neural Machine Translation." arXiv preprint arXiv:1806.09030 (2018), (Sobre exemplos de adversário para tradução automática neural em nível de caracteres, em tradução livre).
[9] Carlini, Nicholas e David Wagner. "Audio adversarial examples: Targeted attacks on speech-to-text." arXiv preprint arXiv:1801.01944 (2018), (Exemplos de adversário de áudio: ataques direcionados em reconhecimento de fala, em tradução livre).
[10] Jagielski, Matthew, et al. "Manipulating machine learning: Poisoning attacks and countermeasures for regression learning." arXiv preprint arXiv:1804.00308 (2018) (Como manipular o aprendizado de máquina: ataques de envenenamento e medidas defensivas para o aprendizado de regressão, em tradução livre)
[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
[13] Shokri R, Stronati M, Song C, Shmatikov V. 2017. Membership inference attacks against machine learning models. Em Proc. of the 2017 IEEE Symp. on Security and Privacy (SP), San Jose, CA, 22 a 24 de maio de 2017, págs. 3–18. Nova Iorque, NY: IEEE.
[14] Tramèr, Florian, et al. "Stealing Machine Learning Models via Prediction APIs." USENIX Security Symposium, (Como roubar modelos de machine learning por meio de APIs de previsão, em tradução livre). 2016.
[15] Elsayed, Gamaleldin F., Ian Goodfellow, and Jascha Sohl-Dickstein. "Adversarial Reprogramming of Neural Networks." arXiv preprint arXiv:1806.11146 (2018), (Reprogramação de adversário de redes neurais, em tradução livre).
[16] Athalye, Anish e Ilya Sutskever. "Synthesizing robust adversarial examples." arXiv preprint arXiv:1707.07397(2017) (Como sintetizar exemplos de adversários robustos, em tradução livre)
[17] Sharif, Mahmood, et al. "Adversarial Generative Nets: Neural Network Attacks on State-of-the-Art Face Recognition." arXiv preprint arXiv:1801.00349 (2017), (Redes geradoras de adversários: ataques de redes neurais em reconhecimento facial de última geração, em tradução livre).
[19] Xiao, Qixue, et al. "Security Risks in Deep Learning Implementations." arXiv preprint arXiv:1711.11008 (2017), (Riscos de segurança em implementações de aprendizado profundo, em tradução livre).
[20] Gu, Tianyu, Brendan Dolan-Gavitt, and Siddharth Garg. "Badnets: Identifying vulnerabilities in the machine learning model supply chain." arXiv preprint arXiv:1708.06733 (2017) (Redes ruins: como identificar vulnerabilidades na cadeia de fornecedores do modelo de machine learning, em tradução livre)
[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. "Concrete problems in AI safety." arXiv preprint arXiv:1606.06565 (2016), (Problemas concretos em segurança de IA, em tradução livre).
[24] Leike, Jan, et al. "AI safety gridworlds." arXiv preprint arXiv:1711.09883 (2017), (Gridworlds de segurança de IA, em tradução livre).
[25] Gilmer, Justin, et al. "Motivating the rules of the game for adversarial example research." arXiv preprint arXiv:1807.06732 (2018), (Como motivar as regras do jogo para a pesquisa de exemplo de adversário, em tradução livre).
[26] Hendrycks, Dan e Thomas Dietterich. "Benchmarking neural network robustness to common corruptions and perturbations." arXiv preprint arXiv:1903.12261 (2019), (Como obter um parâmetro de comparação da robustez da rede neural com os danos e perturbações comuns, em tradução livre).
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de