AUT.3 - Automação de Detecção

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.3, com os subcontroles AUT.3.1 a AUT.3.5.
Define a detecção como código: regras Sigma, YARA e de rede tratadas como artefatos de software, versionadas, testadas e implantadas por pipeline de CI/CD do repositório à produção.

1. Contexto e Posicionamento no Framework CTH

A detecção automatizada amplia o alcance da equipe de segurança além do que é possível com análise manual. Hipóteses de hunting validadas devem se converter em regras que operam continuamente, reduzindo a janela de detecção de dias ou semanas para minutos. Cada hipótese confirmada como verdadeiro positivo é candidata a se tornar uma regra permanente, o que multiplica o impacto de cada hunt ao longo de todo o ano.

No Framework CTH, o AUT.3 é a ponte industrial entre o trabalho analítico do hunting, governado pelos controles TH.x, e a operação contínua do SOC. O controle depende da telemetria do grupo DAT, porque regra sem fonte de dados estável é promessa não cumprida, e conversa com o PRT.5, que cobre as regras personalizadas nos controles de proteção. As salvaguardas por nível evoluem da conversão manual de regras Sigma até o pipeline de CI/CD com testes automáticos, staging e promoção controlada.

2. Detecção como Código

Detecção como código é o princípio de tratar cada regra como artefato de software, com versão, autor, testes e ciclo de vida gerenciado. A regra vive em repositório Git, muda por pull request, é validada automaticamente e chega à produção por pipeline, e não por colagem manual no console do SIEM. Esse princípio entrega quatro ganhos concretos: trilha de auditoria de cada mudança, reprodutibilidade do ambiente de detecção, rollback trivial e escala do catálogo sem aumento proporcional de erro humano.

O formato Sigma funciona como linguagem intermediária neutra, escrita uma única vez e convertida para a linguagem nativa de cada destino: consultas do SIEM em KQL, SPL ou EQL, regras do EDR, assinaturas YARA para varredura de arquivos e memória, e regras de rede para o sistema de detecção de intrusão. A conversão elimina o lock-in de fornecedor e permite que o mesmo comportamento, como T1059.001 com parâmetros codificados, seja detectado em todas as camadas a partir de uma única definição. A calibração contra falsos positivos continua sendo trabalho analítico, e a automação apenas garante que a calibração seja aplicada de forma consistente.

A estrutura física do repositório materializa o princípio e deve ser simples o suficiente para caber em uma página. Convenções de diretório por fonte de log e por tipo de artefato aceleram a navegação e a revisão, e o versionamento de datasets junto às regras garante que teste e código evoluam no mesmo commit. O esqueleto abaixo é um ponto de partida testado em times de médio porte.

Estrutura de repositório sugerida para detecção como código
rules/
  windows/process_creation/     regras Sigma por fonte de log
  windows/registry/             regras Sigma por fonte de log
  network/                      regras de rede (Suricata ou derivadas)
  file/yara/                    assinaturas YARA para arquivos e memória
datasets/
  golden/                       amostras rotuladas por técnica ATT&CK
  benigno/                      ruído conhecido do ambiente para medir FP
catalogo/
  DET-0001.yml                  metadados por detecção
ci/
  lint.yml                      validação de schema e metadados
  test.yml                      execução contra golden datasets
  convert.yml                   conversão pySigma para os backends
  deploy_staging.yml            implantação em homologação e promoção

3. Pipeline de Regras de Ponta a Ponta

O pipeline de detecção formaliza as etapas pelas quais toda regra passa, do rascunho ao monitoramento em produção. A tabela abaixo descreve cada etapa, com a ferramenta típica de execução, e serve como checklist de maturidade do time.

Nenhuma etapa da tabela é dispensável, embora possam começar semiautomáticas com execução por script. O erro mais custoso é pular o teste de dados, pois regra sem teste enche o SIEM de ruído até ser desligada, queimando a confiança do SOC no catálogo inteiro. O pipeline existe para tornar o caminho correto o caminho fácil.

4. Exemplo de Fluxo de CI para uma Regra Sigma

O roteiro abaixo percorre o ciclo completo de uma regra, desde o pull request até o monitoramento pós-deploy. Ele é executado por CI, com intervenção humana concentrada na revisão analítica.

Ciclo de vida de uma regra Sigma no pipeline
1. Analista abre pull request com
   rules/windows/process_creation/win_susp_encoded_powershell.yml
2. Job lint: valida schema Sigma, campos obrigatórios
   (title, id, logsource, detection, tags ATT&CK, tlp)
   e rejeita ID duplicado no catálogo
3. Job test: executa a regra contra dataset de validação com
   10 amostras rotuladas de T1059.001 e 200 amostras benignas
   critério: >= 9 acertos em 10 e 0 falso positivo conhecido
4. Job build: pySigma converte a regra para KQL e para a regra do EDR
5. Job staging: implanta em homologação e roda contra 30 dias de dados
   históricos, medindo volume de disparos por dia
6. Revisão por pares: aprovação de um segundo analista e do dono do
   catálogo, com conferência do mapeamento ATT&CK
7. Merge e deploy: pipeline promove para produção e registra versão,
   autor e data no catálogo de detecções
8. Monitoramento: painel acompanha disparos diários por regra; salto
   anômalo de volume abre chamado no próprio pipeline
Rollback: git revert do commit e reexecução do pipeline reimplanta a
   versão anterior em minutos, sem contato manual com o SIEM

O passo 3 merece investimento prioritário, porque o dataset de validação é ativo de longo prazo que serve a todas as regras futuras. Times que mantêm golden datasets por técnica ATT&CK convertem cada incidente real em amostra nova, melhorando continuamente o poder discriminativo da suíte. Sem esse ativo, o teste de dados degrada para execução curiosa sem critério.

5. Testes de Regressão de Detecção

Mudanças no ambiente de coleta podem matar regras silenciosamente, e por isso o pipeline precisa de testes de regressão agendados, além dos testes de entrada. Eventos que disparam a suíte de regressão incluem upgrade de versão do SIEM, mudança de fonte de log com novos campos, migração de esquema como a adoção de ECS ou OCSF, atualização do backend de conversão e alteração no formato de telemetria do endpoint. Em cada um desses casos, o comportamento esperado é reexecutar a suíte completa contra os golden datasets e comparar os disparos com a linha de base registrada.

A comparação busca dois sintomas opostos, ambos graves. Regra que para de disparar indica detecção morta, muitas vezes por campo renomeado ou log que deixou de ser coletado, e precisa de correção imediata. Regra que explode em disparos indica mudança semântica de campo que multiplicou falsos positivos, e entra em revisão antes de inundar a fila do SOC. Registrar a linha de base de disparos por regra em cada release transforma a regressão de surpresa em verificação rotineira.

Mantenha os golden datasets como código revisado, com rótulos justificados em comentários, porque dataset sem dono degrada junto com as regras. Cada incidente confirmado deve gerar amostra nova no dataset, convertendo o adversário em fonte involuntária de melhoria da suíte. Esse hábito, mais que qualquer ferramenta, é o que preserva o poder discriminativo dos testes ao longo dos anos.

6. Catálogo de Detecções e Metadados

O catálogo é o registro central de todas as detecções, com metadados que permitem responder rapidamente às perguntas rotineiras do programa: quem escreveu, contra qual técnica, com qual fonte de dados, em qual status e com qual sensibilidade de compartilhamento. Sem catálogo, o time perde horas redescobrindo regras existentes e duplica esforço. O exemplo abaixo mostra o registro YAML que acompanha cada regra no repositório.

id: DET-0142
title: PowerShell com comando codificado em linha de processo
format: sigma
technique: T1059.001
data_source: Sysmon EventID 1 e Windows EventID 4688
author: equipe de hunting
status: produção
tlp: amber
created: 2024-05-12
last_review: 2025-01-20
false_positive_rate: 0.4
test_dataset: golden/T1059.001_encoded.yaml
notes: gerada da hipótese HNT-2024-07, calibrada com dois ciclos de ajuste

Metadados são documentação viva, e por isso o lint do pipeline valida a presença e a atualidade de cada campo. A regra prática é que nenhum artefato entra em produção sem id, técnica ATT&CK, fonte de dados, TLP e status, pois esses cinco campos sustentam a cobertura reportada na métrica do pipeline e a decisão de compartilhamento conforme o TLP 2.0. O status deve transitar por valores conhecidos, como candidata, homologação, produção e aposentada, com aposentada preservando o histórico em vez de apagar a regra.

7. Do Hunting à Detecção Permanente

A relação entre hunting e automação de detecção é o coração do valor do programa. O hunting gera a candidata: hipótese investigada, confirmada como verdadeiro positivo e documentada com o comportamento observado. O pipeline promove a candidata: converte a consulta do analista em Sigma, aplica os testes e implanta. A partir daí, o que era descoberta pontual vira cobertura contínua, liberando o hunter para perseguir o próximo comportamento.

A promoção, porém, tem critérios, e não é automática por decisão de status. Exige verdadeiro positivo confirmado, taxa de falso positivo medida e aceitável, fonte de dados estável no ambiente e valor defensivo real, isto é, o comportamento detectado deve ser relevante para o adversário que importa para o negócio. Regras para amostras isoladas de laboratório ou para fontes que serão descontinuadas viram achados documentados, e não detecções. O ciclo se fecha quando o feedback de falsos positivos do SOC retorna ao autor, gerando ajuste e novo ciclo de testes.

8. Métricas do Pipeline

O lead time é a métrica que resume o pipeline, porque mede a velocidade com que o conhecimento analítico se torna proteção operacional. Times que começam costumam registrar semanas e chegam a dias com a automação consolidada. A cobertura ATT&CK não deve ser perseguida como número absoluto, mas como mapas vivos priorizados pelo perfil de ameaça definido no CTI.5.

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

A sequência é deliberada: primeiro qualidade de regra individual, depois varredura de artefatos, depois correlação comportamental, e só então industrialização. Implementar o nível avançado sobre catálogo imaturo apenas automatiza a má qualidade. Cada nível entregue deve aumentar a confiança do SOC no catálogo, e não apenas o número de regras.

10. Erros Comuns e Pontos de Atenção

• Regra sem teste que dispara milhares de vezes por dia: a solução improvisada é desligá-la, e o custo real é a confiança perdida no catálogo; exija teste antes do merge.
• Conversão sem validação semântica: sintaxe convertida não garante comportamento equivalente entre backends; valide a regra convertida contra o dataset em cada destino.
• Catálogo sem metadados: regras sem autor, técnica e fonte viram legado impossível de manter; trate o lint de metadados como porta de entrada.
• Deploy direto em produção: pular staging elimina a chance de medir volume e performance; a economia de um passo gera incidente de ruído depois.
• Regras órfãs: autor saiu e ninguém mantém a regra; o dono do catálogo assume a revisão e a aposentadoria formal.
• Ignorar o decaimento: fontes de dados mudam e regras param de disparar sem aviso; a suíte de regressão agendada é o antídoto.
• Perseguir número de regras: catálogo inchado de regras redundantes dilui atenção do analista; priorize cobertura de comportamento com baixo falso positivo.

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

O AUT.3 recebe candidatas dos controles TH.x, que documentam as hipóteses validadas, e do AUT.1, cujos playbooks de triagem sinalizam padrões recorrentes. As regras produzidas alimentam o SOC por meio das fontes consolidadas no DAT.4 e se apoiam nas regras personalizadas do PRT.5 nas camadas de endpoint, rede e arquivos. O ciclo de validação contínua conversa com o grupo SIM.x, cujas simulações geram amostras novas para os golden datasets, e as métricas de cobertura sustentam os relatórios de situação e o planejamento de detecção do programa de CTI.