AUT.4 - Machine Learning e AI para Hunting

Nota do grupo AUT (Automação e Orquestração) da seção 15 do Framework CTH.
Deriva do Capítulo 14 do PDF de referência, controle AUT.4, com os subcontroles AUT.4.1 a AUT.4.5.
Trata do uso realista de machine learning e de LLMs como amplificadores do analista em CTI e Threat Hunting, com requisitos de dados, limitações conhecidas e salvaguardas por nível.

1. Contexto e Posicionamento no Framework CTH

Machine learning detecta padrões que são invisíveis ao olho humano e reduz o alert fatigue que esgota as equipes de segurança. Modelos analisam volumes de telemetria impossíveis de processar manualmente, identificam anomalias sutis em múltiplas dimensões ao mesmo tempo e se adaptam a mudanças do ambiente com re-treino. A aplicação de ML e IA não substitui o analista, mas amplia sua capacidade de forma expressiva, e é essa premissa que orienta o AUT.4.

No Framework CTH, o controle complementa a automação determinística do AUT.1 e do AUT.3, atacando o que regras fixas não alcançam: comportamento sem assinatura, padrões estatísticos e volumes de texto. Ele depende diretamente da qualidade de telemetria garantida pelo DAT.5, porque modelo alimentado por dado sujo aprende sujeira. As salvaguardas por nível começam nos jobs de anomalia nativos do SIEM e evoluem para clustering customizado, processamento de linguagem natural e modelos preditivos, sempre com validação humana nas decisões.

2. Usos Realistas de ML e IA no Ciclo de CTI e Hunting

O primeiro passo de um programa sadio é separar o que funciona hoje em produção do que é promessa de palestra. Os seis usos abaixo têm histórico consolidado em times de médio porte e retornam valor mensurável sem exigir equipe dedicada de ciência de dados.

Cada linha da tabela combina uma técnica com uma decisão humana que permanece inegociável. O job de anomalia aponta o desvio, o analista decide se ele importa. O LLM redige o resumo, o analista valida cada afirmação. Esse desenho é o que separa ampliação de capacidade de abdicação de julgamento.

3. Requisitos para Funcionar

ML não é mágica aplicada sobre qualquer dado, e os requisitos abaixo definem se o projeto tem chance de sucesso antes da primeira linha de código. Ignorá-los produz os pilotos eternos que minam a credibilidade da iniciativa.

• Dados limpos e rotulados ou semi-rotulados: classificação e clustering precisam de amostras com veredito, que vêm dos relatos do SOC, dos fechamentos de caso e das investigações de hunting, todos fontes naturais de rótulo.
• Telemetria consistente: campos estáveis, horários confiáveis e cobertura uniforme, garantidos pelo DAT.5, pois mudança silenciosa de schema corrompe o treino e a inferência.
• Volume suficiente: anomalia estatística exige população para comparar, e regra prática de partida é meses de histórico com milhões de eventos por classe de comportamento.
• Métrica de sucesso definida antes do treino: precisão, recall e custo por falso positivo acordados com o negócio, porque modelo sem alvo mensurável vira demonstração.

O rótulo é o recurso mais escasso, e por isso o fluxo de feedback do analista é infraestrutura crítica do programa. Cada fechamento de caso com veredito correto alimenta o próximo re-treino, transformando a rotina do SOC em combustível do modelo. Times que formalizam esse ciclo colhem melhoria contínua sem projeto de rotulagem manual gigante.

4. Limitações e Riscos

O risco de deriva merece ênfase porque é silencioso e universal. Modelo que funcionou no trimestre do ataque X degrada quando o adversário muda de ferramenta, e a degradação não dispara alerta por si só. Trate modelo como regra de detecção do AUT.3: com versão, dono, data de revisão e suíte de validação periódica. A analogia é proposital, e time que já opera pipeline de detecção entende rapidamente o pipeline de modelo.

O monitoramento de saúde do modelo pode se apoiar em sinais objetivos, registrados em painel dedicado e revisados pelo dono do modelo.

Registrar esses sinais transforma a saúde do modelo em operação visível, e não em impressão subjetiva. O dono do modelo responde aos sinais como o dono da regra responde à detecção morta no AUT.3. Sem esse circuito, o programa de ML entra em decadência silenciosa entre um trimestre e outro.

5. Casos de Uso com LLM em CTI

LLMs são particularmente bons em texto, e a CTI é rica em texto: relatórios de fornecedor, posts de pesquisador, feeds em linguagem natural e relatos internos de incidente. Os três usos abaixo entregam retorno imediato com estrutura de prompt disciplinada e validação humana.

• Extração de TTPs de relatório: o modelo lê o relatório e devolve JSON estruturado com técnicas ATT&CK, malwares, atores e IOCs, pronto para conferência humana e carga no TIP.
• Enriquecimento e síntese: consolidar vários relatos sobre a mesma campanha em um dossiê único com citações dos trechos de origem, reduzindo horas de leitura a minutos de revisão.
• Elaboração de hipóteses: a partir de TTPs extraídos e do inventário de telemetria, propor candidatas de hunt alinhadas às EEI do programa, que o hunter avalia e reescreve.

O exemplo abaixo ilustra o padrão de extração com saída estruturada, o mais valioso na prática. A ressalva de validação humana acompanha sempre: modelo extrai, analista confere contra o texto de origem antes de qualquer carga no TIP, porque alucinação em inteligência é falso IOC em produção.

Prompt de extração (resumido)
Sistema: extraia TTPs, malwares, atores e IOCs do relatório abaixo.
Responda SOMENTE com JSON no schema {techniques[attck_id, name, evidence],
malware[], actors[], iocs[type, value]}. Se um campo não estiver no texto,
devolva lista vazia. Nunca infira valores ausentes.
Usuário: <texto do relatório>
Saída esperada (trecho):
{
  "techniques": [
    {"attck_id": "T1566.002", "name": "Spearphishing Link",
     "evidence": "emails com link para portal falso de webmail"}
  ],
  "iocs": [
    {"type": "domain", "value": "exemplo-webmail[.]com"}
  ]
}

Valide o JSON com schema antes de qualquer carga automática, pois resposta malformada corrompe o TIP tanto quanto a alucinação. Remova ou mascare dados pessoais do texto enviado ao modelo quando o caso permitir, alinhando o fluxo à LGPD. Registre no caso a versão do modelo e o prompt usados, para que a origem de cada afirmação do dossiê seja rastreável.

6. Exemplo Prático de Job de Anomalia no SIEM

O job de anomalia é a porta de entrada mais barata de ML no programa, porque usa o módulo nativo do SIEM e telemetria já coletada pelo grupo DAT. O exemplo abaixo define um job clássico, com critérios de disparo e fatores de contribuição exibidos ao analista.

Job de anomalia: logons fora de padrão por usuário
Campo-alvo: contagem de EventID 4625 (falha) e 4624 (sucesso) por usuário
Janela: 1 hora, com atraso de 5 minutos para acomodar a coleta
Baseline: 14 dias de histórico, atualização diária do perfil da entidade
Função: desvio sobre a média móvel por hora do dia da própria entidade
Condição de disparo: score acima de 3 desvios E horário fora do padrão
                      da entidade E volume >= 5 eventos na janela
Saída: alerta com {usuário, host, horário, score, fatores}
Fatores exibidos: hora incomum (0.62), host novo para a entidade (0.27),
                  pico de falhas consecutivas (0.11)
Destino: fila de triagem priorizada do SOC e painel de tendências

Duas decisões desse exemplo sustentam a qualidade a longo prazo. Primeira, o baseline é por entidade, o que reduz falso positivo em comparação com limiares globais. Segunda, o alerta carrega os fatores que geraram o score, permitindo que o analista valide em segundos e alimente o ciclo de rótulos descrito na seção 3.

7. Papel do Analista: IA Acelera, Analista Decide

A divisão de trabalho saudável dá à máquina o recorte, a ordenação e a redação, e reserva para o humano a relevância, a decisão e a responsabilidade. IA acelera a leitura de cem páginas, a varredura de milhões de eventos e a redação do primeiro rascunho. O analista decide o que é ameaça para o negócio, o que merece contenção e o que entra na inteligência oficial do TIP.

Esse desenho tem consequência prática de projeto: toda saída de modelo deve chegar ao analista com evidência navegável. Score de priorização exibe os fatores que o geraram, resumo de LLM cita os trechos de origem, anomalia mostra a série histórica que a gerou. A regra simples é que nenhum modelo fala em nome do analista, apenas para o analista, e a assinatura de cada veredito é humana.

8. Avaliação de Custo e Benefício Antes de Implantar

A ordem das perguntas é deliberada e começa pela alternativa simples. Muitos projetos de ML resolvem problemas que uma consulta bem escrita resolve melhor, e o filtro da segunda pergunta economiza meses. Quando ML passa no filtro, comece pelo uso de menor risco da tabela da seção 2, meça contra baseline manual e expanda com evidência, nunca por entusiasmo.

9. Implementação e Salvaguardas por Nível

O avançado exige maturidade real dos níveis anteriores, com feedback de rótulos funcionando e telemetria estável por ciclos. Modelos preditivos sobre dados imaturos produzem profecias que consomem reuniões. Documente cada modelo no mesmo espírito do catálogo do AUT.3, com dono, versão, dataset de treino e data de revisão.

10. Erros Comuns e Pontos de Atenção

• Esperar milagre do ML sem dados: modelo não inventa sinal que a telemetria não captura; resolva o DAT.5 antes de comprar o algoritmo.
• Automatizar preconceito: dataset rotulado por decisões passadas herda os vieses delas, como priorizar alertas de servidores e ignorar estações de executivos; revise a amostra e meça por segmento.
• Saída de LLM sem revisão entrando no TIP: alucinação vira IOC falso compartilhado internamente; exige conferência contra a fonte em todo fluxo.
• Métrica de precisão sem alvo de negócio: 99% de precisão em evento que ocorre duas vezes por ano não diz nada; defina custo por falso positivo e por falso negativo.
• Piloto eterno: demonstração que nunca chega à fila do SOC consome orçamento e credibilidade; defina critério de go ou no-go com prazo.
• Ignorar privacidade: treinar e inferir sobre dados pessoais sem base legal e sem minimização cria exposição regulatória paralela ao risco cibernético.
• Trocar analista por modelo: corte de equipe justificado por IA transfere o erro da máquina para o negócio, sem quem valide e corrija.

11. Integração com Outros Controles do Framework CTH

O AUT.4 alimenta e consome quase todo o resto do framework, o que explica seu posicionamento de amplificador. As anomalias e os clusters alimentam a fila de hunting do TH.x com candidatos de hipótese, a extração de TTPs nutre o PLT.2 e o processo de análise do grupo ANA.x, e a priorização de alertas otimiza os playbooks de triagem do AUT.1. O resultado de cada uso retorna como rótulo para o re-treino, e as métricas de precisão sustentam os relatórios de efetividade do grupo MET.x, fechando o ciclo entre dado, modelo e decisão humana auditável.