Modelação de Ameaças dos Sistemas e Dependências de IA/ML

Por Andrew Marshall, Jugal Parikh, Emre Kiciman e Ram Shankar Siva Kumar

Agradecimentos especiais a Raul Rojas e ao Grupo de Trabalho de Engenharia de Segurança do Comité AETHER

Novembro de 2019

Este documento é o resultado do Grupo de Trabalho de Práticas de Engenharia para IA do Comité AETHER e complementa as práticas de modelação de ameaças de CVDCS existentes ao proporcionar novas orientações sobre a enumeração e mitigação de ameaças específicas ao espaço do Machine Learning e IA. Destina-se a ser utilizado como referência durante as revisões da conceção da segurança:

1. Produtos/serviços que interagem ou assumem dependências de serviços baseados em IA/ML

2. Produtos/serviços que estão a ser desenvolvidos com IA/ML no seu cerne

A mitigação de ameaças de segurança tradicionais é mais importante do que nunca. Os requisitos estabelecidos pelo Ciclo de Vida de Desenvolvimento Centrado na Segurança são essenciais para a criação de uma base de segurança do produto na qual esta orientação se baseia. Ao não abordar as ameaças de segurança tradicionais está a ajudar a permitir os ataques específicos de IA/ML abordados neste documento tanto no software como nos domínios físicos, bem como a tornar o compromisso trivial mais baixo na pilha do software. Para obter uma introdução às novas ameaças de segurança na rede neste espaço, veja Garantir o Futuro da IA e do ML na Microsoft.

O conjunto de competências dos engenheiros de segurança e dos cientistas de dados normalmente não se sobrepõem. Esta documentação de orientação apresenta uma forma para que ambas as disciplinas tenham conversas estruturadas sobre estas novas ameaças de rede/mitigações sem exigir que os engenheiros de segurança se tornem cientistas de dados ou vice-versa.

Este documento está dividido em duas secções:

1. “Novas Considerações Importantes sobre a Modelação de Ameaças” centra-se em novas formas de pensar e novas perguntas a fazer ao realizar a modelação de ameaças em sistemas de ML/IA. Tanto os cientistas de dados como os engenheiros de segurança devem analisar este documento, dado que será o manual de procedimentos para discussões de modelação de ameaças e atribuição de prioridades de mitigação.
2. “Ameaças específicas de IA/ML e Mitigações” aborda os detalhes sobre ataques específicos, bem como medidas específicas de mitigação em utilização atualmente para proteger os produtos e serviços da Microsoft contra estas ameaças. Esta secção destina-se principalmente a cientistas de dados que podem precisar de implementar mitigações de ameaças específicas, como uma saída do processo de análise de segurança/modelação de ameaças.

Esta orientação é organizada em torno de uma Taxonomia Adversarial de Ameaças de Machine Learning criada por Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen e Jeffrey Snover intitulada "Failure Modes in Machine Learning". Para obter orientações de gerenciamento de incidentes sobre a triagem de ameaças à segurança detalhadas neste documento, consulte a Barra de bugs SDL para ameaças de IA/ML. Todos estes são documentos vivos que evoluirão ao longo do tempo com o cenário de ameaças.

Principais novas considerações na modelagem de ameaças: alterando a maneira como você vê os limites de confiança

Assuma o compromisso/envenenamento dos dados que prepara, bem como o fornecedor de dados. Aprenda a detetar entradas de dados anómalos e maliciosos, bem como a ser capaz de distinguir entre eles e recuperar

Resumo

Os arquivos de Dados de Preparação e os sistemas que os alojam fazem parte do âmbito da Modelação de Ameaças. A maior ameaça de segurança da aprendizagem automática atualmente é o envenenamento dos dados devido à falta de deteções padrão e mitigações neste espaço, combinado com a dependência de conjuntos de dados públicos não fidedignos/não organizados como origens de dados de preparação. Acompanhar a proveniência e a linhagem dos dados é essencial para garantir a fiabilidade e evitar um ciclo de preparação “se entra lixo, sai lixo”.

Perguntas a Fazer numa Revisão de Segurança

• Se os dados forem envenenados ou adulterados, como poderia saber?

  - Que telemetria tem para detetar uma distorção na qualidade dos dados de preparação?

• Está a preparar a partir de entradas enviadas pelo utilizador?

  - Que tipo de validação/limpeza de entradas está a fazer nesse conteúdo?

  - A estrutura destes dados documentados é semelhante às Folhas de Dados dos Conjuntos de Dados?

• Se preparar com arquivos de dados online, que medidas toma para garantir a segurança da ligação entre o modelo e os dados?

  - Têm alguma forma de comunicar os compromissos aos consumidores dos feeds?

  - Têm sequer essa capacidade?

• Qual é o grau de confidencialidade dos dados com os quais faz a preparação?

  - Cataloga-os ou controla a adição/atualização/eliminação das entradas de dados?

• O modelo pode apresentar dados confidenciais?

  - Estes dados foram obtidos com autorização da origem?

• O modelo apresenta apenas os resultados necessários para atingir o objetivo?

• O modelo devolve pontuações de confiança não processadas ou qualquer outra saída direta que possa ser registada e duplicada?

• Qual é o impacto se os dados de preparação forem recuperados por ataque/inversão do modelo?

• Se os níveis de confiança de saída do modelo baixarem subitamente, consegue descobrir como/porquê, bem como os dados que causaram essa queda?

• Definiu uma entrada bem formada para o modelo? O que está a fazer para garantir que as entradas cumprem este formato e o que faz se não o cumprirem?

• Se as saídas estiverem erradas, mas não causarem erros, como saberia?

• Sabe se os algoritmos de preparação são resistentes às entradas adversas a nível matemático?

• Como recupera da contaminação adversa dos dados de preparação?

  - Consegue isolar/colocar em quarentena conteúdo adverso e preparar novamente os modelos afetados?

  - Consegue reverter/recuperar para um modelo de versão anterior para nova preparação?

• Está a utilizar a Aprendizagem de Reforço em conteúdo público não organizado?

• Comece a pensar na linhagem dos dados – se encontrasse um problema, conseguiria rastreá-lo até à sua introdução no conjunto de dados? Se a resposta for não, é um problema?

• Saiba de onde vêm os dados de preparação e identifique as normas estatísticas para começar a entender como são as anomalias

  - Que elementos dos dados de preparação são vulneráveis à influência externa?

  - Quem pode contribuir para os conjuntos de dados a partir dos quais está a preparar?

  - Como é que atacaria as origens de dados de preparação para prejudicar um concorrente?

Ameaças Relacionadas e Mitigações neste Documento

• Perturbação Adversa (todas as variantes)

• Envenenamento de Dados (todas as variantes)

Exemplo de Ataques

• Forçar e-mails benignos a serem classificados como spam ou fazer com que um exemplo malicioso não seja detetado

• Entradas criadas por atacantes que podem reduzir o nível de confiança da classificação correta, especialmente em cenários com consequências elevadas

• O atacante injeta dados irrelevantes aleatoriamente nos dados de origem que estão a ser classificados para reduzir a probabilidade de uma classificação correta ser utilizada no futuro, ao simplificar eficazmente o modelo

• Contaminação dos dados de preparação para forçar a má classificação dos pontos de dados selecionados, o que resulta em ações específicas tomadas ou omitidas por um sistema

Identificar ações que os modelos ou produto/serviço podem tomar que possam causar danos ao cliente online ou no domínio físico

Resumo

Sem mitigação, os ataques aos sistemas de IA/ML podem passar para o mundo físico. Qualquer cenário que possa ser deturpado para prejudicar psicológica ou fisicamente os utilizadores é um risco catastrófico para o produto/serviço. Inclui também quaisquer dados confidenciais sobre os clientes, que são utilizados para a preparação e escolhas a nível de conceção e que podem levar a uma fuga desses pontos de dados privados.

Perguntas a Fazer numa Revisão de Segurança

• Faz a preparação com exemplos adversos? Que impacto têm sobre a saída do modelo no domínio físico?

• Como é o “trolling” para o produto/serviço? Como o pode detetar e resolver?

• O que seria necessário para que o modelo devolvesse um resultado que levasse o serviço a negar o acesso a utilizadores legítimos erradamente?

• Que impacto teria a cópia/roubo do modelo?

• O modelo pode ser utilizado para inferir a associação de uma pessoa individual num determinado grupo ou simplesmente nos dados de preparação?

• Um atacante pode causar danos a nível de reputação ou represálias de relações públicas ao produto, ao forçá-lo a realizar ações específicas?

• Como lida com dados devidamente formatados, mas explicitamente tendenciosos, como os do “trolls”?

• Para cada forma de interagir ou consultar se o modelo está exposto, esse método pode ser interrogado para divulgar dados de preparação ou funcionalidade do modelo?

Ameaças Relacionadas e Mitigações neste Documento

• Inferência de Associação

• Inversão do Modelo

• Roubo de Modelos

Exemplo de Ataques

• Reconstrução e extração de dados de preparação ao consultar repetidamente o modelo para obter resultados de máxima confiança

• Duplicação do próprio modelo por correspondência exaustiva de consulta/resposta

• Consultar o modelo de forma a revelar um elemento específico de dados privados que foi incluído no conjunto de preparação

• Veículo autónomo a ser enganado para ignorar sinais de STOP/semáforos

• Bots de conversação manipulados para apanhar utilizadores benignos

Identificar todas as origens de dependências de IA/ML, bem como as camadas de apresentação de front-end na cadeia de fornecimento de dados/modelo

Resumo

Muitos ataques em IA e Machine Learning começam com o acesso legítimo a APIs que surgem para proporcionar acesso de consulta a um modelo. Devido às origens de dados ricas e às experiências de utilizador ricas envolvidas aqui, autenticadas, mas “inapropriadas” (há aqui uma área cinzenta) o acesso de terceiros aos modelos é um risco, devido à capacidade de agir como uma camada de apresentação acima de um serviço fornecido pela Microsoft.

Perguntas a Fazer numa Revisão de Segurança

• Quais os clientes/parceiros autenticados para aceder ao modelo ou APIs de serviço?

  - Podem funcionar como uma camada de apresentação acima do serviço?

  - Pode revogar o acesso deles rapidamente se ficarem comprometidos?

  - Qual é a estratégia de recuperação em caso de utilização maliciosa do serviço ou das dependências?

• Um terceiro pode criar uma fachada em torno do modelo para renovar e prejudicar a Microsoft ou os seus clientes?

• Os clientes enviam dados de preparação diretamente?

  - Como é que garante a segurança desses dados?

  - E se for malicioso e o serviço for o alvo?

• Como é um falso positivo aqui? Qual é o impacto de um falso negativo?

• Pode rastrear e medir o desvio das taxas de Verdadeiros Positivos vs. Falsos Positivos em vários modelos?

• Que tipo de telemetria precisa para provar a fiabilidade de saída do modelo aos clientes?

• Identifique todas as dependências de terceiros na cadeia de fornecimento de dados de ML/Preparação – não só em software open source, mas também fornecedores de dados

  - Por que os utiliza e de que forma verifica a sua fiabilidade?

• Está a utilizar modelos pré-criados de terceiros ou está a submeter dados de preparação a fornecedores MLaaS de terceiros?

• Novos blocos de inventário sobre ataques a produtos/serviços semelhantes. Compreender que muitas ameaças de IA/ML são transferidas entre tipos de modelos, que impacto teriam estes ataques nos seus próprios produtos?

Ameaças Relacionadas e Mitigações neste Documento

• Reprogramação da Rede Neural

• Exemplos Adversos no domínio físico

• Fornecedores de ML Malicioso Recuperam Dados de Preparação

• Atacar a Cadeia de Fornecimento de ML

• Modelo de Backdoor

• Dependências específicas de ML comprometidas

Exemplo de Ataques

• O fornecedor MLaaS malicioso aplica um trojan ao modelo com uma omissão específica

• O cliente adverso encontra a vulnerabilidade na dependência OSS comum que utiliza, carrega o payload dos dados de preparação criados para comprometer o serviço

• O parceiro sem escrúpulos utiliza as APIs de reconhecimento facial e cria uma camada de apresentação sobre o serviço para produzir Deep Fakes.

Ameaças específicas de IA/ML e Mitigações

#1: Perturbação Adversarial

Description

Em ataques de estilo perturbação, o atacante modifica furtivamente a consulta para obter uma resposta desejada de um modelo implementado na produção[1]. Esta é uma falha na integridade de entrada do modelo que leva a ataques do estilo fuzzing, onde o resultado final não é necessariamente uma violação de acesso ou EOP, mas compromete o desempenho de classificação do modelo. Este ataque pode também manifestar-se por “trolls” que utilizam certas palavras-alvo de forma a que a IA as proíba, ao negar efetivamente o serviço a utilizadores legítimos com um nome que corresponda a uma palavra “proibida”.

[24]

Variante #1a: Classificação incorreta direcionada

Neste caso, os atacantes geram uma amostra que não está na classe de entrada do classificador-alvo, mas que é classificada pelo modelo como essa classe de entrada particular. A amostra adversa pode parecer tratar-se de dados irrelevantes aleatórios aos olhos humanos, mas os atacantes têm algum conhecimento sobre o sistema de aprendizagem automática-alvo, de modo a gerarem dados irrelevantes que não são aleatórios e que exploram alguns aspetos específicos do modelo-alvo. O adversário apresenta uma amostra de entrada que não é uma amostra legítima, mas o sistema-alvo classifica-a como uma classe legítima.

Exemplos

[6]

Mitigações

• Reforçando a Robustez Adversarial usando a Confiança do Modelo Induzida pelo Treinamento Adversarial [19]: Os autores propõem o Highly Confident Near Neighbor (HCNN), uma estrutura que combina informações de confiança e busca de vizinhos mais próximos, para reforçar a robustez adversarial de um modelo base. Tal pode ajudar a distinguir as previsões de modelos certos e errados numa vizinha de um ponto de amostragem da distribuição de preparação subjacente.

• Análise Causal Orientada por Atribuição [20]: Os autores estudam a conexão entre a resiliência a perturbações adversárias e a explicação baseada em atribuição de decisões individuais geradas por modelos de aprendizado de máquina. Indicam que as entradas adversas não são robustas no espaço de atribuição, ou seja, mascarar algumas funcionalidades com elevada atribuição leva à mudança da indecisão do modelo de machine learning nos exemplos adversos. Em contraste, as entradas naturais são robustas no espaço de atribuição.

  [20]

Estas abordagens podem tornar os modelos de machine learning mais resistentes aos ataques adversos, porque enganar este sistema de cognição de duas camadas requer não só atacar o modelo original, mas também garantir que a atribuição gerada para o exemplo adverso é semelhante aos exemplos originais. Ambos os sistemas devem ser simultaneamente comprometidos para um ataque adverso bem sucedido.

Paralelos Tradicionais

Elevação de Privilégio Remota, uma vez que o atacante está agora no controlo do modelo

Gravidade

Crítico

Variante #1b: Classificação incorreta de origem/destino

Esta variante é caracterizada como uma tentativa por parte de um atacante de obter um modelo para devolver a etiqueta desejada para uma dada entrada. Geralmente, força um modelo a devolver um falso positivo ou falso negativo. O resultado final é uma subtil obtenção de controlo sobre a precisão da classificação do modelo, através da qual um atacante consegue induzir omissões específicas à vontade.

Embora este ataque tenha um impacto prejudicial significativo na precisão da classificação, a sua execução também exigir mais tempo, dado que um adversário não só deve manipular os dados de origem de modo a que não sejam etiquetados corretamente, mas também etiquetados especificamente com o rótulo fraudulento desejado. Estes ataques envolvem frequentemente vários passos/tentativas para forçar uma má classificação [3]. Se o modelo for suscetível de transferir ataques de aprendizagem que forçam uma má classificação direcionada, poderá não existir uma pegada percetível do tráfego dos atacantes, dado que os ataques de sondagem podem ser realizados offline.

Exemplos

Forçar e-mails benignos a ser classificados como spam ou fazer com que um exemplo malicioso não seja detetado. Estes também são conhecidos como ataques de evasão ou mimetismo de modelos.

Mitigações

Ações de Deteção Reativa/Defensiva

• Implementar um limite de tempo mínimo entre as chamadas à API que apresenta os resultados de classificação. Este limite de tempo atrasa os testes de ataque em vários passos, ao aumentar o tempo total necessário para encontrar uma perturbação de sucesso.

Ações Proativas/Protetivas

• Feature Denoising for Improving Adversarial Robustness [22]: Os autores desenvolvem uma nova arquitetura de rede que aumenta a robustez adversarial através da realização de denoising. Especificamente, as redes contêm blocos que reduzem o ruído das funcionalidades através de meios não locais ou outros filtros; todas as redes são preparadas de ponto a ponto. Quando combinada com a preparação adversa, as redes com redução de ruído das funcionalidades melhoram substancialmente a tecnologia de resistência à adversidade nas definições de ataques whitebox e blackbox.

• Treinamento e Regularização Adversarial: Treine com amostras adversárias conhecidas para construir resiliência e robustez contra entradas maliciosas. Tal também pode ser visto como uma forma de regularização, o que penaliza a norma dos gradientes de entrada e torna a função de previsão do classificador mais suave (ao aumentar a margem de entrada). Inclui classificações corretas com classificações de confiança mais baixas.

Invista no desenvolvimento da classificação monotónica com a seleção de funcionalidades monotónicas. Garantirá assim que o adversário não será capaz de evitar o classificador ao preencher simplesmente funcionalidades da classe negativa [13].

• A compactação de funcionalidades [18] pode ser utilizada para aumentar a resistência dos modelos DNN através da deteção de exemplos adversos, o que reduz o espaço de pesquisa disponível a um adversário, ao agregar as amostras que correspondem a muitos vetores de funcionalidades diferentes no espaço original numa única amostra. Ao comparar a predição de um modelo DNN na entrada original com a da entrada compactada, a compactação de funcionalidades pode ajudar a detetar exemplos adversos. Se os exemplos originais e comprimidos produzirem saídas substancialmente diferentes das do modelo, será provável que essa entrada seja adversa. Ao medir a divergência entre as predições e ao selecionar um valor limite, o sistema pode emitir a predição correta para exemplos legítimos e rejeitar as entradas adversas.

  

  [18]

• Defesas certificadas contra exemplos adversários [22]: Os autores propõem um método baseado em um relaxamento semi-definido que produz um certificado de que, para uma determinada rede e entrada de teste, nenhum ataque pode forçar o erro a exceder um determinado valor. Em segundo lugar, dado que este certificado é diferencial, os autores otimizam-no conjuntamente com os parâmetros de rede, ao proporcionar um regularizador adaptativo que incentiva a resistência contra todos os ataques.

Ações de Resposta

• Emitir alertas sobre resultados de classificação com elevada variação entre classificadores, especialmente se a partir de um único utilizador ou de um grupo pequeno de utilizadores.

Paralelos Tradicionais

Elevação de Privilégio Remota

Gravidade

Crítico

Variante #1c: Classificação incorreta aleatória

Esta é uma variação especial onde a classificação de destino do atacante pode ser qualquer coisa que não a classificação de origem legítima. O ataque envolve geralmente a injeção aleatória de dados irrelevantes nos dados de origem que estão a ser classificados para reduzir a probabilidade de uma classificação correta ser utilizada no futuro [3].

Exemplos

Mitigações

Idêntico à Variante 1a.

Paralelos Tradicionais

Denial of service não persistente

Gravidade

Importante

Variante #1d: Redução da Confiança

Um atacante pode criar entradas para reduzir o nível de confiança da classificação correta, especialmente em cenários com consequências elevadas. Tal também pode assumir a forma de um grande número de falsos positivos destinados a sobrecarregar os administradores ou os sistemas de monitorização com alertas fraudulentos indistinguíveis de alertas legítimos [3].

Exemplos

Mitigações

• Além das ações abordadas na Variante #1a, a limitação de eventos pode ser empregada para reduzir o volume de alertas de uma única fonte.

Paralelos Tradicionais

Denial of service não persistente

Gravidade

Importante

#2a envenenamento de dados direcionado

Description

O objetivo final do atacante é contaminar o modelo de máquina gerado na fase de preparação, de modo a que as previsões sobre novos dados sejam modificadas na fase de teste[1]. Nos ataques de envenenamento direcionados, o atacante quer classificar erradamente exemplos específicos para fazer com que ações específicas sejam tomadas ou omitidas.

Exemplos

Submeter software AV como malware para forçar a sua classificação errada como malicioso e eliminar a utilização de software AV direcionado em sistemas cliente.

Mitigações

• Definir sensores de anomalia para observarem a distribuição de dados diariamente e alertar sobre variações

  - Medir a variação de dados de preparação diariamente, telemetria para distorção/desfasamento

• Validação de entradas, tanto de limpeza como de verificação de integridade

• O envenenamento injeta amostras de preparação periféricas. Duas estratégias principais para combater esta ameaça:

  - Limpeza/validação de dados: remova as amostras de envenenamento dos dados de preparação - Preparação para combater ataques de envenenamento [14]

  - Defesa Roni (Reject-on-Negative-Impact) [15]

  - Aprendizagem robusta: Escolha algoritmos de aprendizagem que sejam robustos na presença de amostras de envenenamento.

  -Uma dessas abordagens é descrita em [21], onde os autores abordam o problema do envenenamento de dados em duas etapas: 1) introduzindo um novo método robusto de fatoração matricial para recuperar o subespaço verdadeiro, e 2) nova regressão robusta de componentes de princípio para podar instâncias adversárias com base na base recuperada na etapa (1). Estes caracterizam as condições necessárias e suficientes para recuperar com sucesso o verdadeiro subespaço e apresentam um limite sobre a perda de previsão esperada em comparação com a situação real.

Paralelos Tradicionais

Anfitrião com trojan onde o atacante persiste na rede. Os dados de configuração ou preparação são comprometidos e estão a ser ingeridos/considerados fidedignos para a criação de modelos.

Gravidade

Crítico

#2b Envenenamento indiscriminado de dados

Description

O objetivo é arruinar a qualidade/integridade do conjunto de dados que está a ser atacado. Muitos conjuntos de dados são públicos/não fidedignos/não organizados, o que cria, em primeiro lugar, preocupações adicionais em torno da capacidade para detetar essas violações de integridade dos dados. A preparação com dados inconscientemente comprometidos é uma situação de “se entra lixo/sai lixo”. Quando detetada, a triagem deve determinar a extensão dos dados que foram violados e colocar em quarentena/preparar novamente.

Exemplos

Uma empresa extrai um site bem conhecido e fiável para dados futuros de petróleo para preparar os modelos. O site do fornecedor de dados é posteriormente comprometido através do Ataque de injeção de SQL. O atacante pode envenenar o conjunto de dados sem entraves e o modelo que está a ser preparado não tem noção de que os dados estão contaminados.

Mitigações

Idêntico à variante 2a.

Paralelos Tradicionais

Denial of service autenticado contra um recurso de valor elevado

Gravidade

Importante

#3 Ataques de Inversão de Modelo

Description

Os recursos privados usados em modelos de aprendizado de máquina podem ser recuperados [1]. incluindo a recriação de dados de preparação privados aos quais o atacante não tem acesso. Também conhecidos como ataques de “hill climbing” pela comunidade biométrica [16, 17]. Tal é possível ao localizar a entrada que maximiza o nível de confiança devolvido, sujeito à classificação correspondente ao destino [4].

Exemplos

[4]

Mitigações

• As interfaces para modelos preparados a partir de dados confidenciais precisam de um forte controlo de acesso.

• Consultas com limitação de taxas permitidas por modelo

• Implemente portas entre os utilizadores/chamadores e o modelo real, através da validação de entradas em todas as consultas propostas, ao rejeitar tudo o que não cumpre a definição de entrada correta do modelo e ao devolver apenas a quantidade mínima de informações necessária para ser útil.

Paralelos Tradicionais

Divulgação de Informações confidenciais direcionadas

Gravidade

A predefinição é importante, de acordo com barra de erros CVDCS padrão, mas a extração de dados confidenciais ou pessoalmente identificáveis elevam este valor para crítico.

#4 Ataque de inferência de associação

Description

O atacante pode determinar se um dado registo de dados fazia parte do conjunto de dados de preparação do modelo ou não[1]. 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) [1].

[12]

Mitigações

Os trabalhos de investigação que demonstram a viabilidade deste ataque indicaram que a Privacidade Diferencial [4, 9] seria uma mitigação eficaz. Este ainda é um campo em crescimento na Microsoft e a Engenharia de Segurança do Comité AETHER recomenda o desenvolvimento de conhecimentos especializados com investimento a nível de investigação nesta área. Esta investigação deveria enumerar as capacidades de Privacidade Diferencial e avaliar a eficácia prática das mesmas como mitigações e, posteriormente, conceber maneiras de estas defesas serem herdadas de forma transparente nas nossas plataformas de serviços online, à semelhança da forma como a compilação de código no Visual Studio lhe dá proteções de segurança predefinidas que são transparentes para o programador e para os utilizadores.

A utilização do abandono de neurónios e do empilhamento de modelos pode ser, dentro de certa medida, uma mitigação eficaz. A utilização do abandono de neurónios não só aumenta a resiliência da rede neural a este ataque, como também aumenta o desempenho do modelo [4].

Paralelos Tradicionais

Privacidade dos Dados. Estão a ser feitas inferências sobre a inclusão de pontos de dados no conjunto de preparação, mas os dados de preparação em si não estão a ser divulgados

Gravidade

Este é um problema de privacidade, não um problema de segurança. É abordado na orientação de modelação de ameaças dado que os domínios se sobrepõem, mas qualquer resposta aqui seria impulsionada pela Privacidade, não pela Segurança.

#5 Roubo de modelos

Description

Os atacantes recriam o modelo subjacente ao consultar o modelo de forma legítima. A funcionalidade do novo modelo é a mesma do modelo subjacente[1]. Uma vez recriado o modelo, pode ser invertido para recuperar informações de funcionalidades ou fazer inferências sobre os dados de preparação.

• Resolução de equações – num modelo que devolve probabilidades de classe através da saída da API, um atacante pode criar consultas para determinar variáveis desconhecidas num modelo.

• Localização de Caminhos – um ataque que explora as particularidades da API para extrair as “decisões” tomadas por uma árvore ao classificar uma entrada [7].

• Ataque de transferência – um adversário pode preparar um modelo local (possivelmente através da emissão de consultas de predição para o modelo pretendido) e utilizá-lo para criar exemplos adversos que são transferidos para o modelo de destino [8]. Se o modelo for extraído e detetado como sendo vulnerável a um tipo de entrada adversa, podem ser desenvolvidos novos ataques totalmente offline contra o modelo implementado na produção pelo atacante que extraiu uma cópia do modelo.

Exemplos

Com definições em que um modelo de ML serve para detetar comportamentos adversos, tais como identificação de spam, classificação de malware e deteção de anomalias de rede, a extração de modelos pode facilitar os ataques de evasão [7].

Mitigações

Ações Proativas/Protetivas

• Minimize ou oculte os detalhes devolvidos nas APIs de previsão, enquanto mantém a utilidade para as aplicações “honestas” [7].

• Defina uma consulta bem formada para as entradas do modelo e devolva apenas os resultados em resposta a entradas completas e bem formadas que correspondam a esse formato.

• Devolva valores fiáveis e bem formados. A maioria dos chamadores legítimos não precisa de várias casas decimais de precisão.

Paralelos Tradicionais

Adulteração só de leitura e não autenticada de dados do sistema, direcionada à divulgação de informações de alto valor?

Gravidade

Importante em modelos sensíveis à segurança; caso contrário, moderada

#6 Reprogramação de Redes Neurais

Description

Através de uma consulta especialmente criada por um atacante, os sistemas de Machine learning podem ser reprogramados para uma tarefa que se desvia da intenção original do criador [1].

Exemplos

Controlos de acesso fracos numa API de reconhecimento facial permitem que terceiros se incorporem em aplicações destinadas a prejudicar os clientes da Microsoft, tal como um gerador de falsificações profundas.

Mitigações

• Forte autenticação mútua cliente-servidor<> e controle de acesso a interfaces de modelo

• Remoção das contas ofensivas.

• Identifique e aplique um contrato de nível de serviço para as APIs. Determine o tempo aceitável para corrigir um problema quando este é comunicado e garanta que o problema não se repete quando o SLA expira.

Paralelos Tradicionais

Este é um cenário de abuso. É menos provável que abra um incidente de segurança sobre esta situação do que simplesmente desativar a conta do agressor.

Gravidade

Importante a Crítica

#7 Exemplo Adversarial no domínio Físico (bits-átomos>)

Description

Um exemplo contraditório é uma entrada/consulta de uma entidade maliciosa enviada com o único objetivo de enganar o sistema de aprendizado de máquina [1]

Exemplos

Estes exemplos podem manifestar-se no domínio físico, como um veículo autónomo que é manipulado para passar um sinal de STOP por causa de uma dada cor de luz (a entrada adversa) que é refletida no sinal de STOP, o que força o sistema de reconhecimento de imagens a deixar de ver o sinal de STOP como um sinal de paragem.

Paralelos Tradicionais

Elevação de Privilégio, execução remota de código

Mitigações

Estes ataques manifestam-se porque os problemas na camada de aprendizagem automática (a camada de dados e algoritmos abaixo da tomada de decisões orientada pela IA) não foram mitigados. Tal como acontece com qualquer outro software *ou* sistema físico, a camada abaixo do alvo pode sempre ser atacada através de vetores tradicionais. Por este motivo, as práticas de segurança tradicionais são mais importantes que nunca, especialmente com a camada de vulnerabilidades não mitigadas (a camada de dados/algoritmos) que está a ser utilizada entre a IA e o software tradicional.

Gravidade

Crítico

#8 Provedores de ML mal-intencionados que podem recuperar dados de treinamento

Description

Um fornecedor malicioso apresenta um algoritmo de backdoor, no qual os dados de preparação privados são recuperados. Conseguiram reconstruir faces e textos, considerando apenas o modelo.

Paralelos Tradicionais

Divulgação de informações direcionadas

Mitigações

Os trabalhos de investigação que demonstram a viabilidade deste ataque indicam que a Encriptação Homomórfica seria uma mitigação eficaz. Este é uma área que atualmente não tem muito investimento na Microsoft e a Engenharia de Segurança do Comité AETHER recomenda o desenvolvimento de conhecimentos especializados com investimento a nível de investigação nesta área. Esta investigação deveria enumerar os princípios de Encriptação Homomórfica e avaliar a sua eficácia prática, como mitigações face a fornecedores de ML como Serviço maliciosos.

Gravidade

Importante se os dados forem PII; caso contrário, Moderada

#9 Atacando a cadeia de suprimentos de ML

Description

Devido aos grandes recursos (dados + computação) necessários para treinar algoritmos, a prática atual é reutilizar modelos treinados por grandes corporações e modificá-los ligeiramente para a tarefa em questão (por exemplo: ResNet é um modelo de reconhecimento de imagem popular da Microsoft). Estes modelos são organizados num Model Zoo (o Caffe aloja modelos de reconhecimento de imagens populares). Neste ataque, o adversário ataca os modelos alojados no Caffe, envenenando assim o conjunto para qualquer outra pessoa. [1]

Paralelos Tradicionais

• Compromisso da dependência não relacionada com segurança de terceiros

• App store que aloja malware inadvertidamente

Mitigações

• Minimize as dependências de terceiros dos modelos e dos dados sempre que possível.

• Incorpore estas dependências no seu processo de modelação de ameaças.

• Tire partido da autenticação forte, controlo de acesso e da encriptação entre sistemas proprietários e de terceiros.

Gravidade

Crítico

#10 Aprendizagem Automática Backdoor

Description

O processo de preparação é confiado a um terceiro malicioso que adultera os dados de preparação e proporciona um modelo com trojan que força más classificações direcionadas, como classificar determinado vírus como não malicioso[1]. Este é um risco em cenários de geração de modelos de ML como Serviço.

[12]

Paralelos Tradicionais

• Compromisso de dependência de segurança de terceiros

• Mecanismo de Atualização de Software comprometido

• Autoridade Certificada comprometida

Mitigações

Ações de Deteção Reativa/Defensiva

• Os danos já aconteceram quando esta ameaça é descoberta, pelo que o modelo e quaisquer dados de preparação proporcionados pelo fornecedor malicioso não podem ser considerados fiáveis.

Ações Proativas/Protetivas

• Prepare todos os modelos confidenciais locais

• Catalogue os dados de preparação ou garanta que vêm de um terceiro de confiança com práticas de segurança fortes

• Crie um modelo de ameaça que demonstre a interação entre o fornecedor de MLaaS e os seus próprios sistemas

Ações de Resposta

• Idêntico ao da dependência externa comprometida

Gravidade

Crítico

#11 Explorar dependências de software do sistema de ML

Description

Neste ataque, o atacante NÃO manipula os algoritmos. Em vez disso, explora vulnerabilidades de software, como memória intermédia com capacidade excedida ou scripting entre sites[1]. É ainda mais fácil comprometer camadas de software abaixo da IA/ML do que atacar diretamente a camada de aprendizagem, pelo que as práticas tradicionais de mitigação de ameaças à segurança detalhadas no ciclo de vida do desenvolvimento da segurança são essenciais.

Paralelos Tradicionais

• Dependência de Software Open Source Comprometida

• Vulnerabilidade do servidor Web (Falha de validação de entrada da API, CSRF, XSS)

Mitigações

Trabalhe com a sua equipa de segurança para seguir as melhores práticas aplicáveis de Garantia de Segurança Operacional/Ciclo de Vida de Desenvolvimento Centrado na Segurança.

Gravidade

Variável; Até Crítica, dependendo do tipo de vulnerabilidade de software tradicional.

Bibliografia

[1] Modos de falha no aprendizado de máquina, Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen e Jeffrey Snover, https://learn.microsoft.com/security/failure-modes-in-machine-learning

[2] AETHER Security Engineering Workstream, Data Provenance/Lineage v-team

[3] Exemplos Adversarial em Deep Learning: Caracterização e Divergência, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf

[4] ML-Leaks: Model and Data Independent Membership Inference Attacks and Defenses on Machine Learning Models, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf

[5] M. Fredrikson, S. Jha, and T. Ristenpart, “Model Inversion Attacks that Exploit Confidence Information and Basic Countermeasures,” in Proceedings of the 2015 ACM SIGSAC Conference on Computer and Communications Security (CCS).

[6] Nicolas Papernot & Patrick McDaniel- Adversarial Examples in Machine Learning AIWTB 2017

[7] Stealing Machine Learning Models via Prediction APIs, Florian Tramèr, École Polytechnique Fédérale de Lausanne (EPFL); Fan Zhang, Cornell University; Ari Juels, Cornell Tech; Michael K. Reiter, The University of North Carolina at Chapel Hill; Thomas Ristenpart, Cornell Tech

[8] The Space of Transferable Adversarial Examples, Florian Tramèr , Nicolas Papernot , Ian Goodfellow , Dan Boneh , and Patrick McDaniel

[9] Understanding Membership Inferences on Well-Generalized Learning Models Yunhui Long1 , Vincent Bindschaedler1 , Lei Wang2 , Diyue Bu2 , Xiaofeng Wang2 , Haixu Tang2 , Carl A. Gunter1 , and Kai Chen3,4

[10] Simon-Gabriel et al., Adversarial vulnerability of neural networks increases with input dimension, ArXiv 2018;

[11] Lyu et al., A unified gradient regularization family for adversarial examples, ICDM 2015

[12] Wild Patterns: dez Anos Após a Ascensão do Aprendizado de Máquina Adversário - NeCS 2019 Battista Biggioa, Fabio Roli

[13] Adversarially Robust Malware Detection UsingMonotonic Classification Inigo Incer et al.

[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto, and Fabio Roli. Bagging Classifiers for Fighting Poisoning Attacks in Adversarial Classification Tasks

[15] Uma rejeição melhorada na defesa de impacto negativo Hongjiang Li e Patrick P.K. Chan

[16] Adler. Vulnerabilities in biometric encryption systems. 5th Int’l Conf. AVBPA, 2005

[17] Galbally, McCool, Fierrez, Marcel, Ortega-Garcia. On the vulnerability of face verification systems to hill-climbing attacks. Patt. Rec., 2010

[18] Weilin Xu, David Evans, Yanjun Qi. Feature Squeezing: Detetando exemplos adversários em redes neurais profundas. 2018 Network and Distributed System Security Symposium. 18-21 February.

[19] Reinforcing Adversarial Robustness using Model Confidence Induced by Adversarial Training - Xi Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen, Somesh Jha

[20] Attribution-driven Causal Analysis for Detection of Adversarial Examples, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami

[21] Robust Linear Regression Against Training Data Poisoning – Chang Liu et al.

[22] Feature Denoising for Improving Adversarial Robustness, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He

[23] Certified Defenses against Adversarial Examples - Aditi Raghunathan, Jacob Steinhardt, Percy Liang