Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Por Andrew Marshall, Jugal Parikh, Emre Kiciman e Ram Shankar Siva Kumar
Agradecimentos especiais a Raul Rojas e ao Workstream de Engenharia de Segurança da AETHER
Novembro de 2019
Este documento é uma entrega das Práticas de Engenharia AETHER para o Grupo de Trabalho de IA e complementa as práticas de modelagem de ameaças SDL existentes, fornecendo novas diretrizes sobre enumeração de ameaças e mitigação específicas para o espaço de IA e Machine Learning. Este documento deve ser usado como referência durante as revisões de design de segurança dos seguintes itens:
Produtos/serviços que interagem ou dependem de serviços baseados em IA/ML
Produtos/serviços que estão sendo criados com IA/ML em seu núcleo
A mitigação tradicional de ameaças à segurança é mais importante do que nunca. Os requisitos estabelecidos pelo ciclo de vida de desenvolvimento de segurança são essenciais para estabelecer uma base de segurança do produto em que essas diretrizes se baseiam. A falha ao lidar com ameaças de segurança tradicionais ajuda a habilitar os ataques específicos de IA/ML abordados neste documento nos domínios físicos e de software, além de tornar o comprometimento trivial na pilha de software. Para obter uma introdução às novas ameaças à segurança neste espaço, confira Como proteger o futuro da IA e do ML na Microsoft.
Os conjuntos de habilidades de engenheiros de segurança e cientistas de dados normalmente não se sobrepõem. Essa orientação fornece uma maneira de ambas as disciplinas terem conversas estruturadas sobre essas novas ameaças/mitigações sem exigir que os engenheiros de segurança se tornem cientistas de dados ou vice-versa.
Este documento é dividido em duas seções:
- "Principais novas considerações na modelagem de ameaças" se concentra em novas maneiras de pensar e novas perguntas a serem feitas ao modelar sistemas de IA/ML de ameaças. Tanto os cientistas de dados quanto os engenheiros de segurança devem revisar isso, pois ele será seu guia estratégico para discussões de modelagem de ameaças e priorização de mitigação.
- "Ameaças específicas de IA/ML e suas Mitigações" fornece detalhes sobre ataques específicos, bem como etapas de mitigação específicas em uso hoje para proteger produtos e serviços da Microsoft contra essas ameaças. Esta seção é direcionada principalmente a cientistas de dados que talvez precisem implementar mitigações de ameaças específicas como uma saída do processo de modelagem de ameaças/revisão de segurança.
Esta orientação é organizada em torno de uma Taxonomia de Ameaças de Machine Learning adversária criada por Ram Shankar Siva Kumar, David O'Brien, Kendra Albert, Salome Viljoen e Jeffrey Snover intitulada "Modos de Falha no Machine Learning". Para obter diretrizes de gerenciamento de incidentes sobre como triar ameaças de segurança detalhadas neste documento, consulte a Barra de Bugs do SDL para ameaças de IA/ML. Todos eles são documentos vivos que evoluirão ao longo do tempo com o cenário de ameaças.
Principais novas considerações sobre modelagem de ameaças: alterando a maneira como você vê limites de confiança
Suponha comprometimento/envenenamento dos dados usados para o seu treinamento, bem como do provedor de dados. Saiba como detectar entradas de dados anômalas e mal-intencionadas, além de poder distinguir entre elas e se recuperar delas
Resumo
Armazenamentos de dados de treinamento e os sistemas que os hospedam fazem parte do escopo de Modelagem de Ameaças. A maior ameaça à segurança no aprendizado de máquina hoje é a intoxicação de dados devido à falta de detecções e mitigações padrão nesse espaço, combinada com a dependência de conjuntos de dados públicos não confiáveis/não hospedados como fontes de dados de treinamento. O acompanhamento da procedência e da linhagem de seus dados é essencial para garantir sua confiabilidade e evitar um ciclo de treinamento "lixo dentro, lixo fora".
Perguntas a serem feitas em uma revisão de segurança
Se seus dados forem envenenados ou adulterados, como você saberia?
-Qual telemetria você tem para detectar uma distorção na qualidade dos seus dados de treinamento?
Você está treinando com base em entradas fornecidas pelo usuário?
-Que tipo de validação/sanitização de entrada você está fazendo nesse conteúdo?
-A estrutura desses dados está documentada de forma semelhante a Folhas de Dados para Conjuntos de Dados?
Se você treinar em armazenamentos de dados online, quais etapas você tomará para garantir a segurança da conexão entre o modelo e os dados?
- Eles têm uma maneira de informar comprometimentos aos consumidores de seus feeds?
- Eles são capazes disso?
Quão sensíveis são os dados que você usa para treinar?
-Você o cataloga ou controla a adição/atualização/exclusão de entradas de dados?
O modelo pode gerar dados confidenciais?
- Esses dados foram obtidos com permissão da origem?
O modelo só gera resultados necessários para atingir sua meta?
Seu modelo retorna pontuações de confiança brutas ou qualquer outra saída direta que possa ser registrada e duplicada?
Qual é o impacto de seus dados de treinamento sendo recuperados atacando/invertendo seu modelo?
Se os níveis de confiança da saída do modelo de repente caírem, você pode descobrir como/por que isso aconteceu, assim como os dados que causaram isso?
Você definiu uma entrada bem formada para seu modelo? O que você está fazendo para garantir que as entradas atendam a esse formato e o que você faz se não o fizerem?
Se as saídas estiverem erradas, mas não estiverem causando a notificação de erros, como você saberia?
Você sabe se seus algoritmos de treinamento são resilientes a entradas adversárias em um nível matemático?
Como você se recupera da contaminação adversária de seus dados de treinamento?
-Você pode isolar/colocar conteúdo adversário em quarentena e treinar novamente modelos afetados?
- Você pode reverter/recuperar um modelo de uma versão anterior para re-treinamento?
Você está usando aprendizado de reforço em conteúdo público não curado?
Comece a pensar sobre a linhagem de seus dados– você encontraria um problema, poderia rastreá-lo até sua introdução ao conjunto de dados? Se não, isso é um problema?
Saiba de onde vêm seus dados de treinamento e identifique as normas estatísticas para começar a entender como são as anomalias
-Quais elementos dos seus dados de treinamento são vulneráveis à influência externa?
-Quem pode contribuir para os conjuntos de dados a partir dos quais você está sendo treinado?
-Como você atacaria suas fontes de dados de treinamento para prejudicar um concorrente?
Ameaças e mitigações relacionadas neste documento
Perturbação Adversária (todas as variantes)
Envenenamento por dados (todas as variantes)
Ataques de exemplo
Forçar emails benignos a serem classificados como spam ou fazer com que um exemplo mal-intencionado não seja detectado
Entradas criadas pelo invasor que reduzem o nível de confiança da classificação correta, especialmente em cenários de alta consequência
O invasor injeta ruído aleatoriamente nos dados de origem que estão sendo classificados para reduzir a probabilidade de a classificação correta ser usada no futuro, efetivamente prejudicando o modelo.
Contaminação de dados de treinamento para forçar a classificação incorreta de pontos de dados selecionados, resultando em ações específicas sendo tomadas ou omitidas por um sistema
Identificar ações que seus modelos ou produto/serviço podem tomar, o que pode causar danos ao cliente online ou no domínio físico
Resumo
Não mitigados, os ataques a sistemas de IA/ML podem se manifestar no mundo físico. Qualquer cenário que possa ser distorcido para prejudicar psicologicamente ou fisicamente os usuários é um risco catastrófico para seu produto/serviço. Isso se estende a quaisquer dados confidenciais sobre seus clientes usados para escolhas de treinamento e design que possam resultar em vazamento desses dados privados.
Perguntas a serem feitas em uma revisão de segurança
Você treina com exemplos adversários? Qual é o impacto que eles têm na saída do modelo no domínio físico?
Como o trolling se manifesta em relação ao seu produto/serviço? Como você pode detectar e responder a ele?
O que seria necessário para que seu modelo retornasse um resultado que engana seu serviço para negar acesso aos usuários legítimos?
Qual é o impacto do seu modelo sendo copiado/roubado?
Seu modelo pode ser usado para inferir a associação de uma pessoa individual em um determinado grupo ou simplesmente nos dados de treinamento?
Um invasor pode causar danos à reputação ou uma reação negativa nas relações públicas ao seu produto forçando-o a realizar ações específicas?
Como você lida com dados formatados corretamente, mas excessivamente tendenciosos, como de trolls?
Para cada maneira de interagir ou consultar seu modelo que é exposta, esse método pode ser interrogado para revelar dados de treinamento ou a funcionalidade do modelo?
Ameaças e mitigações relacionadas neste documento
Inferência de Pertinência
Inversão de modelos
Roubo de modelos
Ataques de exemplo
Reconstrução e extração de dados de treinamento consultando repetidamente o modelo para obter resultados máximos de confiança
Duplicação do próprio modelo por correspondência completa de consulta/resposta
Consultar o modelo de uma maneira que revela um elemento específico de dados privados foi incluído no conjunto de treinamento
Carro autônomo sendo enganado para ignorar placas de parada/semáforos
Bots de conversa manipulados para trollar usuários benignos
Identificar todas as fontes de dependências de IA/ML, bem como camadas de apresentação de front-end em sua cadeia de fornecimento de dados/modelo
Resumo
Muitos ataques em IA e Machine Learning começam com acesso legítimo a APIs que são exibidas para fornecer acesso de consulta a um modelo. Devido às fontes ricas de dados e ricas experiências do usuário envolvidas aqui, o acesso de terceiros autenticado, mas "inapropriado" (há uma área cinza aqui) aos seus modelos é um risco devido à capacidade de atuar como uma camada de apresentação acima de um serviço fornecido pela Microsoft.
Perguntas a serem feitas em uma revisão de segurança
Quais clientes/parceiros são autenticados para acessar seu modelo ou APIs de serviço?
- Eles podem atuar como uma camada de apresentação sobre seu serviço?
- Você pode revogar o acesso deles prontamente em caso de comprometimento?
-Qual é a sua estratégia de recuperação em caso de uso mal-intencionado de seu serviço ou dependências?
Uma terceiraparte pode criar uma fachada em torno de seu modelo para reutilizar e prejudicar a Microsoft ou seus clientes?
Os clientes fornecem dados de treinamento diretamente para você?
-Como você protege esses dados?
-E se for mal-intencionado e o seu serviço for o alvo?
Como parece um falso positivo aqui? Qual é o impacto de um falso negativo?
Você pode monitorar e avaliar a divergência das taxas de True Positive versus False Positive em vários modelos?
Que tipo de telemetria você precisa para provar a confiabilidade da saída do modelo para seus clientes?
Identificar todas as dependências de terceiros em sua cadeia de fornecimento de dados de ML/treinamento – não apenas software de código aberto, mas também provedores de dados.
- Por que você os está usando e como você verifica sua confiabilidade?
Você está usando modelos predefinidos de terceiros ou enviando dados de treinamento para provedores de MLaaS de terceiros?
Notícias de inventário sobre ataques a produtos/serviços semelhantes. Entendendo que muitas ameaças de IA/ML são transferidas entre tipos de modelo, qual impacto esses ataques teriam nos seus próprios produtos?
Ameaças e mitigações relacionadas neste documento
Reprogramação de Rede Neural
Exemplos adversariais no domínio físico
Provedores maliciosos de ML recuperando dados de treinamento
Atacando a cadeia de fornecimento de ML
Modelo comprometido
Dependências específicas de aprendizado de máquina comprometidas
Ataques de exemplo
O provedor de MLaaS malicioso insere um trojan no seu modelo com uma passagem específica
O cliente adversário encontra vulnerabilidade na dependência comum de OSS que você usa, carrega um pacote de dados de treinamento criado para colocar em risco seu serviço
O parceiro inescrupuloso usa APIs de reconhecimento facial e cria uma camada de apresentação sobre seu serviço para produzir Deep Fakes.
Ameaças específicas de IA/ML e suas Mitigações
Nº 1: Perturbação adversária
Descrição
Em ataques de estilo perturbação, o invasor furtivamente modifica a consulta para obter uma resposta desejada de um modelo implantado em produção[1]. Isso é uma violação da integridade de entrada do modelo que leva a ataques no estilo fuzzing em que o resultado final não é necessariamente uma violação de acesso ou EOP, mas compromete o desempenho de classificação do modelo. Isso também pode ser manifestado por trolls usando determinadas palavras de destino de uma maneira que a IA as proibirá, negando efetivamente o serviço a usuários legítimos com um nome que corresponda a uma palavra "proibida".
[24]
Variant #1a: Classificação incorreta direcionada
Nesse caso, os invasores geram um exemplo que não está na classe de entrada do classificador de destino, mas é classificado pelo modelo como aquela classe de entrada específica. O exemplo de adversário pode aparecer como ruído aleatório para os olhos humanos, mas os invasores têm algum conhecimento do sistema de aprendizado de máquina de destino para gerar um ruído branco que não é aleatório, mas está explorando alguns aspectos específicos do modelo de destino. O adversário fornece um exemplo de entrada que não é um exemplo legítimo, mas o sistema de destino o classifica como uma classe legítima.
Exemplos
[6]
Atenuações
Reforçando a robustez adversarial usando a confiança do modelo induzida pelo treinamento adversário [19]: Os autores propõem HCNN (Vizinho Próximo Altamente Confiante), um framework que combina informações de confiança e busca de vizinhos mais próximos, para reforçar a robustez adversarial de um modelo base. Isso pode ajudar a distinguir entre previsões de modelo certas e erradas em um bairro de um ponto amostrado da distribuição de treinamento 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 machine learning. Eles relatam que as entradas adversárias não são robustas no espaço de atribuição, ou seja, mascarar alguns recursos com alta atribuição leva à alteração da indecisão do modelo de machine learning nos exemplos adversários. Por outro lado, as entradas naturais são robustas no espaço de atribuição.
[20]
Essas abordagens podem tornar os modelos de machine learning mais resilientes a ataques adversários porque enganar esse sistema de cognição de duas camadas requer não apenas atacar o modelo original, mas também garantir que a atribuição gerada para o exemplo de adversário seja semelhante aos exemplos originais. Ambos os sistemas devem ser simultaneamente comprometidos para um ataque adversário bem-sucedido.
Paralelos Tradicionais
Elevação remota de privilégios, já que o invasor agora está no controle do seu modelo
Severidade
Crítico
Variant #1b: Erro de classificação de origem/destino
Isso é caracterizado como uma tentativa de um invasor de fazer um modelo retornar o rótulo desejado para uma entrada específica. Isso geralmente força um modelo a retornar um falso positivo ou falso negativo. O resultado final é uma apropriação discreta da precisão de classificação do modelo, na qual um invasor pode induzir falhas específicas deliberadamente.
Embora esse ataque tenha um impacto prejudicial significativo para a precisão da classificação, também pode ser mais demorado realizar, dado que um adversário não deve apenas manipular os dados de origem para que eles não sejam mais rotulados corretamente, mas também rotulados especificamente com o rótulo fraudulento desejado. Esses ataques geralmente envolvem várias etapas/tentativas de forçar a classificação incorreta [3]. Se o modelo for suscetível a ataques de aprendizado por transferência que forçam a classificação incorreta direcionada, pode não haver nenhum vestígio discernível de tráfego de invasor, pois os ataques de investigação podem ser executados offline.
Exemplos
Forçar emails benignos a serem classificados como spam ou fazer com que um exemplo mal-intencionado não seja detectado. Eles também são conhecidos como evasão de modelo ou ataques de mimetismo.
Atenuações
Ações de detecção reativa/defensiva
- Implemente um limite de tempo mínimo entre chamadas à API fornecendo resultados de classificação. Isso retarda o teste de ataque de várias etapas aumentando a quantidade geral de tempo necessária para encontrar uma perturbação de sucesso.
Ações proativas/protetoras
Remoção de ruído de características para melhorar a robustez contra ataques adversariais [22]: os autores desenvolvem uma nova arquitetura de rede que aumenta a robustez contra ataques adversariais, executando a remoção de ruído de características. Especificamente, as redes contêm blocos que denoizam os recursos usando meios não locais ou outros filtros; todas as redes são treinadas de ponta a ponta. Quando combinado com o treinamento adversário, o recurso que denoiza redes melhora substancialmente o estado da arte em robustez adversária nas configurações de ataque de caixa branca e caixa preta.
Treinamento adversarial e regularização: Treine com exemplos adversários conhecidos para fortalecer a resiliência e robustez contra entradas mal-intencionadas. Isso também pode ser visto como uma forma de regularização, que penaliza a norma de gradientes de entrada e torna a função de previsão do classificador mais suave (aumentando a margem de entrada). Isso inclui classificações corretas com taxas de confiança mais baixas.
Invista no desenvolvimento de classificação monotônica com seleção de características monotônicas. Isso garante que o adversário não será capaz de enganar o classificador simplesmente adicionando características da classe negativa [13].
A compressão de características [18] pode ser usada para proteger modelos DNN e detectar exemplos adversários. Ele reduz o espaço de pesquisa disponível para um adversário unindo amostras que correspondem a muitos vetores de recursos diferentes no espaço original em uma única amostra. Comparando a previsão de um modelo de rede neural profunda (DNN) na entrada original com a previsão na entrada comprimida, a compressão de recursos pode ajudar a detectar exemplos adversários. Se os exemplos originais e espremidos produzirem saídas substancialmente diferentes do modelo, a entrada provavelmente será adversária. Medindo a discordância entre previsões e selecionando um valor limite, o sistema pode gerar a previsão correta para exemplos legítimos e rejeitar entradas adversárias.
[18]Defesas certificadas contra exemplos adversários [22]: os autores propõem um método baseado em relaxamento semidefinido que emite um certificado indicando que, para uma rede e uma entrada de teste específicas, nenhum ataque pode forçar o erro a exceder um valor determinado. Em segundo lugar, como esse certificado é diferencial, os autores o otimizam em conjunto com os parâmetros de rede, fornecendo um regularizador adaptável que incentiva a robustez contra todos os ataques.
Ações de resposta
- Emita alertas sobre resultados de classificação com alta variação entre classificadores, especialmente se de um único usuário ou pequeno grupo de usuários.
Paralelos Tradicionais
Elevação remota de privilégios
Severidade
Crítico
Variante #1c: Classificação incorreta aleatória
Essa é uma variação especial em que a classificação de destino do invasor pode ser qualquer uma, exceto a classificação legítima de origem. O ataque geralmente envolve a injeção de ruído aleatoriamente nos dados de origem que estão sendo classificados para reduzir a probabilidade de a classificação correta ser usada no futuro [3].
Exemplos
Atenuações
O mesmo que Variant 1a.
Paralelos Tradicionais
Negação de serviço não persistente
Severidade
Importante
Variant #1d: Redução de Confiança
Um invasor pode criar entradas para reduzir o nível de confiança da classificação correta, especialmente em cenários com alto impacto. Isso também pode assumir a forma de um grande número de falsos positivos destinados a sobrecarregar administradores ou sistemas de monitoramento com alertas fraudulentos indistinguíveis de alertas legítimos [3].
Exemplos
Atenuações
- Além das ações abordadas na Variante #1a, a limitação de eventos pode ser utilizada para reduzir o volume de alertas provenientes de uma única fonte.
Paralelos Tradicionais
Negação de serviço não persistente
Severidade
Importante
#2a envenenamento de dados direcionados
Descrição
O objetivo do invasor é contaminar o modelo de computador gerado na fase de treinamento, para que as previsões sobre novos dados sejam modificadas na fase de teste[1]. Em ataques de envenenamento direcionados, o invasor deseja classificar incorretamente exemplos específicos para fazer com que ações específicas sejam tomadas ou omitidas.
Exemplos
Submeter software AV como se fosse malware para forçar sua classificação incorreta como mal-intencionado e eliminar o uso de software antivírus específico em sistemas de clientes.
Atenuações
Definir sensores de anomalias para examinar a distribuição de dados no dia a dia e alertar sobre variações
-Medir diariamente a variação de dados de treinamento, telemetria para viés/desvio
Validação de entrada, verificação de integridade e sanitização
Envenenamento injeta amostras de treinamento subjacentes. Duas estratégias principais para combater essa ameaça:
-Sanitização/validação de dados: remover amostras de envenenamento dos dados de treinamento -Bagging para combater ataques de envenenamento [14]
-Reject-on-Negative-Impact (RONI) defesa [15]
-Aprendizado robusto: escolha algoritmos de aprendizado robustos na presença de amostras de envenenamento.
-Uma abordagem desse tipo é descrita em [21], onde os autores abordam o problema do envenenamento de dados em duas etapas: 1) introduzindo um novo método de fatoração de matriz robusta para recuperar o subespaço verdadeiro, e 2) uma nova regressão robusta de componente principal para eliminar instâncias adversárias com base na base recuperada na etapa (1). Eles caracterizam condições necessárias e suficientes para recuperar com êxito o subespaço verdadeiro e apresentam um limite na perda de previsão esperada em comparação com a verdade básica.
Paralelos Tradicionais
Host trojanizado que permite ao invasor persistir na rede. Os dados de treinamento ou configuração estão comprometidos e sendo utilizados/confiáveis para a criação do modelo.
Severidade
Crítico
#2b envenenamento indiscriminado de dados
Descrição
A meta é arruinar a qualidade/integridade do conjunto de dados que está sendo atacado. Muitos conjuntos de dados são públicos/não confiáveis/não são organizados, portanto, isso gera preocupações adicionais em relação à capacidade de detectar essas violações de integridade de dados para começar. O treinamento sobre dados comprometidos sem conhecimento é uma situação de lixo entra/lixo sai. Depois de detectada, a triagem precisa determinar a extensão dos dados que foram violados e implementar quarentena e retreinamento.
Exemplos
Uma empresa extrai dados de um site confiável e conhecido sobre futuros de petróleo para treinar seus modelos. O site do provedor de dados é posteriormente comprometido por meio de ataque de injeção de SQL. O invasor pode envenenar o conjunto de dados à vontade e o modelo que está sendo treinado não tem noção de que os dados estão contaminados.
Atenuações
O mesmo que a variante 2a.
Paralelos Tradicionais
Negação de serviço autenticada contra um ativo de alto valor
Severidade
Importante
#3 Ataques de inversão de modelo
Descrição
Os recursos privados usados em modelos de machine learning podem ser recuperados [1]. Isso inclui a reconstrução de dados de treinamento privados aos quais o invasor não tem acesso. Também conhecidos como ataques de escalada na comunidade biométrica [16, 17] Isso é feito encontrando a entrada que maximiza o nível de confiança retornado, desde que a classificação corresponda ao alvo [4].
Exemplos
[4]
Atenuações
Interfaces para modelos treinados com base em dados confidenciais precisam de um forte controle de acesso.
Consultas de limite de taxa permitidas por modelo
Implemente portões entre usuários/chamadores e o modelo real executando a validação de entrada em todas as consultas propostas, rejeitando qualquer coisa que não esteja atendendo à definição do modelo de correção de entrada e retornando apenas a quantidade mínima de informações necessárias para ser útil.
Paralelos Tradicionais
Divulgação de informações direcionadas e secretas
Severidade
Este padrão é considerado importante de acordo com a barra padrão de bugs SDL, mas a extração de dados confidenciais ou de identificação pessoal elevaria isso para crítico.
Ataque de inferência de pertencimento nº 4
Descrição
O invasor pode determinar se um determinado registro de dados fazia parte do conjunto de dados de treinamento do modelo ou não[1]. Os pesquisadores conseguiram 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]
Atenuações
Artigos de pesquisa que demonstram a viabilidade desse ataque indicam que a Privacidade Diferencial [4, 9] seria uma mitigação eficaz. Este ainda é um campo nascente na Microsoft e a Engenharia de Segurança AETHER recomenda a criação de experiência com investimentos em pesquisa nesse espaço. Essa pesquisa precisaria enumerar as capacidades de Privacidade Diferencial e avaliar sua eficácia prática como mitigações, para então criar maneiras de essas defesas serem herdadas de forma transparente em nossas plataformas de serviços online, semelhante a como compilar código no Visual Studio fornece proteções de segurança padrão on-by, as quais são transparentes para o desenvolvedor e os usuários.
O uso de emissões de neurônios e empilhamento de modelos pode ser mitigações eficazes até certo ponto. O uso de dropout de neurônios não só aumenta a resiliência de uma rede neural a esse ataque, mas também melhora o desempenho do modelo [4].
Paralelos Tradicionais
Privacidade de dados. Inferências estão sendo feitas sobre a inclusão de um ponto de dados no conjunto de treinamento, mas os próprios dados de treinamento não estão sendo divulgados
Severidade
Este é um problema de privacidade, não um problema de segurança. Ela é tratada nas diretrizes de modelagem de ameaças porque os domínios se sobrepõem, mas qualquer resposta aqui seria orientada pela Privacidade, não pela Segurança.
Roubo de modelo nº 5
Descrição
Os invasores recriam o modelo subjacente realizando consultas legítimas ao modelo. A funcionalidade do novo modelo é igual à do modelo subjacente[1]. Depois que o modelo é recriado, ele pode ser invertido para recuperar informações de recurso ou fazer inferências em dados de treinamento.
Resolução de equações – Para um modelo que retorna probabilidades de classe por meio da saída da API, um invasor pode criar consultas para determinar variáveis desconhecidas em um modelo.
Localização de caminho – 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 treinar um modelo local, possivelmente emitindo consultas de previsão para o modelo de destino, e usá-lo para criar exemplos adversários que são transferidos para o modelo de destino [8]. Se o modelo for extraído e descoberto vulnerável a um tipo de entrada adversária, novos ataques contra seu modelo implantado em produção poderão ser desenvolvidos totalmente offline pelo invasor que extraiu uma cópia do modelo.
Exemplos
Nas configurações em que um modelo de ML serve para detectar comportamentos adversários, como identificação de spam, classificação de malware e detecção de anomalias de rede, a extração de modelos pode facilitar ataques de evasão [7].
Atenuações
Ações proativas/protetoras
Minimizar ou ofuscar os detalhes retornados nas APIs de previsão, mantendo sua utilidade para aplicativos "honestos" [7].
Defina uma consulta bem formada para as entradas do modelo e retorne apenas os resultados em resposta a entradas completas e bem formadas correspondentes a esse formato.
Retorne valores de confiança arredondados. A maioria dos chamadores legítimos não precisa de várias casas decimais de precisão.
Paralelos Tradicionais
Violação não autenticada com acesso somente leitura a dados do sistema, divulgação direcionada de informações valiosas?
Severidade
Importante em modelos sensíveis à segurança, caso contrário, Moderado
Capítulo 6: Reprogramação de Redes Neurais
Descrição
Por meio de uma consulta especialmente elaborada de um adversário, os sistemas de machine learning podem ser reprogramados para uma tarefa que se desvia da intenção original do criador [1].
Exemplos
Controles de acesso fracos em uma API de reconhecimento facial, permitindo que terceiros sejam incorporados a aplicativos projetados para prejudicar os clientes da Microsoft, como um gerador de deepfakes.
Atenuações
Forte autenticação mútua cliente-servidor< e controle de acesso> às interfaces de modelo
Retirada das contas ofensivas.
Identifique e imponha um contrato de nível de serviço para suas APIs. Determine o tempo de correção aceitável para um problema depois de relatado e verifique se o problema pare de ocorrer após o vencimento do SLA.
Paralelos Tradicionais
Este é um cenário de abuso. É menos provável que você abra um incidente de segurança sobre isso do que simplesmente desabilitar a conta do infrator.
Severidade
De Importante a Crítico
#7 Exemplo de adversário no domínio físico (bits-atoms>)
Descrição
Um exemplo adversarial é uma entrada/consulta de uma entidade mal-intencionada enviada com o único objetivo de enganar o sistema de aprendizado de máquina [1]
Exemplos
Esses exemplos podem se manifestar no domínio físico, como um carro autônomo sendo enganado a atravessar um sinal de parada, devido a uma determinada cor de luz (a entrada adversária) brilhando sobre o sinal, forçando o sistema de reconhecimento de imagem a não mais identificar o sinal de parada como tal.
Paralelos Tradicionais
Elevação do Privilégio, execução de código remoto
Atenuações
Esses ataques se manifestam porque os problemas na camada de aprendizado de máquina (a camada de dados e algoritmos abaixo da tomada de decisão orientada por IA) não foram atenuados. Assim como acontece com qualquer outro sistema físico *ou* de software, a camada abaixo do destino sempre pode ser atacada por meio de vetores tradicionais. Por isso, as práticas de segurança tradicionais são mais importantes do que nunca, especialmente com a camada de vulnerabilidades não confirmadas (a camada de dados/algo) sendo usada entre a IA e o software tradicional.
Severidade
Crítico
#8 Provedores de ML mal-intencionados que podem recuperar dados de treinamento
Descrição
Um provedor mal-intencionado apresenta um algoritmo com backdoor, no qual os dados de treinamento privados são recuperados. Eles foram capazes de reconstruir rostos e textos, usando apenas o modelo.
Paralelos Tradicionais
Divulgação de informações direcionadas
Atenuações
Artigos de pesquisa que demonstram a viabilidade desse ataque indicam que a Criptografia Homomórfica seria uma mitigação eficaz. Essa é uma área com pouco investimento atual na Microsoft e a Engenharia de Segurança AETHER recomenda a criação de experiência com investimentos em pesquisa nesse espaço. Esta pesquisa precisaria enumerar os princípios de Criptografia Homomórfica e avaliar sua eficácia prática como mitigações diante de provedores mal-intencionados de ML como serviço.
Severidade
Importante se os dados forem Informações Pessoais Identificáveis (PII), moderado caso contrário
Nº 9 Atacando a cadeia de suprimentos de ML
Descrição
Devido aos recursos grandes (dados + computação) necessários para treinar algoritmos, a prática atual é reutilizar modelos treinados por grandes corporações e modificá-los ligeiramente para tarefa em questão (por exemplo: ResNet é um modelo de reconhecimento de imagem popular da Microsoft). Esses modelos são coletados em um Zoológico de Modelos (o Caffe hospeda modelos populares de reconhecimento de imagem). Neste ataque, o adversário ataca os modelos hospedados em Caffe, envenenando assim o poço para qualquer outra pessoa. [1]
Paralelos Tradicionais
Comprometimento de dependência de terceiros não relacionada à segurança
Loja de aplicativos inadvertidamente hospedando malware
Atenuações
Minimize as dependências de terceiros para modelos e dados sempre que possível.
Incorpore essas dependências ao processo de modelagem de ameaças.
Utilize autenticação forte, controle de acesso e criptografia entre sistemas de primeiros/terceiros.
Severidade
Crítico
#10 Backdoor Machine Learning
Descrição
O processo de treinamento é terceirizado para terceiros mal-intencionados que adulteram dados de treinamento e entregam um modelo de tróia que força classificações incorretas direcionadas, como classificar um determinado vírus como não mal-intencionado[1]. Esse é um risco em cenários de geração de modelo de ML como serviço.
[12]
Paralelos Tradicionais
Comprometimento da dependência de segurança de terceiros
Mecanismo de Atualização de Software Comprometido
Comprometimento da Autoridade de Certificação
Atenuações
Ações de detecção reativa/defensiva
- O dano já é feito depois que essa ameaça é descoberta, portanto, o modelo e todos os dados de treinamento fornecidos pelo provedor mal-intencionado não são confiáveis.
Ações proativas/protetoras
Treinar todos os modelos confidenciais internamente
Catalogar dados de treinamento ou garantir que eles venham de terceiros confiáveis com práticas de segurança fortes
Modelo de ameaça a interação entre o provedor MLaaS e seus próprios sistemas
Ações de resposta
- O mesmo que para o comprometimento da dependência externa
Severidade
Crítico
#11 Aproveitar as dependências de software do sistema de aprendizado de máquina
Descrição
Nesse ataque, o invasor NÃO manipula os algoritmos. Em vez disso, explora vulnerabilidades de software, como estouros de buffer ou scripts entre sites[1]. Ainda é mais fácil comprometer camadas de software abaixo da IA/ML do que atacar diretamente a camada de aprendizado, portanto, as práticas tradicionais de mitigação de ameaças à segurança detalhadas no ciclo de vida de desenvolvimento de segurança são essenciais.
Paralelos Tradicionais
Dependência comprometida de software de código aberto
Vulnerabilidade do servidor Web (XSS, CSRF, falha na validação de entrada da API)
Atenuações
Trabalhe com sua equipe de segurança para seguir as práticas recomendadas aplicáveis de Ciclo de Vida de Desenvolvimento de Segurança/Garantia de Segurança Operacional.
Severidade
Variável; Até Crítico, dependendo do tipo de vulnerabilidade de software tradicional.
Bibliografia
[1] Modos de falha no Machine Learning, 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 Adversariais no Aprendizado Profundo: Caracterização e Divergência, Wei, et al, https://arxiv.org/pdf/1807.00051.pdf
[4] Vazamentos de ML: ataques e defesas de inferência de associação independente de dados e modelos em modelos de machine learning, Salem, et al, https://arxiv.org/pdf/1806.01246v2.pdf
[5] M. Fredrikson, S. Jha e T. Ristenpart, "Ataques de Inversão de Modelo que Exploram Informações de Confiança e Contramedidas Básicas", in Proceedings of the 2015 ACM SIGSAC Conference on Computer and Communications Security (CCS).
[6] Nicolas Papernot & Patrick McDaniel - Exemplos adversários no Aprendizado de Máquina AIWTB 2017
[7] Roubando modelos de machine learning por meio de APIs de previsão, Florian Tramèr, École Polytechnique Fédérale de Lausanne (EPFL); Fan Zhang, Universidade de Cornell; Ari Juels, Cornell Tech; Michael K. Reiter, Universidade da Carolina do Norte em Chapel Hill; Thomas Ristenpart, Cornell Tech
[8] O espaço de exemplos adversários transferíveis, Florian Tramèr, Nicolas Papernot, Ian Goodfellow, Dan Boneh e Patrick McDaniel
[9] Noções básicas sobre inferências de associação em Well-Generalized learning models Yunhui Long1 , Vincent Bindschaedler1 , Lei Wang2 , Diyue Bu2 , Xiaofeng Wang2 , Haixu Tang2 , Carl A. Gunter1 e Kai Chen3,4
[10] Simon-Gabriel et al., a vulnerabilidade adversária de redes neurais aumenta com a dimensão de entrada, ArXiv 2018;
[11] Lyu et al., uma abordagem unificada de regularização de gradiente para exemplos adversariais, ICDM 2015
[12] Padrões selvagens: dez anos após a ascensão do aprendizado de máquina adversarial - NeCS 2019 Battista Biggioa, Fabio Roli
[13] Detecção de malware robusta contra ataques adversários usando classificação monotônica Inigo Incer et al.
[14] Battista Biggio, Igino Corona, Giorgio Fumera, Giorgio Giacinto e Fabio Roli. Classificadores de ensacamento para combater ataques de envenenamento em tarefas de classificação adversária
[15] Uma rejeição aprimorada na defesa de impacto negativo Hongjiang Li e Patrick P.K. Chan
[16] Adler. Vulnerabilidades em sistemas de criptografia biométrica. 5ª Conferência Internacional AVBPA, 2005
[17] Galbally, McCool, Fierrez, Marcel, Ortega-Garcia. Sobre a vulnerabilidade dos sistemas de verificação facial para ataques de escalada de colinas. Patt. Rec., 2010
[18] Weilin Xu, David Evans, Yanjun Qi. Compressão de características: detectando exemplos adversariais em redes neurais profundas. Simpósio de Segurança do Sistema Distribuído e rede 2018. 18 a 21 de fevereiro.
[19] Reforçando a robustez adversária usando a confiança do modelo induzida pelo treinamento adversarial - Xi Wu, Uyeong Jang, Jiefeng Chen, Lingjiao Chen, Somesh Jha
[20] Análise causal orientada por atribuição para detecção de exemplos adversários, Susmit Jha, Sunny Raj, Steven Fernandes, Sumit Kumar Jha, Somesh Jha, Gunjan Verma, Brian Jalaian, Ananthram Swami
[21] Regressão linear robusta contra envenenamento por dados de treinamento – Chang Liu et al.
[22] Denoising de características para melhorar a robustez contra ataques adversariais, Cihang Xie, Yuxin Wu, Laurens van der Maaten, Alan Yuille, Kaiming He
[23] Defesas certificadas contra exemplos adversários - Aditi Raghunathan, Jacob Steinhardt, Percy Liang