Técnicas ATLAS do MITRE para Ameaças de IA

Nota do Capítulo 17, pasta de Detecção de Ameaças Contra Sistemas de IA.
Apresenta o MITRE ATLAS, a matriz de táticas e técnicas de adversários contra sistemas de IA, com exemplos de técnicas, diferenças para o ATT&CK Enterprise e uso em gap analysis.
Dialoga com a nota de Prompt Injection do mesmo capítulo e com as notas de ATT&CK e de gap analysis dos capítulos 4 e 15.

1. Contexto e Posicionamento na Biblioteca

A biblioteca usa o MITRE ATT&CK desde o capítulo 4 como gramática para organizar TTPs de adversários contra sistemas corporativos tradicionais. Esta nota apresenta o complemento dessa gramática para a superfície de IA: o MITRE ATLAS, base de conhecimento pública mantida pela MITRE que cataloga táticas e técnicas reais usadas por adversários contra sistemas de inteligência artificial, em produção e em desenvolvimento. O ATLAS segue a mesma filosofia do ATT&CK, com comportamentos documentados em casos reais e simulados, organizados por táticas que descrevem o objetivo do adversário, e técnicas que descrevem como o objetivo é alcançado.

O posicionamento na biblioteca é o de ponte entre o capítulo 17 e o capítulo 15. O gap analysis do grupo MAP do Framework CTH pressupõe uma matriz de ameaças contra a qual medir cobertura, e, para sistemas de IA, essa matriz é o ATLAS. O leitor que já domina ATT&CK reconhecerá a estrutura e precisará ajustar três coisas: o alvo do adversário, que agora é o modelo, os dados e o pipeline de aprendizado; as técnicas, que incluem comportamentos sem equivalente em redes corporativas, como envenenamento de dados de treinamento; e o vocabulário de IDs, que usa o prefixo AML e numeração própria.

2. O Que é o MITRE ATLAS e Como Está Organizado

O ATLAS organiza o conhecimento em uma matriz de táticas e técnicas, com IDs no formato AML.T seguido de quatro dígitos, e sub-técnicas com sufixo adicional. As táticas descrevem por que o adversário age em cada etapa, e a sequência começa em reconhecimento, passa por acesso a modelos, preparação do ataque e execução, e termina em exfiltração e impacto. Entre as táticas, o ATLAS inclui táticas específicas de IA que o ATT&CK Enterprise não possui, como ML Model Access, que cobre os caminhos pelos quais o adversário chega ao modelo, e ML Attack Staging, que cobre a preparação técnica do ataque, como criação de dados adversários.

Cada técnica traz descrição, exemplos, procedimentos observados e, em muitos casos, mitigação e detecção sugeridas, e a base cita casos reais reportados pela indústria, de roubo de modelos por API a injeção de prompt em assistentes. O ATLAS também mantém mitigações organizadas por objetivo, com orientação que cobre desde hardening de MLOps até controles de aplicação de LLM, e esse material é o insumo direto do gap analysis descrito na seção 8. Para fins de estudo, o leitor deve tratar o ATLAS como o ATT&CK da IA, com a mesma disciplina de mapear, priorizar e medir, e não como catálogo de curiosidades acadêmicas. Essa equivalência de método é o que permite reutilizar processos já maduros de ATT&CK, do gap analysis ao red team, sem inventar disciplina paralela.

3. Estrutura da Matriz: Táticas Aplicadas a Sistemas de IA

A melhor forma de fixar o ATLAS é percorrer as táticas como fases de uma campanha contra um sistema de IA concreto, por exemplo um assistente corporativo conectado a ferramentas internas. O reconhecimento cobre a descoberta da superfície, de qual modelo roda a qual API responde e quais ferramentas o agente executa. O acesso inicial cobre como o adversário entra, por prompt injection, por API exposta ou por cadeia de suprimento. O staging cobre a preparação técnica do ataque, como dados adversários e prompts maliciosos testados. A execução dispara o ataque contra o modelo, a persistência fixa comportamento hostil no modelo ou no pipeline, a evasão contorna os controles de detecção, a exfiltração leva dados, credenciais ou o próprio modelo, e o impacto degrada, cobra ou destrói.

Duas observações ajudam a leitura da tabela. Primeiro, as táticas do ATLAS não são lineares obrigatórias, e ataques reais combinam caminhos curtos, como o acesso direto a artefato de modelo mal protegido, que pulam reconhecimento e staging. Segundo, a tática de impacto tem peso desproporcional em IA, porque envenenar ou degradar um modelo compromete decisões futuras em escala, dano que se estende muito além do incidente inicial e que a seção de gap analysis traduz em prioridade.

4. Táticas e Técnicas Representativas

A tabela abaixo reúne técnicas representativas, com IDs conhecidos da base pública, a tática a que pertencem e um exemplo de aplicação real no contexto corporativo. A lista não é exaustiva, e o leitor deve consultar a matriz completa no site do ATLAS ao montar o gap analysis.

A leitura da tabela evidencia um ponto estrutural: no ATLAS, o adversário às vezes não quer roubar dados, quer degradar a capacidade de decisão da vítima, e técnicas de impacto como envenenamento e apagamento de checkpoints ilustram esse objetivo. Para organizações cujo negócio depende de decisões de modelo, risco de integridade do modelo equivale, em impacto, ao risco de confidencialidade que domina o ATT&CK Enterprise.

5. Técnicas Chave com Exemplos Concretos e Detecção

A injeção de prompt, AML.T0011, é a técnica de maior relevância imediata porque atinge a classe de sistema mais difundida, os assistentes e agentes. O exemplo concreto: o adversário envia e-mail com instrução oculta em texto claro sobre fundo branco, o agente de correio processa a mensagem ao resumir a caixa de entrada, e a instrução manda consultar a ferramenta de RH e enviar a folha de pagamento para um destino externo. O bloqueio correto não é a filtragem de texto, e sim o contrato de ferramentas, com egress por classificação e aprovação humana para envio externo, na arquitetura da nota de Guardrails.

O par de acesso a API e exfiltração por inferência, AML.T0043 e AML.T0024, aparece em sistemas de consulta a conhecimento interno. O adversário com conta legítima formula perguntas sistemáticas que induzem o modelo a reconstruir dado sensível do índice, frase a frase, sem violar nenhuma regra de consulta individual. A detecção está no padrão de sessão, e não no conteúdo de cada consulta isolada, como exemplifica a busca abaixo.

AppInsightsAPI
| where TimeGenerated > ago(1d)
| where OperationName == "InferenceChat"
| summarize Consultas = count(), Sessoes = dcount(SessionId),
    TokensTotais = sum(Tokens)
    by UserPrincipalName, bin(TimeGenerated, 1h)
| where Consultas > 60 or TokensTotais > 40000
| extend Risco = "sondagem_sistematica_de_api_de_inferencia"

Em modelos treinados internamente, o envenenamento de dados e o backdoor, AML.T0020 e AML.T0021, exigem visão sobre o pipeline, e não sobre a API. Os sinais vivem em auditoria de proveniência de dataset, revisão de mudanças no corpus e testes de comportamento condicionado a gatilhos no pipeline de avaliação. Times sem linhagem de dados não têm nem superfície para caçar, e essa é a lacuna mais comum encontrada em gap analysis dessa classe de sistema.

6. Tabela de Técnicas, Exemplo e Defesa

A tabela abaixo cruza técnicas selecionadas, um exemplo concreto de operação e a defesa de maior alavancagem, no formato que o gap analysis consome. A coluna de defesa cita a camada da nota de Guardrails quando aplicável, para que o mapa de lacunas aponte diretamente para o controle implementável. Linhas sem defesa citável indicam lacuna de arquitetura, e não de produto.

A regra de leitura da tabela é a mesma da matriz: defesa segue superfície, e superfície segue inventário. Um sistema que não expõe API de inferência elimina de imediato três linhas, e um sistema que não treina modelo elimina as técnicas de pipeline, o que reduz o gap analysis a um exercício de inventário honesto antes de qualquer compra de ferramenta. O exercício de eliminação por linha costuma reduzir o escopo real à metade.

7. Diferença para ATT&CK Enterprise

A comparação com o ATT&CK Enterprise é o caminho mais rápido para internalizar o ATLAS, e a tabela abaixo organiza as diferenças que importam para o analista. O ponto de encontro entre as duas matrizes é o agente autônomo: quando um agente de IA tem acesso a rede, credenciais e ferramentas corporativas, a campanha contra esse agente cruza as duas matrizes, e o mapeamento completo exige as duas visões em conjunto.

A diferença mais enganosa para o analista experiente é a de superfície. No ATT&CK, a superfície é exposta por serviço de rede ou por engenharia social sobre humano; no ATLAS, a superfície inclui o comportamento estatístico do próprio modelo, que pode ser sondado, reproduzido e manipulado por quem tem acesso de consulta legítimo. Essa é a razão técnica pela qual uma API de inferência pública é, no vocabulário do ATLAS, uma posição de ML Model Access, e a razão pela qual controles de taxa, de autenticação e de monitoramento de uso são mitigações de primeira linha.

8. Uso em Gap Analysis de Sistemas de IA da Empresa

O gap analysis com ATLAS segue o mesmo método do gap analysis ATT&CK do grupo MAP, com cinco passos adaptados. O primeiro passo é inventariar os sistemas de IA da organização, com quatro classes que demandam controles diferentes: modelos treinados internamente, modelos de terceiro consumidos por API, aplicações de LLM com ferramentas e agentes autônomos. O segundo passo é mapear cada sistema às técnicas ATLAS aplicáveis, considerando a superfície real, por exemplo, uma API de inferência exposta puxa o conjunto de técnicas de ML Model Access e de evasão, e um agente com e-mail puxa a AML.T0011 com força. O terceiro passo é mapear os controles existentes por técnica, dos mesmos tipos que a nota de Guardrails detalha.

O quarto passo é atribuir lacunas com prioridade, combinando a criticidade do sistema com a plausibilidade da técnica, na mesma lógica de priorização por ameaça que o capítulo 1 ensina. O quinto passo é transformar lacunas em plano, com dono, prazo e métrica de fechamento, e registrar o mapa na plataforma de CTI para evolução contínua. A tabela abaixo mostra o formato de saída com três exemplos de inventário hipotético.

O formato da tabela é deliberadamente igual ao do MAP.4 do capítulo 15, porque a intenção operacional é a mesma: converter matriz de ameaças em fila de trabalho com dono e prazo. Times que tentam pular direto da matriz para compra de ferramenta produzem controles órfãos, e times que documentam lacuna sem dono reproduzem o erro clássico de heatmap decorativo que a biblioteca critica no capítulo 15. A métrica de fechamento merece decisão explícita no início do exercício, com meta por técnica prioritária e data, porque gap sem prazo vira inventário de desejo. O dono de cada lacuna deve ser uma função, e não um projeto temporário. A cadência de revisão segue a seção de erros deste capítulo, com revisão semestral e revisão por evento.

9. Integração com o Ciclo de CTI

No ciclo de inteligência, o ATLAS atua em três pontos. No planejamento, alimenta PIRs específicas de IA, como quais técnicas contra sistemas de IA são mais usadas por atores relevantes ao setor, e o registro de incidentes públicos do ATLAS fornece casos para responder. Na coleta e análise, o vocabulário de técnicas padroniza o registro de campanhas contra IA, e a nota de CAIRN desta mesma pasta mostra como sinais de geração assistida acrescentam dimensão à análise de capacidade do ator. Na disseminação, o mapeamento ATLAS permite comparar o risco de IA com o risco tradicional na mesma linguagem de prioridade que a liderança já usa para ATT&CK, o que evita que o tema vire ilha de discussão técnica.

A integração com hunting segue o mesmo desenho do resto da biblioteca: cada técnica ATLAS aplicável vira hipótese de caça com fonte de dados declarada, por exemplo, sondagem de API de inferência vira caça em logs de aplicação com distribuição de consultas, e envenenamento de dados vira caça em auditoria de pipeline com linhagem. O grupo HNT do capítulo 15 fornece o método, e o ATLAS fornece o catálogo de hipóteses específicas de IA que faltava a esse método. A tabela abaixo exemplifica a conversão em fichas de caça, com fonte de dados e critério de avaliação declarados, no formato do grupo HNT. O critério é o que separa caça estruturada de consulta improvisada, porque define quando a hipótese está confirmada ou negada. Cada ficha deve registrar data, analista e resultado, para que a caça alimente o histórico de cobertura do capítulo 7.

10. Erros Comuns e Pontos de Atenção

Um ponto de atenção final é o ritmo de evolução da base. O ATLAS incorpora técnicas novas com frequência maior que o ATT&CK Enterprise, refletindo a velocidade do campo, e o gap analysis que vale por um ano no plano tradicional não vale por um ano no plano de IA. A cadência recomendada é revisão semestral do mapeamento e revisão por evento, sempre que um caso público relevante ou um incidente interno mudar a plausibilidade de uma técnica.

11. Integração com o Restante da Biblioteca

A nota dialoga primeiro com o capítulo 4, onde o ATT&CK foi apresentado, e a recomendação de leitura é lê-la junto da nota de ATT&CK para consolidar as duas gramáticas em uma só prática de mapeamento. Com o grupo MAP do capítulo 15, a nota fornece a matriz que estende heatmap e gap analysis à superfície de IA, com o mesmo formato de tabela e o mesmo requisito de dono e prazo. No capítulo 17, a nota de Prompt Injection detalha a técnica AML.T0011 que aqui aparece uma vez na tabela, a nota de Guardrails descreve as mitigations que o gap analysis vai cobrar, e o AutoPT fornece o motor de teste que separa controle documentado de controle eficaz.

Para o leitor que fecha o estudo da biblioteca, o ATLAS é o fechamento natural do arco de frameworks que começou no ATT&CK e passou por Diamond Model e Pyramid of Pain. O aprendizado que fica é o da continuidade de método: a organização madura em CTI não muda de método quando muda de superfície, ela mantém o ciclo de mapear, priorizar, testar e medir, e apenas troca a matriz que dá vocabulário ao exercício.