Avaliação de risco de IA para engenheiros de ML

Apesar das razões convincentes para proteger os sistemas de ML, a pesquisa da Microsoft abrangendo 28 empresas descobriu que a maioria dos profissionais do setor ainda não chegou a um acordo com o aprendizado de máquina (ML) adversarial. Vinte e cinco das 28 empresas indicaram que não têm as ferramentas certas para proteger seus sistemas de ML. Além disso, estão explicitamente à procura de orientação. Descobrimos que a falta de preparação não se limita a organizações menores – elas vão desde empresas da Fortune 500, governos até organizações sem fins lucrativos. Os clientes reconhecem a necessidade de proteger os sistemas de IA, mas simplesmente não sabem como.

Este documento é um primeiro passo para as organizações avaliarem a postura de segurança dos seus sistemas de IA. Mas, em vez de adicionar mais uma estrutura para as organizações seguirem, tentamos fornecer o conteúdo de uma maneira que possa ser ajustada às estruturas tradicionais de avaliação de risco de segurança existentes.

Este documento tem três objetivos:

• Fornecer uma perspetiva abrangente para a segurança do sistema de IA. Analisamos cada elemento do ciclo de vida do sistema de IA em um ambiente de produção: desde a coleta de dados, processamento de dados até a implantação do modelo. Também contabilizamos a cadeia de suprimentos de IA e os controles e políticas com relação a backup, recuperação e planejamento de contingência relacionados a sistemas de IA.
• Descreva ameaças a ativos críticos de IA e orientações para protegê-los. Para ajudar diretamente os engenheiros e profissionais de segurança, enumeramos a declaração de ameaça em cada etapa do processo de construção do sistema de IA. Em seguida, apresentamos um conjunto de diretrizes que sobrepõem e reforçam as práticas existentes no contexto dos sistemas de IA.
• Permita que as organizações realizem avaliações de risco de segurança de IA. A estrutura ajuda a reunir informações sobre o estado atual de segurança dos sistemas de IA em uma organização, realizar análises de lacunas e acompanhar o progresso da postura de segurança.

Formulámo-lo em conjunto com as partes interessadas em toda a Microsoft, com representantes da Segurança do Azure, Estratégia de IA Responsável em Engenharia, Centro de Resposta de Segurança da Microsoft, Segurança do Azure e IA, Ética e Efeitos em Engenharia e Investigação (Aether).

Introdução

Sugerimos usar este documento para iniciar a discussão sobre a proteção de sistemas de IA alinhados aos esforços contínuos de segurança da informação e aos objetivos de negócios. O documento se concentra em sistemas de IA e inclusão de controles tradicionais porque os sistemas de IA são construídos em infraestrutura de TI tradicional.

Cobrimos as seguintes áreas relacionadas com sistemas de IA.

Controlos administrativos	Description
Políticas de segurança de aprendizado de máquina	Controles e políticas relacionados às políticas documentadas que regem o aprendizado de máquina, a inteligência artificial e a segurança da informação.

Controlos técnicos	Description
Recolha de dados	Controles e políticas relacionadas à coleta, armazenamento e classificação de dados que são usados para aprendizado de máquina e inteligência artificial.
Tratamento de dados	Controles e políticas relacionadas ao processamento e engenharia de dados usados para aprendizado de máquina e inteligência artificial.
Modelo de formação	Controlos e políticas relacionados com a conceção, formação e validação de modelos.
Implantação do modelo	Controlos e políticas relacionados com a implantação de modelos e infraestruturas de apoio.
Monitorização do sistema	Controles e políticas relacionadas ao monitoramento contínuo de sistemas de aprendizado de máquina.
Gestão de incidentes	Controles e políticas relacionados a como os incidentes relacionados ao sistema de IA são tratados.
Continuidade de negócio e recuperação após desastre	Controlos e políticas relacionados com a perda de propriedade intelectual através de roubo de modelos, degradação de serviços ou outras vulnerabilidades específicas da IA.

Adaptamos a estrutura existente de controles e políticas do popular padrão ISO27001:2013 e a mapeamos em todo o processo de construção do sistema de IA – desde a fase de coleta de dados até a resposta a ameaças aos sistemas de IA. As organizações podem ter alguns ou todos os controles existentes implementados a partir de ISO27001:2013 ou já estar em conformidade com várias estruturas de risco (NIST 800-53, PCI-DSS, FedRamp, etc.) como parte dos esforços de segurança da informação existentes.

Não proteger adequadamente os sistemas de IA aumenta o risco não apenas para os sistemas de IA abordados nesta avaliação, mas de forma mais geral para todo o ambiente de tecnologia da informação e conformidade.

O objetivo deste documento não é substituir nenhum desses esforços existentes – mas descrever a proteção de sistemas de IA do ponto de vista das ferramentas e estruturas existentes e estendê-la a todas as partes do processo de construção de IA.

As orientações listadas aqui não são prescritivas, pois isso exigiria mais contexto, como a plataforma subjacente, o tipo de dados subjacente e a escolha do algoritmo. Se você for um cliente do Azure Machine Learning, consulte o artigo Segurança e governança corporativa.

Gravidade, probabilidade e impacto sugeridos

Nem todos os controlos são de importância crítica para a segurança de um sistema de IA. Portanto, para priorizar adequadamente o trabalho, cada controle deve ser classificado pela organização com uma classificação de gravidade que seja relevante para o impacto nos negócios de não implementar um determinado controle. Uma organização pode optar por aceitar o risco de um controle crítico e, em vez disso, implementar um controle de compensação para reduzir o risco. Em última análise, essas classificações são para ajudar a orientar a tomada de decisões com base no risco, em vez de prescrever atividades.

Gravidade

A gravidade de um compromisso vai depender do caso de uso do modelo de IA. Felizmente, se os dados ou sistemas que estão sendo usados eram de preocupação crítica antes do aprendizado de máquina ser integrado, ele deve permanecer o mesmo. Da mesma forma, se o modelo usado estiver "pronto para uso" sem nenhuma outra entrada, dependendo do contexto em que o modelo é usado, a gravidade de um compromisso é provavelmente menor. Técnicas como a privacidade diferencial podem reduzir o impacto potencial de um compromisso. No entanto, esse contexto não reduziria a criticidade do sistema, dos dados ou do modelo. Recomendamos que os modelos sejam protegidos usando uma estratégia de defesa em profundidade, em vez de depender de qualquer implementação defensiva.

Nível de gravidade sugerido

Sugerido como crítico

• Se o modelo de IA é treinado ou ingere dados pessoais sensíveis, dados classificados ou dados regidos por requisitos de conformidade, como PCI, HIPAA, GLBA, etc.
• Se o modelo de IA for usado em um aplicativo ou sistema crítico para os negócios, esse comprometimento teria um grande impacto negativo das operações de negócios
• Se o modelo de IA é usado em aplicações onde danos físicos ou morte é um resultado possível
• Se o modelo de IA for usado em um sistema que suporta infraestrutura crítica (por exemplo, água, energia, saúde)

Sugerido como alto

• Se o modelo de IA é treinado ou ingere dados pessoais sensíveis, informações confidenciais ou dados que são considerados críticos pela organização
• Se o comprometimento desse modelo de IA teria um impacto grande, mas abrangente, nas operações de negócios
• Se o modelo de IA for usado em aplicativos ou sistemas críticos para os negócios

Sugerido como meio

• Se o modelo de IA for treinado em um subconjunto de dados de treinamento que contenha tipos de dados confidenciais
• Se o comprometimento deste modelo de IA teria implicações para os modelos implantados em produção
• Se o modelo de IA for usado em aplicativos não críticos, mas voltados para os negócios
• Se o modelo de IA não é usado na produção, mas tem informações sobre modelos de produção

Sugerido como baixo

• Se o modelo de IA é treinado em dados que não são usados na produção
• Se o modelo de IA não é usado na produção e não tem informações sobre modelos de produção

Sugerido como informativo

• Se os dados não forem classificados a partir de uma fonte verificada
• Se o modelo de IA não for usado na produção

Probabilidade

A probabilidade tem dois componentes principais, a disponibilidade do modelo e a disponibilidade de técnicas. Para reduzir a probabilidade de um ataque, uma organização deve implementar controles que:

1. Remova a superfície de ataque ou torne a superfície de ataque mais difícil de enumerar.
2. Certifique-se de que o registro em log e os alertas estão funcionando conforme projetado para garantir a resolução rápida dos problemas.
3. Certifique-se de que todos os sistemas de suporte estão atualizados com os requisitos de segurança.

Os controles podem incluir pontos finais de regulação, segmentação de rede ou limitação de taxa. Atenção especial deve ser dada aos fluxos de tráfego e diagramas de rede ou pipeline, por exemplo, um endpoint comprometido e externo comprometido e trabalhando para trás através de um pipeline.

Impacto

O impacto está relacionado com os efeitos na organização. Sugerimos que você comece se familiarizando com diferentes maneiras pelas quais os sistemas de ML podem ser atacados e considere maneiras pelas quais os modelos de produção podem afetar a organização. Para obter mais informações, consulte o artigo Modos de falha no aprendizado de máquina. Uma vez feita essa familiarização, ela pode ser mapeada para uma matriz de gravidade.

Matriz de gravidade

A tabela a seguir é uma matriz básica de gravidade de risco e vulnerabilidade para iniciar as organizações. Sugerimos preencher uma categorização semelhante, convocando arquitetos de segurança, engenheiros de aprendizado de máquina e membros da equipe vermelha de IA.

Tipo de ataque	Probabilidade	Impacto	Exploração
Extração	Alto	Baixa	Alta
Evasão	Alto	Médio	Alto
Inferência	Médio	Médio	Médio
Inversão	Médio	Alto	Médio
Envenenamento	Baixa	Alta	Baixo

"Projetar e desenvolver IA segura é uma pedra angular do desenvolvimento de produtos de IA no BCG. À medida que a necessidade social de proteger nossos sistemas de IA se torna cada vez mais evidente, ativos como a Estrutura de Gerenciamento de Riscos de Segurança de IA da Microsoft podem ser contribuições fundamentais. Já implementamos as melhores práticas encontradas nesta estrutura nos sistemas de IA que desenvolvemos para nossos clientes e estamos entusiasmados que a Microsoft tenha desenvolvido e código aberto essa estrutura para o benefício de toda a indústria." — Jack Molloy, engenheiro de segurança sênior, Boston Consulting Group

Utilização básica

O resto do documento segue esta estrutura:

• Um controlo de risco contém uma descrição da área que o controlo abrange.
• O objetivo do controle e o que ele deve realizar.
• Uma declaração de ameaça que fornece uma descrição do risco que está a ser mitigado.
• Orientações para a implementação de um controlo. Entendemos que nem todas as orientações podem ser implementadas por razões comerciais legítimas. Sugerimos documentar as orientações que não podem ser implementadas.

A tabela a seguir é um controle extraído da avaliação de risco dos sistemas de IA, notas são adicionadas para descrever cada parte de uma estrutura de categorias de risco.

Exemplo de controlo

Como ler

1. Recolha de dados

Categoria primária

Controles e políticas relacionadas à coleta e armazenamento de dados de todas as fontes que são usados para aprendizado de máquina e inteligência artificial.

Descreve o que os controles nesta categoria cobrem em um alto nível.

2. Fontes de dados

Categoria de controlo

Objetivo: Garantir a integridade dos dados coletados que são usados para modelos treinados.

Deve descrever o risco que está a ser mitigado com os controlos.

Declaração de ameaça: Os dados são recolhidos de fontes não fidedignas que podem conter Dados Pessoais Sensíveis, outros dados indesejáveis que podem afetar a segurança de um modelo ou que apresentam riscos de conformidade para a organização.

Uma declaração que descreve o resultado da não implementação do controlo.

Controlo: Os dados devem ser recolhidos a partir de fontes fidedignas. Deve ser mantida e atualizada uma lista de fontes fidedignas. As aprovações para a recolha de dados não fidedignos devem ser consideradas caso a caso.

Verborragia específica que descreve as melhores práticas para o controlo.

Orientação:

1. Todos os esforços razoáveis devem ser feitos para garantir que os dados possam ser confiáveis antes de treinar um modelo. Dados não confiáveis ou desconhecidos podem introduzir vulnerabilidades de segurança mais tarde no pipeline.
2. Os dados que contenham dados pessoais sensíveis, quer sejam utilizados para fins de ciência de dados ou de outra forma, devem ser limpos ou armazenados e acedidos de forma adequada.
3. A recolha de dados sem ter em conta o seu contexto pode resultar em conjuntos de dados que contêm dados ilegais. Os esforços de coleta de dados devem estar atentos a material protegido por direitos autorais, violações de dados, pontos finais não seguros que vazam dados acidentalmente.

As orientações consistem em recomendações para satisfazer os critérios acima referidos. Fornecemos-lhes de uma forma agnóstica em termos de produtos e fornecedores para dar espaço às organizações para resolverem o problema de uma forma que faça sentido para elas.

Avaliação de segurança de aprendizado de máquina

Antes de começar

O objetivo desta avaliação é ajudar as organizações a articular, rastrear e remediar os riscos para as operações de negócios introduzidos pelos sistemas de IA. Esta avaliação deve ser utilizada para:

1. Reúna informações sobre o estado atual da segurança de IA dentro da organização.
2. Realize uma análise de lacunas e construa um roteiro para implementar recomendações.
3. Acompanhe o progresso da segurança realizando essa avaliação anualmente ou semestralmente.

Se uma organização não tiver um programa de segurança, essa avaliação não é o ponto de partida. Uma organização deve ter um programa de segurança da informação funcional antes de implementar as recomendações nesta avaliação. Para obter mais informações, consulte o artigo Diretrizes de segurança do Azure no Cloud Adoption Framework.

Recolha de dados

Controles e políticas relacionadas à coleta e armazenamento de dados de todas as fontes que são usados para aprendizado de máquina e inteligência artificial.

Objetivo: Garantir a integridade dos dados recolhidos utilizados em sistemas de IA.

Origens de dados

Controlo: Os dados devem ser recolhidos a partir de fontes fidedignas. Deve ser mantida e atualizada uma lista de fontes fidedignas. As aprovações da administração para a recolha de dados não fidedignos devem ser consideradas caso a caso. Se uma fonte não confiável for aprovada, ela deverá ser documentada.

Declaração de ameaça: os dados são coletados de fontes não confiáveis que podem conter dados pessoais confidenciais, outros dados indesejáveis que podem afetar o desempenho de um modelo ou apresentam riscos de conformidade para a organização.

Orientação:

1. Os dados de entrada devem ser validados e confiáveis por meio de aprovação de gerenciamento antes de serem usados em um sistema de IA.
2. Os dados coletados para um sistema de IA devem ser revisados antes do uso ou armazenamento.
3. Se for caso disso, os dados recolhidos devem ser limpos de entradas indesejáveis.
4. A fonte dos dados deve ser documentada e conservada com os dados.
5. Os dados de inferência usados para treinar um modelo não devem ser implicitamente confiáveis e devem ser tratados como novos dados.
6. Os esforços de recolha de dados devem ser documentados e auditados. Os dados recolhidos devem ter um proprietário que seja responsável pela sua adesão às políticas documentadas.

Tipos de dados confidenciais

Controle: Para garantir que os dados armazenados para sistemas de IA sejam devidamente protegidos, rastreados e classificados de acordo com sua sensibilidade e caso de uso. Esse controle inclui rótulos de classificação de dados apropriados, políticas de acesso, informações de licença, estatísticas descritivas, origem e data de coleta.

Declaração de ameaça: os dados usados em sistemas de IA são usados, armazenados ou acessados de forma inadequada devido à falta de atributos, metadados ou documentação necessários.

Orientação:

1. Desenvolver uma política de dados que englobe a privacidade e a proteção de tipos de dados sensíveis e comunicar a política a todo o pessoal envolvido com o uso ou criação de sistemas de IA.
2. Implementar pipelines de treinamento e implantação que protejam a confidencialidade e a integridade dos dados usados em sistemas de IA.

Armazenamento de dados

Controlo: Os dados devem ser adequadamente armazenados de acordo com um processo de classificação documentado. Os conjuntos de dados devem ser indexados e considerados um ativo sujeito a políticas de gerenciamento de ativos e controle de acesso.

Declaração de ameaça: Os dados são armazenados de forma insegura e podem ser adulterados ou alterados por partes ou sistemas não autorizados. Os dados não são classificados corretamente, levando à divulgação de informações confidenciais ou dados pessoais sensíveis.

Orientação

1. Garantir que os sistemas ou contas de desenvolvimento ou pesquisa de IA não tenham acesso a bancos de dados de produção e vice-versa.
2. Os dados utilizados em sistemas de IA devem ser classificados e protegidos de acordo com uma política de classificação documentada.
3. Os dados usados em sistemas de IA são rastreados sob uma política documentada de gerenciamento de ativos.
4. Os dados usados para casos de uso sensíveis de IA são armazenados em sistemas aprovados e gerenciados.
5. O acesso aos dados deve ser auditado e os utilizadores que solicitem acesso devem passar por um processo formal de controlo de acesso que inclua a aprovação da gestão.
6. Os dados usados em processos de aprendizado de máquina não devem ser expostos à internet.
7. Os dados extraídos da Internet (ou de outras fontes não confiáveis) devem passar por um processo de filtragem que inclua aprovação de gerenciamento.
8. Os conjuntos de dados devem ser versionados com processos formais de controle de alterações em vigor.

Acesso a dados

Controlo: Os conjuntos de dados devem ser adequadamente rastreados e verificados através de hash criptográfico antes da utilização.

Declaração de ameaça: Os conjuntos de dados são alterados sem autorização.

Orientação:

1. O controle de acesso baseado em função para conjuntos de dados deve ser imposto.
2. Realizar auditorias regulares de acesso para garantir que as contas com acesso a conjuntos de dados devem ter acesso a conjuntos de dados. Certifique-se de que cada conta está operando dentro dos limites normais.
3. Se uma plataforma de rastreamento central não for usada, o acesso aos dados por meio de logs de acesso brutos deve ser revisado para finalidade. Certifique-se de que cada conta está operando dentro dos limites normais.
4. Provedores de recursos terceirizados, contratados ou outras partes externas não devem ter acesso excessivo ou inadequado aos ativos de dados de trem/teste de uma empresa sem contratos em vigor.

Integridade dos dados

Controle: os conjuntos de dados devem ser confiáveis e permanecer confiáveis durante todo o ciclo de vida do sistema de IA.

Declaração de ameaça: os conjuntos de dados são alterados durante o ciclo de vida da IA sem a capacidade de auditar ou rastrear alterações.

Orientação:

1. Os conjuntos de dados devem ser identificados de forma exclusiva, de modo que alterações não autorizadas em um conjunto de dados aprovado causem uma revisão do conjunto de dados.
2. Os conjuntos de dados e suas descrições criptográficas devem ser rastreados em um local central. O acesso ao conjunto de dados deve ser auditado.
3. As alterações ao conjunto de dados devem incluir descrições criptográficas atualizadas e aprovação da gestão antes de serem apresentadas ao serviço central de rastreio.

Processamento de dados

Controles e políticas relacionadas ao processamento de dados que são usados para aprendizado de máquina e inteligência artificial.

Objetivo: Garantir o tratamento seguro dos dados desde a sua forma bruta até um formulário intermédio pronto para formação.

Pipelines de processamento

Controlo: As condutas de processamento devem estar adequadamente protegidas.

Declaração de ameaça: um agente de ameaça pode fazer alterações não autorizadas no sistema alterando os pipelines de processamento de dados.

Orientação:

1. Nem todos os dados que se movem através de um sistema de produção são relevantes para os esforços de ciência de dados. É importante analisar apenas os dados necessários e garantir que todos os dados movidos de uma configuração de produção segura para uma configuração de desenvolvimento sejam rastreados adequadamente. Considere que certos tipos de dados podem não ser capazes de ser movidos para um ambiente de desenvolvimento. A ciência de dados pode precisar ocorrer em um ambiente intermediário seguro.
2. A auditoria adequada do acesso aos dados durante todo o ciclo de vida do processamento de dados é importante. Sem contas separadas, não pode haver auditoria suficiente do acesso. Além disso, a capacidade de responder a um incidente não pode acontecer sem potencialmente afetar os processos de negócios. O comprometimento de uma única conta resultaria no comprometimento de todos os dados que saem do ambiente de produção seguro.
3. Os processos de ciência de dados podem exigir recursos que estão fora de um limite estrito de conformidade.
4. Os processos de ciência de dados devem estar sempre em conformidade com os requisitos existentes. Esse processo pode incluir a transferência de recursos e processos de ciência de dados para um ambiente compatível.
5. Os dados devem ser acompanhados ao longo de todo o seu ciclo de vida; Esse rastreamento inclui subconjuntos de conjuntos de dados maiores. Deve ser exigido que um modelo possa ser rastreado até os dados sobre os quais foi treinado. Além disso, deve existir uma cópia desses dados na íntegra.

Abertura do conjunto de dados

Controle: Para garantir subconjuntos (por exemplo, fatias temporais, categóricas) de dados incluídos para a construção de modelos e como isso pode transmitir riscos de segurança (vazamento de privacidade, envenenamento/integridade por meio de ênfase excessiva no feedback, etc.).

Declaração de ameaça: o agente de ameaça pode recuperar partes dos dados reconstruindo/recuperando subconjuntos de dados.

Orientação:

1. Os subconjuntos de dados são conjuntos de dados propriamente ditos. Esses subconjuntos devem ter os mesmos metadados anexados a eles que o conjunto de dados pai e devem ser revisados de forma semelhante para tipos de dados confidenciais.
2. Dependendo das políticas relativas às práticas de aprendizado de máquina (SLAs, métricas de polarização, etc.), qualquer conjunto de dados específico (incluindo subconjuntos) deve atender a um padrão mínimo documentado em torno dessas métricas se quiser ser usado na construção de modelos. Os metadados devem ser sempre anexados ao conjunto de dados.
3. Todos os conjuntos de dados que violam as políticas existentes devem ter uma exceção documentada aprovada pelo gerenciamento. A exceção deve incluir um motivo documentado para a exceção, além dos metadados necessários.
4. Todos os dados usados para a construção de modelos devem ser rastreados em um local central. Os dados devem ser auditáveis a qualquer momento. Além disso, os modelos que forem treinados em dados não rastreados devem ser retirados da produção até que sejam combinados com um conjunto de dados conhecido com os metadados necessários.
5. Os conjuntos de dados devem ser adequadamente versionados de modo a que todos os metadados sejam atualizados e os utilizadores dos dados compreendam o conteúdo e as propriedades estatísticas. Se necessário, deve ser exigida a aprovação da gestão para casos de utilização sensíveis.

Preparação de modelos

Controlos e políticas relativas à formação de modelos e algoritmos.

Design do modelo

Controlo: O código de formação do modelo é revisto por uma parte responsável.

Declaração de ameaça: Código impróprio ou vulnerabilidades no código modelo produzem riscos de disponibilidade, integridade ou confidencialidade.

Orientação:

1. O design do modelo e a pesquisa devem ocorrer no ambiente apropriado. O design e a arquitetura do modelo podem ter um grande efeito na eficácia de um modelo. Os ambientes de produção não são o lugar para pesquisas ou para testar alegações não prováveis sobre a eficácia de um projeto.
2. A seleção do modelo para um sistema de produção deve ser revista e aprovada pela gerência. Este processo deve acontecer no início da fase de desenvolvimento e deve ser acompanhado através de qualquer mecanismo disponível (Excel, DevOps, Git, etc.). As exceções devem ser documentadas.
3. Os modelos geralmente são específicos do domínio e deve haver documentação adequada acompanhando o modelo durante todo o seu uso em uma organização.
4. Certifique-se de que os metadados do modelo estejam acessíveis aos usuários e que os usos não aprovados dos modelos sejam documentados e aplicados. É aceitável que um usuário ajuste um modelo existente, desde que novos metadados sejam anexados e rastreados adequadamente.

Preparação de modelos

Controle: O critério de seleção do modelo (conjuntos métricos e de retenção) imita o desvio natural e quaisquer condições adversárias que possam ser esperadas no momento da implantação.

Declaração de ameaça: um modelo treinado em condições ideais provavelmente será frágil quando implantado em configurações adversárias.

Orientação

1. Os conjuntos de formação e validação devem respeitar as dependências temporais naturais. Por exemplo, para classificadores de malware, um conjunto de validação deve incluir apenas versões de software posteriores às contidas no conjunto de treinamento.
2. Adicione explicitamente a robustez do modelo aumentando os conjuntos de dados com corrupções comuns que poderiam ser razoavelmente descobertas na natureza.
3. Treine explicitamente contra as piores condições usando o retreinamento adversarial.
4. Rastreie experimentos e metadados associados.

Seleção de modelos

A seleção do modelo consiste na escolha de um modelo de um conjunto de candidatos, onde cada candidato tem um conjunto único de parâmetros do modelo, algoritmo de treinamento e hiperparâmetros de treinamento. O critério de seleção para o modelo vencedor é frequentemente baseado em uma única métrica quantificável (por exemplo, perda mínima, taxa de deteção máxima) medida em um conjunto de dados de retenção comum, ou como média em um conjunto de validação K-fold.

Controle: O design do modelo e o algoritmo de treinamento incluem a regularização explícita ou implícita do modelo.

Declaração de ameaça: os modelos são sobreadequados a um conjunto de dados de treinamento e/ou validação única e são mais vulneráveis a modos de falha.

Orientação:

1. Sempre que possível do ponto de vista computacional, deve ser utilizada a validação cruzada com dobra K para evitar a sobremontagem a um único conjunto de retenção.
2. Verifique se os modelos selecionados têm um bom desempenho em conjuntos de retenção diferentes para validar que eles não se ajustaram demais.
3. Certifique-se de que os processos existem.

Controlo de versões de modelos

Controle: Os modelos são continuamente retreinados à medida que novos dados de treinamento fluem para pipelines de treinamento.

Declaração de ameaça: ocorre um incidente, mas o modelo envolvido não pode ser localizado para investigação.

Orientação:

1. Modelos de versão tais que cada vez que um modelo é treinado é-lhe atribuída uma nova versão. Qualificadores como my_model_dev_1.1 ou my_model_prod_1.1 devem ser usados para delinear a produção a partir de modelos de pré-produção. Esse controle de versão ajuda a isolar problemas para um problema de produção ou pré-produção. Faça referência a processos ou políticas SDL seguros existentes.

Implementação do modelo

Controles e políticas relacionados à implantação de modelos, algoritmos e infraestrutura de suporte.

Testes de segurança

Controlo: Os modelos colocados em produção estão adequadamente protegidos.

Declaração de ameaça: os sistemas de IA não são adequadamente testados quanto a vulnerabilidades antes da implantação.

Orientação:

1. Os critérios formais de teste de aceitação não foram definidos e documentados para novos sistemas de IA, atualizações e novas versões.
2. Novos sistemas de IA, atualizações ou novas versões devem ser implementados com testes formais.
3. Devem ser utilizadas ferramentas automatizadas para testar sistemas de informação, atualizações ou novas versões.
4. O ambiente de teste deve ser muito semelhante ao ambiente de produção final.
5. A frequência, o âmbito e o(s) método(s) para as revisões de segurança independentes devem ser documentados.

Revisão de segurança e conformidade

Controlo: A gestão robusta da rede subjacente é fundamental para proteger o sistema de ML e a infraestrutura.

Declaração de ameaça: Comprometimento do sistema de ML ao acessar a rede não segura.

Orientação:

1. Os dispositivos de gateway para sistemas de ML devem ser configurados para filtrar o tráfego entre domínios e bloquear o acesso não autorizado.
2. Os requisitos estatutários, regulamentares e contratuais pertinentes devem ser explicitamente definidos, documentados e abordados, juntamente com controlos específicos e responsabilidades individuais.
3. As diretrizes de configuração segura também devem ser documentadas, implementadas ou revisadas.
4. O critério para a segregação de redes de ML em domínios deve ser consistente com a política de controle de acesso da organização ou com os requisitos de acesso da organização.
5. Mecanismos como gateway seguro, VPN e roteamento para sistemas de ML devem ser implementados o suficiente para permitir um conjunto gradual de controles.
6. Usuários e engenheiros de ML devem empregar ou seguir requisitos para a implementação de controles para segregar e restringir adequadamente o uso de sistemas acessíveis ao público, redes internas e ativos críticos.

Monitorização de sistema

Controles e políticas relacionadas ao monitoramento contínuo de sistemas de aprendizado de máquina e infraestrutura de suporte.

Logs e revisão de logs

Controlo: O registo e a monitorização são vitais para os sistemas de ML por razões de segurança.

Declaração de ameaça: durante uma investigação, os logs dos sistemas de ML não são encontrados.

Orientação:

1. O registro e o monitoramento devem ocorrer de forma consistente em todos os sistemas de IA e seus componentes, incluindo armazenamento, pipelines, servidores de produção, etc.
2. Os logs de eventos e segurança devem ser revisados regularmente para detetar comportamentos anormais.
3. Os relatórios consolidados e os alertas sobre a atividade do sistema deverão ser gerados e revistos pela direção ou por um representante de segurança.

Gestão de incidentes

Funções e responsabilidades

Controlo: Os registos de segurança devem ser recolhidos numa localização central.

Declaração de ameaça: Durante uma investigação, os analistas de segurança não têm um manual formalizado.

Orientação:

1. As organizações devem seguir um processo formal para relatar incidentes de sistemas de IA no contexto de perda de serviço, perda de equipamentos, perda de instalações, mau funcionamento do sistema, sobrecargas do sistema, erros humanos, não conformidades com políticas ou diretrizes, violações de segurança física, alterações descontroladas do sistema, mau funcionamento de software, mau funcionamento de hardware e violações de acesso.
2. Devem ser desenvolvidos procedimentos formais de resposta a incidentes e escalonamento para documentar as ações tomadas após a receção de um relatório de um evento de segurança da informação.
3. Os procedimentos de resposta a incidentes devem ser testados periodicamente, acompanhando as métricas de resposta.

Planejamento de continuidade de negócios

Planeamento, revisão e resultados

Controle: Certifique-se de que os sistemas de ML possam ser remediados e recuperados após um incidente.

Declaração de ameaça: os incidentes causam problemas persistentes de confidencialidade, integridade ou disponibilidade em sistemas críticos de ML.

Orientação:

1. Os ativos críticos de IA devem ser identificados e inventariados.
2. A organização deve desenvolver um processo de plano de continuidade de negócios (BCP) ou recuperação de desastres (DR) em face de ataques a sistemas de IA.
3. A organização deve identificar prioritariamente os riscos associados ao impacto da perda de sistemas críticos de IA para ataques.
4. As organizações devem ter um teste de continuidade de negócios operado em um cronograma repetido para sistemas críticos de IA.

Referências

• Controles do Anexo A da ISO 27001 - Visão geral (isms.online)
• Site oficial do PCI Security Standards Council
• Modos de falha no aprendizado de máquina
• Modelagem de ameaças: sistemas e dependências de IA/ML
• Pivôs de AI/ML para a barra de bugs do ciclo de vida do desenvolvimento de segurança
• Segurança e governança corporativas

Se você tiver dúvidas, comentários ou feedback, entre em contato com atml@microsoft.com.

Faça o download de um PDF deste documento a partir do nosso repositório GitHub.