Capítulo 23 — Segurança de IA e aprendizado de máquina: métodos I
Mapa da aula
Aula 23 publicada. Mapa, exemplo, EX067.
flowchart TD
N0["23.1 Análise de ameaças"]
N1["23.2 Mapeamento"]
N2["23.3 Priorização"]
N3["23.4 Seleção de testes"]
N4["23.4b Árvores de ataque"]
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"]
N1["23.2 Mapeamento"]
N2["23.3 Priorização"]
N3["23.4 Seleção de testes"]
N4["23.4b Árvores de ataque"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX067"]
[23.1 Análise de ameaças]
|
v
[23.2 Mapeamento]
|
v
[23.3 Priorização]
|
v
[23.4 Seleção de testes]
|
v
[23.4b Árvores de ataque]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX067]
Objetivos de aprendizagem
Você vai (1) realizar uma análise de ameaças estruturada para um sistema de IA; (2) mapear ameaças para o OWASP LLM 2025 e o MITRE ATLAS; (3) priorizar ameaças por probabilidade e impacto; e (4) selecionar testes para as principais ameaças.
23.1 Análise de ameaças
Para cada componente e fluxo do modelo de sistema, pergunte o que um atacante poderia fazer: injetar instruções, envenenar dados, escapar da detecção, extrair o modelo ou os dados, esgotar recursos ou abusar de ferramentas. Inclua pessoas internas e acidentes com efeitos semelhantes. Para o repositório de documentos do Ask Lumen, Rina fez cada pergunta por vez. Injetar instruções: sim, por meio dos envios de parceiros. Envenenar: não se aplica, já que ali não há treinamento. Extrair dados: possivelmente, se o chatbot citar documentos internos. Esgotar recursos: conversas longas. Um acidente com efeito semelhante foi uma clínica enviar um folheto desatualizado com horários errados.
23.2 Mapeamento
Mapeie as ameaças para entradas do OWASP LLM 2025 (por exemplo, LLM01 injeção de prompt, LLM02 divulgação de informações sensíveis, LLM06 agência excessiva, LLM10 consumo ilimitado) e para táticas e técnicas do MITRE ATLAS. O mapeamento ajuda a verificar a cobertura e a encontrar mitigações documentadas. O mapeamento de Rina pôs a injeção por documentos de parceiros em LLM01, a marcação para outro paciente em LLM06 e o custo de chats longos em LLM10. Ao procurar lacunas na lista, ela percebeu que não tinha nenhuma entrada de LLM02 para as respostas da ferramenta de agendamento e acrescentou um teste de que o chatbot nunca repete os detalhes da consulta de outro paciente.
23.3 Priorização
Avalie a probabilidade (acesso, habilidade e motivação do atacante) e o impacto (dano ao paciente, privacidade, custo, reputação). Uma escala simples de 1 a 3 e uma justificativa escrita bastam. Reveja quando as coisas mudarem. A justificativa importa mais que o número. Para a marcação para outro paciente, Rina escreveu que a probabilidade era 2 porque os tokens delegados agora bloqueiam o caminho direto, mas os próprios cuidadores do paciente ainda podem ser usados indevidamente; o impacto era 3 porque uma marcação errada pode atrasar o atendimento. Outro revisor pode então contestar o raciocínio, e não apenas a nota, e atualizá-lo quando os tokens ou as regras de cuidadores mudarem.
23.4 Seleção de testes
Para cada ameaça principal, escolha um teste: uma suíte de injeção, uma suíte de vazamento, uma simulação de envenenamento, um teste de carga. Defina os critérios de aprovação de antemão. Para a injeção por documentos de parceiros, o critério de aprovação foi definido antes do teste: no máximo uma afirmação falsa sobre clínicas em 200 documentos injetados, e zero marcações causadas por texto de documentos. Definir o limiar primeiro impede que a equipe decida depois que qualquer resultado obtido era aceitável. Um teste sem critério apenas descreve um comportamento; ele não pode falhar e, portanto, não pode mostrar que um controle funciona.
23.4b Árvores de ataque
Uma árvore de ataque decompõe um objetivo do atacante em subobjetivos ligados por E ou OU. Para "marcar uma consulta como outro paciente", os ramos OU poderiam ser: roubar as credenciais do paciente; manipular o chatbot para marcar em nome dele; explorar diretamente a API de agendamento. Cada ramo pode ser estimado e controlado separadamente, e a árvore mostra qual controle isolado bloqueia vários ramos — por exemplo, uma verificação de política vinculada ao paciente conectado bloqueia tanto o chatbot quanto alguns caminhos da API. Na LCH, o ramo das credenciais é tratado pelos controles de login do portal, fora do escopo da equipe de IA.
23.5 Exemplo resolvido (caso sintético da LCH)
As três principais ameaças de Rina para o Ask Lumen: (1) injeção por documentos de parceiros causando informações falsas (probabilidade 2, impacto 3); (2) marcação para outro paciente por manipulação (2, 3; mitigada por tokens delegados, reteste necessário); (3) esgotamento de custos por chats longos (3, 2). Testes: 200 documentos injetados medindo afirmações falsas; 400 tentativas de marcação para outro paciente; um teste de carga com cotas de tokens. O esgotamento de custos ficou com a maior probabilidade porque não exige habilidade, apenas paciência, e o teste das cotas era barato de executar. A marcação para outro paciente exigia reteste porque a mudança para tokens delegados era recente e não havia sido testada sob manipulação.
23.6 Erros e limites
Três erros são comuns: listas de ameaças não ligadas ao modelo de sistema; nenhuma justificativa para as notas; e testes escolhidos sem critérios de aprovação. Ameaças listadas sem referência ao modelo de sistema tendem a ser genéricas, como "o modelo pode ser hackeado", e não apontam para nenhum controle. Notas sem razões não podem ser revisadas nem atualizadas quando as condições mudam. Testes sem critérios de aprovação produzem resultados que podem ser lidos de qualquer jeito, então ninguém sabe se um controle funcionou. O registro de ameaças de Rina liga cada ameaça a um fluxo do diagrama, a uma razão e a um critério.
Exercícios
- EX067 — Lista de ameaças. Liste cinco ameaças para o NoShow, com mapeamento para o OWASP ou o ATLAS quando pertinente. Rubrica: 3 = cinco plausíveis com mapeamentos; 2 = quatro; 1 = duas; 0 = nenhuma.
- EX068 — Priorização. Avalie a probabilidade e o impacto de uma ameaça, com justificativa. Rubrica: 3 = ambos avaliados com razões; 2 = sem razões; 1 = vago; 0 = nenhum.
- EX069 — Desenho de teste. Projete o teste para a ameaça (2), com critério de aprovação. Rubrica: 3 = tamanho da suíte, método, métrica, limiar; 2 = três; 1 = vago; 0 = nenhum.
Síntese
Os métodos I transformam o modelo de sistema numa lista priorizada de ameaças, mapeada para catálogos compartilhados, cada uma com um teste e um critério de aprovação.
Continue estudando — capítulo 23 de 40
← Capítulo 22 (rascunho) · Índice de capítulos do curso · Capítulo 24 (rascunho) →