Conceitos e Benefícios do DaC

Nota de abertura da pasta de Detection-as-Code do capítulo 18, dedicado a Detection Engineering e Automação.
Define detecção como código, apresenta os princípios de engenharia de software aplicados a regras de detecção e os benefícios mensuráveis dessa abordagem.
Dialoga com o ciclo de vida de detecção da nota seguinte, com a conversão de Sigma na pasta de Pipeline de Detecção e com o controle DAT.4 do framework CTH.

1. Contexto e Posicionamento na Biblioteca

As notas anteriores da biblioteca trataram da produção de inteligência e da formulação de hipóteses de caça, e esta nota marca a transição para a engenharia de detecção: o momento em que o conhecimento sobre o adversário se materializa em regras que operam continuamente nos controles da organização. Detection-as-Code, ou DaC, é a prática de tratar cada regra de detecção como um artefato de software, com versionamento em Git, revisão por pares, testes automatizados e implantação controlada por pipeline. A prática nasce de um problema crônico dos SOC: catálogos de regras criados diretamente no console do SIEM, sem histórico, sem dono claro e sem possibilidade de reprodução em outro ambiente.

O papel da nota é estabelecer o vocabulário e a justificativa para todo o restante do capítulo. As notas de DDLC, repositórios Git, testes e CI/CD e a pasta de Pipeline de Detecção assumem que o leitor aceitou a premissa central: regra de detecção é código, e o ciclo de vida dela deve seguir as práticas consolidadas de engenharia de software. A leitura anterior do controle DAT.4, sobre ingestão e centralização de logs, fornece a base de telemetria sobre a qual o DaC opera, e a nota de simulação de alertas fecha o circuito com a validação ponta a ponta.

2. O que é Detecção como Código

Detecção como código é o princípio segundo o qual a fonte da verdade do catálogo de detecções é um repositório versionado, e não o console do SIEM ou do EDR. A regra nasce em um arquivo de texto, em formato como Sigma, YAML nativo da plataforma ou TOML, passa por revisão em pull request, é validada por testes automatizados e chega ao ambiente de execução por deploy conduzido por pipeline. O console deixa de ser ferramenta de criação e passa a ser apenas a superfície de operação, onde se observa o comportamento das regras implantadas.

A analogia direta é com a gestão de código de aplicação: ninguém mantém o código-fonte de um sistema crítico editando arquivos diretamente em produção, e o mesmo raciocínio se aplica às detecções. Cada mudança de regra é uma mudança de comportamento do sistema de defesa, com potencial de gerar alertas em massa, derrubar cobertura de técnicas ATT&CK ou consumir capacidade de triagem. Tratar a regra como código torna essa mudança visível, avaliável e reversível antes que atinja produção.

O exemplo abaixo mostra uma detecção no formato Sigma, que é o formato mais portátil para começar um repositório de DaC, pois permite conversão para as linguagens nativas de cada plataforma. O arquivo carrega metadados de governança, lógica de detecção e referência ATT&CK no mesmo documento.

title: PowerShell com Download Cradle Suspeito
id: 8a3c1d2e-4b5f-6c7d-8e9f-0a1b2c3d4e5f
status: stable
description: Detecta download de conteúdo remoto via PowerShell com
  padrões de cradle usados em intrusões, incluindo IEX e WebClient.
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: equipe de detection engineering
date: 2024/03/11
modified: 2025/01/20
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  service: powershell
detection:
  selection_script:
    ScriptBlockText|contains|all:
      - 'DownloadString'
      - 'IEX'
  condition: selection_script
falsepositives:
  - Scripts de administração legítimos com download e execução
level: high

3. Princípios Fundamentais do DaC

Quatro princípios constituem o núcleo da prática, e cada um resolve um modo de falha específico do modelo de regras no console. Eles não são opcionais nem independentes entre si: versionamento sem revisão produz histórico de erros, revisão sem testes produz julgamento sem evidência, e tudo isso sem deploy automatizado se degrada em processo manual que não escala.

• Versionamento em Git: toda regra vive em um repositório com histórico completo de criação e alterações, e comandos como git blame e git log respondem quem mudou o quê, quando e por qual motivo. O histórico é infraestrutura de investigação, pois ao auditar um alerta antigo é possível recuperar a versão exata da regra vigente naquele dia.
• Revisão por pares: nenhuma regra entra na branch principal sem aprovação de outro engenheiro, que avalia lógica, viés de falsos positivos, disponibilidade de telemetria e mapeamento ATT&CK. A revisão distribui conhecimento sobre o catálogo, reduz o risco de ônibus com detecções que só uma pessoa entende.
• Testes automatizados: a pipeline executa validação de esquema, checagens de lint e, idealmente, testes contra dados sintéticos ou amostras de log históricas. Teste automatizado transforma a qualidade da regra de uma opinião do revisor em uma verificação repetível a cada mudança.
• Deploy automatizado: a pipeline publica as detecções nos ambientes por estágio, de desenvolvimento para produção, sem intervenção manual no console. Deploy automatizado elimina a deriva entre repositório e plataforma, pois a plataforma é sempre o destino de uma versão declarada no Git.

A combinação dos quatro princípios produz o que engenharia de software chama de caminho de mudança único: existe um único modo aprovado de alterar o catálogo, e qualquer alteração fora dele é, por definição, incidente de processo. Esse caminho único é o que permite confiar nas métricas do catálogo, como cobertura por tática e volume de falsos positivos, porque se sabe exatamente qual versão de cada regra está em execução.

4. Diferença para Regras Criadas no Console

Comparar os dois modos de trabalho de forma explícita ajuda a justificar o investimento em DaC junto à liderança. O modelo do console não é totalmente inútil, pois serve para prototipagem rápida durante uma investigação ou uma caça, mas o protótipo criado ali precisa migrar para o repositório antes de ser considerado produção. A tabela abaixo contrasta as características operacionais dos dois modelos.

O ponto mais grave do modelo de console é a deriva silenciosa: alguém ajusta um limiar no console durante um incidente às duas da manhã, ninguém documenta, e três meses depois o catálogo oficial e a plataforma divergem sem que ninguém perceba. Com DaC, esse ajuste vira commit com mensagem explicando o incidente, revisão posterior e revert planejado quando a condição que motivou o ajuste terminar. A deriva não é eliminada pelo comportamento humano, é eliminada pela impossibilidade material de alterar produção fora do pipeline.

5. Analogia com o Desenvolvimento de Software

A maturidade do DaC pode ser descrita emprestando conceitos consagrados de engenharia de software, e essa tradução é útil para conversar com times de plataforma que já vivem esses conceitos. A regra de detecção equivale a uma função pura com efeitos observáveis: recebe telemetria como entrada, devolve alertas como saída, e a qualidade da saída depende da lógica e da qualidade dos dados. Dívida técnica aparece em detecção na forma de regras legadas sem dono, consultas caras que degradam o SIEM e falsos positivos tolerados por falta de tempo, exatamente como a dívida aparece em software.

• Código legado e refatoração: regras antigas merecem refatoração periódica, trocando campos descontinuados, migrando para o formato corrente e revalidando falsos positivos, sob pena de o catálogo envelhecer em silêncio.
• Documentação como parte do código: a descrição, as fontes de falsos positivos e o mapeamento ATT&CK são a documentação viva da regra, e a revisão por pares recusa regra sem esses campos preenchidos.
• Depuração e observabilidade: quando um alerta dispara de forma inesperada, o engenheiro consulta a versão da regra no repositório, roda a lógica contra a amostra de evento original e reproduz o comportamento, como faria com uma falha de software.
• Liberação contínua: o fluxo da regra, da ideia ao alerta em produção, é um pipeline, e otimizar esse pipeline, reduzindo o tempo entre merge e deploy, reduz diretamente o tempo de exposição a uma nova técnica do adversário.

A analogia tem um limite que vale registrar: software errado geralmente falha de forma visível, enquanto detecção errada falha em silêncio, deixando de alertar sobre um comportamento real. Por isso os testes de detecção têm peso maior que no software convencional, e a nota de simulação de alertas deste capítulo trata da verificação ponta a ponta que comprova que a regra não apenas roda, mas dispara quando o comportamento simulado acontece.

O fluxo típico de alteração de uma regra mostra a analogia em operação, com os mesmos passos que um time de software executaria ao corrigir uma falha. O trecho abaixo resume esse fluxo com os comandos e as checagens envolvidas, do problema detectado até o revert quando a condição que motivou a mudança termina.

Fluxo de alteração de uma regra existente
1. Triagem aponta falsos positivos da regra web_rce_001 em 4% dos alertas.
2. Engenheiro abre branch: git checkout -b tune/web-rce-001-fp
3. Edita o YAML, adiciona filtro de user-agent de scanner conhecido e
   registra o ajuste no campo modified e no falsepositives.
4. Abre pull request; pipeline roda lint, validação de esquema e teste
   contra amostra histórica, reportando a nova taxa de disparo.
5. Revisor aprova com base nos números; merge na branch principal.
6. Pipeline implanta a versão ajustada em produção e registra no deploy log.
7. Após 30 dias, a métrica de falsos positivos cai para 0,3% e o ajuste
   permanece; caso a condição fosse temporária, seria git revert + deploy.

Esse fluxo de sete passos substitui a edição silenciosa no console por uma sequência auditável, e cada passo gera um artefato: a branch, o diff da revisão, os resultados da pipeline, o registro de deploy e a medição pós-implantação. Em auditoria ou na reconstituição de um incidente, essa trilha responde em minutos perguntas que no modelo de console exigiriam semanas de escavação em logs da plataforma, se é que a plataforma sequer guarda esse histórico.

6. Tabela de Práticas e Benefícios Correspondentes

A tabela abaixo consolida a relação entre cada prática do DaC e o benefício concreto que ela entrega, com o indicador típico usado para verificar se o benefício está sendo colhido. Essa estrutura é a base de um caso de negócio para o programa de detecção como código.

Rastreabilidade, reprodutibilidade e escala formam a tríade de benefícios que aparece em qualquer justificativa madura de DaC, e cada item da tabela alimenta uma dessas três frentes. A rastreabilidade sustenta investigação e conformidade, a reprodutibilidade sustenta confiança nas detecções durante mudanças, e a escala sustenta o crescimento do catálogo de dezenas para milhares de regras sem crescimento proporcional do esforço manual.

7. Caminho de Adoção Progressivo

Organizações não migram do console para o DaC completo em um único projeto, e tentar fazer isso é a receita mais comum de abandono da iniciativa. O caminho recomendado é progressivo, com cada estágio entregando valor próprio e preparando o seguinte, e a tabela abaixo descreve os estágios típicos com o resultado que autoriza avançar. O tempo real de cada estágio depende do tamanho do catálogo e da maturidade do time, mas a sequência tem se mostrado estável em diferentes ambientes.

O estágio 1 merece atenção especial porque costuma revelar o tamanho real do problema: inventários de consoles maduros trazem centenas de regras desabilitadas, duplicadas ou sem descrição, e essa limpeza inicial já entrega ganho de qualidade perceptível. Regras sem dono e sem justificativa são candidatas à desativação após análise, e o catálogo entra no DaC já menor e mais confiável do que saiu do console.

O estágio 5 é o ponto de não retorno da prática, porque a partir dele o console perde o papel de ferramenta de escrita e qualquer alteração manual fica visível como violação de processo. Alguns ambientes regulados exigem janela de mudança formal mesmo para detecções, e nesse caso a pipeline passa a agendar o deploy nas janelas aprovadas, mantendo o caminho único de mudança dentro da conformidade em vez de competir com ela.

8. Erros Comuns e Pontos de Atenção

• Adotar Git sem adotar pipeline: o repositório vira um anexo morto, com produção divergindo em semanas, porque o console continua sendo o caminho real de mudança. O deploy automatizado é o componente que dá força ao versionamento.
• Protótipo eterno no console: a regra criada durante a caça funciona e nunca migra para o repositório, virando sombra invisível no inventário. Definir prazo de migração, por exemplo cinco dias úteis, e tratar o descumprimento como dívida visível.
• Revisão burocrática: exigir dois aprovadores e checklist extenso para toda regra transforma a pipeline em gargalo, e o time volta para o console por pragmatismo. Calibrar o rigor por criticidade, com revisão simples para regras de nível baixo e revisão aprofundada para regras críticas.
• Copiar práticas de software sem adaptar: branch por funcionalidade com ciclo de release mensal não faz sentido para detecção, onde o prazo relevante é de horas. Adotar trunk-based com deploy contínuo, exceto quando o ambiente exige janela de mudança formal.
• Medir a adoção por número de regras: milhares de regras ruidosas provam que o pipeline funciona e que o programa falhou, porque volume sem precisão degrada a triagem. A métrica de sucesso é cobertura verificada de técnicas com falsos positivos sob controle.

O ponto de atenção que mais frequentemente decide o sucesso do programa é o acordo entre times: o DaC exige que analistas que nunca programaram aprendam Git e Markdown, e o time de plataforma precisa aceitar que detecção tem urgência própria e cadência de mudança própria. Investir em treinamento nas duas direções, com repositório de exemplo e mentoria, reduz o tempo de adoção de meses para semanas.

Um erro de planejamento que merece destaque é começar pelo formato: times passam semanas debatendo Sigma contra YAML nativo contra formato proprietário antes de ter qualquer regra versionada. O debate correto acontece depois da prática instalada, com critérios objetivos como o número de plataformas de destino, a existência de pipeline de conversão e a disponibilidade de ferramentas de validação para cada formato. Começar com o formato que o time já sabe usar e refatorar depois custa menos que a paralisação por decisão.

9. Integração com o Restante da Biblioteca

A nota seguinte, sobre o Detection Development Life Cycle, organiza as práticas aqui apresentadas em um ciclo de vida com fases, papéis e artefatos, e é o mapa operacional do que esta nota justificou. A nota de repositórios em Git mostra como os repositórios públicos da Elastic, do Wazuh e do Sigma HQ implementam os princípios desta nota em escala real, servindo de referência de arquitetura para o repositório interno da organização.

Na pasta de Pipeline de Detecção, a conversão de Sigma para linguagens nativas materializa a portabilidade citada na tabela de práticas, o deploy com Terraform e GitHub Actions materializa o deploy automatizado e a simulação de alertas com inputs controlados fecha o ciclo com a verificação ponta a ponta. No restante da biblioteca, o controle AUT.3 sobre automação de detecção do framework CTH é o controle correspondente a esta prática, o controle SIM.5 sobre medição de cobertura de detecção fornece as métricas que provam os benefícios, e a nota de sobrecarga de alertas do capítulo 12 descreve o problema de falsos positivos que o DaC ataca na origem, com revisão e teste antes do deploy.