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) adversário. Vinte e cinco das 28 empresas indicaram que não possuem as ferramentas certas para proteger seus sistemas de ML. Além do mais, eles procuram explicitamente orientação. Descobrimos que a falta de preparação não se limita às organizações mais pequenas – vão desde empresas da Fortune 500, governos a organizações sem fins lucrativos. Os clientes reconhecem a necessidade de proteger os sistemas de IA, mas simplesmente não sabem como.

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

Existem três objetivos para esse documento:

• Fornece uma perspectiva 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 levamos em conta a cadeia de fornecimento de IA e os controles e políticas relativos ao backup, recuperação e planejamento de contingência relacionados aos sistemas de IA.
• Descrever ameaças a ativos críticos de IA e orientações para protegê-los. Para ajudar diretamente 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. A seguir, fornecemos um conjunto de diretrizes que se sobrepõem e reforçam as práticas existentes no contexto dos sistemas de IA.
• Permita que as organizações conduzam avaliações de riscos de segurança de IA. A estrutura ajuda a reunir informações sobre o estado atual da segurança dos sistemas de IA em uma organização, realizar análises de lacunas e acompanhar o progresso da postura de segurança.

Nós o formulamos em conjunto com as partes interessadas da Microsoft, com representantes de 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 Pesquisa (Aether).

Introdução

Sugerimos usar esse documento para iniciar a discussão sobre a segurança de sistemas de IA alinhados aos esforços contínuos de segurança da informação e aos objetivos de negócios. O documento centra-se nos sistemas de IA e na inclusão de controlos tradicionais porque os sistemas de IA são construídos sobre infraestruturas de TI tradicionais.

Cobrimos as seguintes áreas relacionadas aos sistemas de IA.

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

Controles técnicos	Descrição
Coleta de dados	Controles e políticas relacionadas à coleta, armazenamento e classificação de dados usados para aprendizado de máquina e inteligência artificial.
Processamento de dados	Controles e políticas relacionadas ao processamento e engenharia de dados utilizados para aprendizado de máquina e inteligência artificial.
Treinamento de modelo	Controles e políticas relacionadas ao design, treinamento e validação de modelos.
Implantação de modelo	Controles e políticas relativas à implantação de modelos e infraestrutura de suporte.
Monitoramento do sistema	Controles e políticas relacionadas ao monitoramento contínuo de sistemas de aprendizado de máquina.
Gerenciamento de incidentes	Controles e políticas relacionadas à forma como os incidentes relacionados ao sistema de IA são tratados.
Continuidade dos negócios e recuperação de desastres	Controles e políticas relacionadas à perda de propriedade intelectual por meio de roubo de modelo, degradação de serviço ou outras vulnerabilidades específicas de IA.

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

A falta de segurança adequada dos sistemas de IA aumenta o risco não apenas para os sistemas de IA abordados nessa avaliação, mas, de forma mais geral, para todo o ambiente de tecnologia da informação e conformidade.

O objetivo desse documento não é substituir nenhum desses esforços existentes – mas descrever a segurança dos sistemas de IA a partir 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 exigiriam mais contexto, como a plataforma subjacente, o tipo de dados subjacente e a escolha do algoritmo. Se você é 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 da não implementação de um determinado controle. Uma organização pode optar por aceitar o risco de um controlo crítico e, em vez disso, implementar um controlo compensatório para reduzir o risco. Em última análise, essas classificações destinam-se a ajudar a orientar a tomada de decisões com base no risco, em vez de prescrever atividades.

Severidade

A gravidade de um comprometimento dependerá do caso de uso do modelo de IA. Felizmente, se os dados ou sistemas usados eram uma preocupação crítica antes da integração do aprendizado de máquina, eles deveriam permanecer os mesmos. Da mesma forma, se o modelo utilizado estiver “pronto para uso” sem nenhuma outra entrada, dependendo do contexto em que o modelo é usado, a gravidade de um comprometimento será provavelmente menor. Técnicas como privacidade diferencial podem reduzir o impacto potencial de um comprometimento. 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 profunda, em vez de depender de qualquer implementação defensiva.

Nível de gravidade sugerido

Sugerido como crítico

• Se o modelo de IA for treinado ou ingerir dados pessoais confidenciais, 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 nas operações de negócios
• Se o modelo de IA for usado em aplicações onde danos físicos, danos ou morte são um resultado possível
• Se o modelo de IA for utilizado num sistema que suporta infraestruturas críticas (por exemplo, água, energia, saúde)

Sugerido como alto

• Se o modelo de IA for treinado ou ingere dados pessoais confidenciais, informações confidenciais ou dados que de outra forma sejam considerados críticos pela organização
• Se o comprometimento desse modelo de IA tivesse 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 médio

• Se o modelo de IA for treinado em um subconjunto de dados de treinamento que contém tipos de dados confidenciais
• Se o comprometimento desse modelo de IA tivesse implicações para os modelos implantados na 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 for usado na produção, mas tiver informações sobre modelos de produção

Sugerido como baixo

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

Sugerido como informativo

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

Probabilidade

A probabilidade tem dois componentes principais: disponibilidade do modelo e 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 e os alertas estejam funcionando conforme projetado para garantir a resolução rápida dos problemas.
3. Certifique-se de que todos os sistemas de suporte estejam atualizados com os requisitos de segurança.

Os controles podem incluir ponto de extremidade de controle, segmentação de rede ou limitação de taxa. Atenção especial deve ser dada aos fluxos de tráfego e aos diagramas de rede ou pipeline, por exemplo, um invasor comprometendo um ponto de extremidade externo e trabalhando de trás para frente através de um pipeline.

Impacto

O impacto está relacionado aos efeitos para a organização. Sugerimos que você comece se familiarizando com as diferentes maneiras pelas quais os sistemas de ML podem ser atacados e considere as maneiras pelas quais os modelos de produção podem afetar a organização. Para mais informações, veja 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 riscos e vulnerabilidades para iniciar as organizações. Sugerimos preencher uma categorização semelhante reunindo 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 é a base do desenvolvimento de produtos de IA no BCG. À medida que a necessidade social de proteger os nossos sistemas de IA se torna cada vez mais evidente, ativos como o AI Security Risk Management Framework da Microsoft podem ser contribuições fundamentais. Já implementamos as melhores práticas encontradas nessa estrutura nos sistemas de IA que desenvolvemos para nossos clientes e estamos entusiasmados com o fato de a Microsoft ter desenvolvido e abrir o código-fonte dessa estrutura para o benefício de toda a indústria.” —Jack Molloy, engenheiro de segurança sênior, Boston Consulting Group

Uso Básico

O restante do documento segue essa estrutura:

• Um controle de risco contém uma descrição de qual área o controle cobre.
• 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á sendo mitigado.
• Orientação para implementação de um controle. Entendemos que nem todas as orientações podem ser implementadas por motivos comerciais legítimos. Sugerimos documentar 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; são adicionadas notas para descrever cada parte de uma estrutura de categorias de risco.

Controle de exemplo

Como ler

1. Coleção de dados

Categoria primária

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

Descreve quais controles nessa categoria cobrem em alto nível.

2. Fontes de dados

Categoria de controle

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

Deve descrever o risco que está sendo mitigado com os controles.

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

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

Controle: Os dados devem ser coletados de fontes confiáveis. Uma lista de fontes confiáveis deve ser mantida e atualizada. As aprovações para a coleta de dados não confiáveis devem ser consideradas caso a caso.

Palavreado específico que descreve as melhores práticas para o controle.

Diretrizes:

1. Todos os esforços razoáveis devem ser feitos para garantir que os dados sejam confiáveis antes de treinar um modelo. Dados não confiáveis ou desconhecidos podem introduzir vulnerabilidades de segurança posteriormente.
2. Os dados que contêm dados pessoais sensíveis, quer sejam utilizados para fins de ciência de dados ou de outra forma, devem ser limpos ou armazenados e acessados de forma adequada.
3. A recolha de dados sem consideração do seu contexto pode resultar em conjuntos de dados que contêm dados ilegais. Os esforços de coleta de dados devem estar atentos a materiais protegidos por direitos autorais, violações de dados e pontos de extremidade inseguros que vazam dados acidentalmente.

As orientações são recomendações para satisfazer os critérios acima. Nós os fornecemos de forma independente de produto e fornecedor para dar espaço para que as organizações resolvam 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 dessa avaliação é ajudar as organizações a articular, rastrear e remediar os riscos às operações comerciais introduzidos pelos sistemas de IA. Essa avaliação deve ser usada para:

1. Reúna informações sobre o estado atual da segurança de IA na 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 lugar para começar. Uma organização deve ter um programa de segurança da informação funcional antes de implementar as recomendações dessa avaliação. Para obter mais informações, veja o artigo Orientações de segurança do Azure no Cloud Adoption Framework.

Coleta de dados

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

Objetivo: Para garantir a integridade dos dados coletados utilizados em sistemas de IA.

Fontes de dados

Controle: Os dados devem ser coletados de fontes confiáveis. Uma lista de fontes confiáveis deve ser mantida e atualizada. As aprovações da gestão para a recolha de dados não confiáveis 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 apresentar riscos de conformidade para a organização.

Diretrizes:

1. Os dados de entrada devem ser validados e confiáveis através da aprovação da gestão antes da utilização num sistema de IA.
2. Os dados recolhidos para um sistema de IA devem ser revistos antes da utilização ou armazenamento.
3. Se apropriado, os dados coletados devem ser limpos de entradas indesejáveis.
4. A fonte dos dados deve ser documentada e mantida 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 coletados devem ter um proprietário responsável pela adesão às políticas documentadas.

Tipos de dados confidenciais

Controle: 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, fonte de 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.

Diretrizes:

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

Armazenamento de dados

Controle: Os dados devem ser armazenados adequadamente 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 gestão de ativos e de 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.

Diretrizes

1. Garanta 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 utilizados em sistemas de IA são rastreados sob uma política documentada de gestão 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 usuários que solicitam acesso devem passar por um processo formal de controle de acesso que inclua a aprovação da administração.
6. Os dados utilizados em processos de aprendizagem automática 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 inclui a aprovação da administração.
8. Os conjuntos de dados devem ser versionados com processos formais de controle de alterações em vigor.

Acesso de dados

Controle: Os conjuntos de dados devem ser devidamente rastreados e verificados por meio de hash criptográfico antes do uso.

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

Diretrizes:

1. O controle de acesso baseado em funções para conjuntos de dados deve ser aplicado.
2. Realize auditorias regulares de acesso para garantir que as contas com acesso aos conjuntos de dados tenham acesso aos conjuntos de dados. Certifique-se de que cada conta esteja operando dentro dos limites normais.
3. Se uma plataforma central de rastreamento não for usada, o acesso aos dados por meio de logs de acesso brutos deverá ser revisado para fins específicos. Certifique-se de que cada conta esteja operando dentro dos limites normais.
4. Provedores de recursos terceirizados, empreiteiros ou outras partes externas não devem ter acesso excessivo ou inadequado aos ativos de dados de treinamento/teste de uma empresa sem contratos em vigor.

Integridade de 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.

Diretrizes:

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 possam causar 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 no conjunto de dados devem incluir descrições criptográficas atualizadas e aprovação da administração antes de serem submetidas ao serviço central de rastreamento.

Processamento de dados

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

Objetivo: Garantir o processamento seguro dos dados desde a sua forma bruta até uma forma intermediária pronta para treinamento.

Processamento de pipelines

Controle: Os pipelines de processamento devem ser adequadamente protegidos.

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.

Diretrizes:

1. Nem todos os dados que passam por 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 um ambiente de produção seguro para um ambiente de desenvolvimento sejam devidamente rastreados. Considere que certos tipos de dados talvez não possam 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 afetar potencialmente os processos de negócios. O comprometimento de uma única conta resultaria no comprometimento de todos os dados que saíssem do ambiente de produção seguro.
3. Os processos de ciência de dados podem exigir recursos que estão fora dos limites rígidos de conformidade.
4. Os processos de ciência de dados devem sempre estar 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 rastreados durante todo o seu ciclo de vida; esse rastreamento inclui subconjuntos de conjuntos de dados maiores. Deve ser necessário que um modelo possa ser rastreado até os dados nos quais foi treinado. Além disso, deve existir uma cópia completa desses dados.

Abertura do conjunto de dados

Controle: Para garantir subconjuntos (por exemplo, fatias temporais e categóricas) de dados incluídos para a construção de modelos e como isso pode causar riscos à segurança (vazamento de privacidade, envenenamento/integridade através de ênfase excessiva nos comentários, etc.).

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

Diretrizes:

1. Os subconjuntos de dados são os próprios conjuntos de dados. 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 aprendizagem automática (SLAs, métricas de polarização, etc.), qualquer conjunto de dados (incluindo subconjuntos) deve cumprir um padrão mínimo documentado em torno dessas métricas se forem utilizadas na construção de modelos. Os metadados devem estar sempre anexados ao conjunto de dados.
3. Todos os conjuntos de dados que violem as políticas existentes devem ter uma exceção documentada e aprovada pela administração. Incluído na exceção deve estar um motivo documentado para a exceção, além dos metadados necessários.
4. Todos os dados utilizados para a construção do modelo devem ser rastreados em um local central. Os dados devem ser auditáveis a qualquer momento. Além disso, os modelos 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 ter versões apropriadas, de modo que todos os metadados sejam atualizados e os usuários dos dados entendam o conteúdo e as propriedades estatísticas. Se necessário, deverá ser exigida a aprovação da gestão para casos de utilização sensíveis.

Treinamento do modelo

Controles e políticas relativas ao treinamento de modelos e algoritmos.

Design de modelo

Controle: O código de treinamento do modelo é revisado por uma parte responsável.

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

Diretrizes:

1. O projeto e a pesquisa do modelo devem acontecer 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 locais para pesquisas ou para testar afirmações não comprováveis sobre a eficácia de um projeto.
2. A seleção do modelo para um sistema de produção deve ser revisada e aprovada pela administração. Esse 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 são frequentemente específicos de um domínio e deve haver documentação adequada acompanhando o modelo durante todo o seu uso em uma organização.
4. Garanta 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.

Treinamento do modelo

Controle: O critério de seleção do modelo (conjuntos de métricas e de validação) imita a deriva natural e quaisquer condições adversas 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 ambientes adversários.

Diretrizes

1. Os conjuntos de treinamento 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 robustez ao modelo, aumentando os conjuntos de dados com corrupções comuns que poderiam ser razoavelmente descobertas em estado selvagem.
3. Treine explicitamente contra as piores condições usando o retreinamento adversário.
4. Acompanhe experimentos e meta associados.

Seleção de modelos

A seleção de modelos consiste em escolher um modelo de um conjunto de candidatos, onde cada candidato possui um conjunto único de parâmetros de modelo, algoritmo de treinamento e hiperparâmetros de treinamento. O critério de seleção para o modelo vencedor é muitas vezes baseado em uma única métrica quantificável (por exemplo, perda mínima, taxa máxima de detecção), medida em um conjunto de dados de validação comum ou calculada em média em um conjunto de validação K-fold.

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

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

Diretrizes:

1. Sempre que for computacionalmente viável, a validação cruzada K-fold deve ser usada para evitar overfitting a um único conjunto de validação.
2. Verifique se os modelos selecionados apresentam bom desempenho em conjuntos de validação diferentes para validar se eles não se ajustaram demais.
3. Certifique-se de que os processos existam.

Controle de versão de modelo

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

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

Diretrizes:

1. Modelos de versão de modo que toda vez que um modelo é treinado, uma nova versão é atribuída a ele. 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 de produção ou de pré-produção. Faça referência a processos ou políticas SDL seguras existentes.

Implantação de modelo

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

Teste de segurança

Controle: Os modelos colocados em produção são adequadamente protegidos.

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

Diretrizes:

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. Ferramentas automatizadas devem ser usadas 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 escopo e o(s) método(s) para revisões de segurança independentes devem ser documentados.

Revisão de segurança e conformidade

Controle: O gerenciamento robusto 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.

Diretrizes:

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 relevantes 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 graduado de controles.
6. Os 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.

Monitoramento do sistema

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

Registros e revisão de registros

Controle: O registro e o monitoramento são vitais para 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.

Diretrizes:

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 de segurança devem ser revisados regularmente em busca de comportamento anormal.
3. Relatórios e alertas consolidados sobre a atividade do sistema devem ser gerados e revisados pela administração ou por um representante de segurança.

Gerenciamento de incidentes

Funções e responsabilidades

Controle: Os logs de segurança devem ser coletados em um local central.

Declaração de ameaça: durante uma investigação, os analistas de segurança não possuem um manual formalizado.

Diretrizes:

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 equipamento, perda de instalações, mau funcionamento do sistema, sobrecargas do sistema, erros humanos, não conformidade com políticas ou diretrizes, violações de segurança física, sistema não controlado alterações, 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 o recebimento 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

Planejamento, revisão e resultados

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

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

Diretrizes:

1. Os ativos críticos de IA devem ser identificados e inventariados.
2. A organização deve desenvolver um plano de continuidade de negócios (BCP) ou um processo de recuperação de desastres (DR) diante de ataques a sistemas de IA.
3. A organização deve identificar priorizados os riscos associados ao impacto da perda de sistemas críticos de IA devido a ataques.
4. As organizações devem ter testes de continuidade de negócios operados 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 Conselho de Padrões de Segurança PCI
• Modos de falha em aprendizado de máquina
• Modelagem de ameaças de sistemas e dependências de AI/ML
• AI/ML gira para a barra de bugs do ciclo de vida de desenvolvimento de segurança
• Segurança e governança corporativas

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

Baixe um PDF desse documento em nosso repositório GitHub.