Capítulo 23 — Segurança de IA e aprendizado de máquina: análise de ameaças e falhas
Mapa da aula
Aula 23 publicada. Mapa, exemplo, EX067.
flowchart TD
N0["23.1 Análise de ameaças estruturada"]
N1["23.2 Mapeamento para catálogos compartilhados"]
N2["23.3 Combinando com a análise de falhas"]
N3["23.4 Classificação"]
N4["23.4b Mantendo a análise viva"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX067"]
Desenho lógico
flowchart LR
N0["23.1 Análise de ameaças estruturada"]
N1["23.2 Mapeamento para catálogos compartilhados"]
N2["23.3 Combinando com a análise de falhas"]
N3["23.4 Classificação"]
N4["23.4b Mantendo a análise viva"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX067"]
[23.1 Análise de ameaças estruturada]
|
v
[23.2 Mapeamento para catálogos compartilhados]
|
v
[23.3 Combinando com a análise de falhas]
|
v
[23.4 Classificação]
|
v
[23.4b Mantendo a análise viva]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX067]
Objetivos de aprendizagem
Você vai (1) conduzir uma análise de ameaças estruturada em um sistema de IA usando perguntas no estilo STRIDE adaptadas à IA; (2) mapear ameaças para técnicas do MITRE ATLAS e itens do OWASP LLM; (3) combinar análise de ameaças e de falhas; e (4) classificar ameaças por risco.
23.1 Análise de ameaças estruturada
Percorra cada elemento do diagrama de fluxo de dados e pergunte: ele pode ser falsificado (sensor falso, fornecedor falso), adulterado (dados envenenados, pesos modificados), repudiado (ação de agente impossível de rastrear), divulgado (inferência de pertencimento, vazamento de prompt), negado (esgotamento de recursos) ou usado para elevar privilégios (injeção de prompt que alcança uma ferramenta)? Acrescente perguntas específicas de IA: o modelo pode ser evadido, extraído, receber um backdoor ou ser levado a confabular de forma convincente? Percorrer elemento por elemento mantém a análise completa de um jeito que o brainstorming não consegue. Cada pergunta é feita mesmo quando a resposta parece óbvia, e "não se aplica" é registrado com um motivo.
23.2 Mapeamento para catálogos compartilhados
O MITRE ATLAS organiza o comportamento adversário contra IA em táticas (como reconhecimento, desenvolvimento de recursos, acesso inicial, acesso ao modelo de ML, persistência, evasão de defesas, descoberta, coleta, preparação de ataque de ML, exfiltração e impacto) e técnicas, com estudos de caso do mundo real. Mapear suas ameaças para técnicas do ATLAS e itens do OWASP LLM ajuda os revisores a verificar a cobertura e cria ligações com mitigações conhecidas. O mapeamento é uma verificação cruzada, e não um substituto da análise. Se uma técnica do catálogo não tem ameaça correspondente no modelo, a equipe pergunta se ela foi esquecida ou se de fato não se aplica. Os estudos de caso são especialmente úteis para convencer as partes interessadas de que uma ameaça é real, já que descrevem ataques que realmente aconteceram.
23.3 Combinando com a análise de falhas
Ameaças e falhas muitas vezes compartilham efeitos: um defeito não detectado pode vir de reflexo de luz (falha) ou de uma marcação (ataque). Analise-as juntas, para que controles como monitoramento estratificado e alternativa manual cubram ambas. A análise conjunta também evita trabalho duplicado e controles conflitantes. Uma alternativa manual projetada para o reflexo pode ser acionada por um atacante que queira atrasar as inspeções, então a própria alternativa precisa de um limite de taxa ou de um alerta. As tabelas de perigos e de ameaças de Sam compartilham identificadores de efeitos, de modo que um revisor pode ver todas as causas, acidentais ou deliberadas, que levam a um defeito não detectado, e verificar se algum controle cobre cada uma delas.
23.4 Classificação
Estime a probabilidade (capacidade e motivação do atacante, exposição) e o impacto (segurança física, financeiro, jurídico, reputacional). Use uma escala ordinal simples e documente o raciocínio. Reclassifique quando o sistema ou o cenário de ameaças mudar. Escalas ordinais como baixa, média e alta são honestas quanto à precisão: estimativas de probabilidade de ataques são julgamentos, não medições. Escrever o raciocínio ao lado de cada nota, por exemplo "média: boletins de fornecedores são públicos e editáveis por qualquer funcionário do fornecedor", permite que os revisores contestem o julgamento, e não o número. A reclassificação é disparada por eventos, como uma nova ferramenta ou um ataque publicado, e não apenas pelo calendário.
23.4b Mantendo a análise viva
Modelos de ameaças envelhecem. Novas ferramentas, fontes de dados, versões de modelo e ataques publicados mudam o quadro. Guarde a análise junto da arquitetura, dê a ela uma versão e agende uma revisão a cada mudança significativa e pelo menos uma vez por ano. Registre quais ameaças foram aceitas e por quem, para que os riscos aceitos não sejam esquecidos. Para o Wrench, o gatilho é concreto: quando o Bulletin Gate entrou em serviço, a ameaça 1 de Sam, injeção via boletim de fornecedor, teve de ser reavaliada, porque agora os boletins chegam ao Wrench apenas como registros estruturados. A probabilidade caiu, mas uma nova ameaça surgiu em seu lugar: uma atualização envenenada do modelo de extração, que o ensaio do Capítulo 47 testou depois.
23.5 Exemplo resolvido (caso sintético da NRS)
As cinco principais ameaças de Sam para o Wrench: (1) injeção indireta via boletim de fornecedor → ferramenta de ordens de serviço (probabilidade média, impacto alto); (2) injeção via notas de terceirizados (média/alto); (3) divulgação de informações sensíveis de documentos de RH na recuperação (média/médio, mitigada no Capítulo 13); (4) extração do prompt de sistema revelando nomes de ferramentas (alta/baixo); (5) esgotamento de recursos via documentos muito longos (média/médio). Cada uma foi mapeada para o OWASP (LLM01, LLM01, LLM02, LLM07, LLM10) e para técnicas do ATLAS de injeção de prompt e negação de serviço de ML. As duas ameaças de injeção compartilham um item em cada catálogo, mas continuam separadas na lista porque suas origens, e portanto seus controles, diferem.
23.6 Erros e limites
Três erros são comuns: listas de ameaças sem o modelo de sistema por trás; ignorar falhas não adversariais com o mesmo efeito; e classificações nunca revistas. Uma lista de ameaças sem modelo de sistema é genérica e deixa passar os caminhos específicos do projeto. Ignorar falhas que têm o mesmo efeito de ataques leva a controles duplicados ou a lacunas. Classificações congeladas no momento do projeto ficam desatualizadas à medida que ferramentas e fontes de dados mudam. Sam amarra a lista de ameaças à versão do diagrama, de modo que qualquer mudança no diagrama sinaliza a análise para revisão.
Exercícios
- EX067 — STRIDE para IA. Aplique as seis perguntas do STRIDE ao Pulse, uma ameaça para cada. Rubrica: 3 = seis plausíveis; 2 = quatro; 1 = duas; 0 = nenhuma.
- EX068 — Mapeamento. Mapeie "um atacante compra um domínio expirado citado em uma lista de URLs de treinamento" para uma tática do ATLAS e um item do OWASP. Rubrica: 3 = desenvolvimento de recursos/acesso inicial ou envenenamento; LLM04; 2 = um; 1 = vago; 0 = errado.
- EX069 — Classificação. Classifique as cinco ameaças de Sam e justifique a primeira. Rubrica: 3 = classificação sensata com raciocínio de probabilidade e impacto; 2 = classificação sem justificativas; 1 = vago; 0 = nenhuma.
Síntese
A análise de ameaças transforma o modelo de sistema em uma lista classificada do que pode dar errado, mapeada para catálogos compartilhados e combinada com a análise de falhas para que os controles cubram ambas.
Continue estudando — capítulo 23 de 50
← Capítulo 22 (rascunho) · Índice de capítulos do curso · Capítulo 24 (rascunho) →