Detection Development Life Cycle (DDLC)

Nota da pasta de Detection-as-Code do capítulo 18, sobre Detection Engineering e Automação.
Estrutura o ciclo de vida de desenvolvimento de detecção, da ideia à deprecação, com papéis, artefatos e critérios de passagem por fase.
Dialoga com os conceitos de DaC da nota anterior, com os repositórios de regras e com a simulação de alertas da pasta de Pipeline de Detecção.

1. Contexto e Posicionamento na Biblioteca

A nota anterior justificou tratar detecção como código, e esta nota organiza o trabalho em um processo formal: o Detection Development Life Cycle, ou DDLC. O ciclo define o caminho que uma ideia de detecção percorre desde a fonte que a gerou, que pode ser um relato de inteligência, uma caça ou um incidente, até a regra desativada com justificativa registrada. Sem esse arcabouço, o catálogo cresce por acumulação sem direção, regras envelhecem sem revisão e ninguém sabe o que motivou metade das detecções em produção.

O DDLC cumpre na engenharia de detecção o papel que o ciclo de inteligência cumpre na CTI, tratado no capítulo 1 da biblioteca: uma sequência de fases com entradas, saídas e responsáveis definidos, que torna o trabalho previsível, auditável e melhorável. O ciclo não é burocracia, é o mecanismo que permite ter centenas de detecções ativas mantendo qualidade, porque cada fase filtra defeitos na etapa mais barata de corrigi-los, que é sempre a anterior ao deploy.

2. Visão Geral do Ciclo e suas Fases

O DDLC da biblioteca adota oito fases, em alinhamento com as descrições consagradas de ciclo de vida de detecção: ideação, desenho, implementação, teste, revisão, implantação, ajuste fino e deprecação. As fases formam um circuito, pois o ajuste fino em produção gera novas ideias de versões da regra, e a deprecação devolve conhecimento para a ideação. A tabela abaixo apresenta cada fase com o objetivo e a pergunta central que a fase responde.

As fases de ideação a implantação costumam levar de um a dez dias úteis em times maduros, dependendo da criticidade e da complexidade do desenho. O ajuste fino tem janela padrão de trinta dias após o deploy, com revisão obrigatória das métricas de falsos positivos ao final, e a deprecação é um evento planejado com aviso prévio, nunca a desativação silenciosa que proliferou nos catálogos de console.

3. Fontes de Ideias e Priorização

A ideação de detecção é um processo de abastecimento contínuo, não uma atividade criativa esporádica. Quatro fontes principais alimentam o fluxo, e cada uma tem características próprias de prazo e justificativa, o que exige um mecanismo único de triagem para que nenhuma ideia se perca.

• Inteligência de ameaças: relatos públicos e privados descrevem campanhas e TTPs, como o abuso de ferramentas de acesso remoto legítimas por grupos de ransomware, e cada técnica nova com telemetria disponível é um candidato a detecção. O vínculo direto com os requisitos de inteligência da organização justifica a prioridade.
• Threat Hunting: hipóteses de caça confirmadas, fruto do trabalho das notas do capítulo 7, produzem as detecções de maior qualidade do catálogo, porque o comportamento foi observado no ambiente real e a lógica já rodou em modo de busca antes de virar alerta contínuo.
• Incidentes de segurança: cada pós-mortem pergunta o que teria detectado a intrusão mais cedo, e cada resposta a essa pergunta vira uma detecção candidata com justificativa documentada pelo prejuço evitado. É a fonte com maior poder de persuasão junto à liderança.
• Análise de lacunas ATT&CK: heatmaps de cobertura, como os do grupo MAP do framework CTH, apontam técnicas críticas sem detecção alguma, e o preenchimento dessas lacunas mantém o catálogo balanceado por tática em vez de viciado em técnicas espetaculares.

A priorização combina três critérios com pesos explícitos: risco da técnica, medido por relevância das campanhas recentes para o setor e pela posição na cadeia de ataque; viabilidade de telemetria, medida pela existência real dos logs necessários no ambiente; e esforço de implementação, estimado em dias de trabalho do time de detecção. Análise de lacunas alimenta o backlog, incidentes e inteligência urgente entram com prioridade elevada por padrão, e o backlog é reordenado em cadência semanal ou quinzenal em uma reunião curta com CTI, hunting e engenharia de detecção presentes.

4. Fase de Desenho: Lógica, Fontes e Campos

O desenho é a fase de maior alavancagem do ciclo, porque um desenho ruim não é salvo por implementação caprichosa. O desenho começa pela descrição comportamental do que se quer detectar, em linguagem independente de plataforma, e prossegue para a resposta a quatro perguntas técnicas: quais fontes de log registram o comportamento, quais campos carregam o sinal, qual a lógica de seleção e quais padrões legítimos geram falsos positivos previsíveis.

A escolha da fonte de dados é a decisão mais crítica do desenho. Um comportamento como execução de comandos remotos pode aparecer no log de segurança do Windows com Event ID 4688, no Sysmon com Event ID 1, na telemetria do EDR ou no log de assinatura do serviço remoto, e cada fonte tem custo de ingestão, fidelidade e cobertura diferentes. O desenho deve verificar na prática que a fonte existe no ambiente, executando a consulta exploratória contra dados reais, pois desenhar sobre uma fonte que o controle DAT.1 ou DAT.4 da biblioteca mostra não estar habilitada é projetar detecção que nunca vai disparar.

A lógica de seleção deve ser desenhada para o comportamento, não para o IOC. Detectar o nome de domínio de um ator específico é uma detecção frágil que morre quando a infraestrutura muda, enquanto detectar o padrão de comportamento, como processo pai inválido para uma ferramenta de administração, sobrevive à troca de infraestrutura do adversário. A Pirâmide de Dor da biblioteca fundamenta essa escolha: quanto mais alto na pirâmide o artefato detectado, mais duradoura a detecção.

O desenho termina com a análise de falsos positivos prevista, listando os padrões legítimos que casam com a lógica e a estratégia para cada um, que pode ser filtro explícito, contextualização por linha de base ou classificação do alerta com contexto enriquecido. Uma regra sem análise de falsos positivos no desenho está, estatisticamente, adiando o trabalho de tuning para depois do deploy, quando o custo de corrigir é maior e a credibilidade do catálogo já sofreu.

5. Implementação, Teste e Revisão

A implementação traduz o desenho no formato do repositório, respeitando as convenções de nomenclatura, metadados e estrutura descritas na nota de repositórios em Git. Regras em Sigma são preferidas quando há múltiplas plataformas de destino, enquanto formatos nativos são aceitáveis quando a organização opera um único motor e valoriza expressividade total do dialeto. A implementação registra no arquivo os metadados de governança, como autor, data, status, mapeamento ATT&CK e referências ao desenho.

O teste combina três camadas descritas em detalhe na nota de testes automatizados: validação estrutural do arquivo, teste de lógica contra dados sintéticos que simulam o comportamento verdadeiro e teste de regressão contra amostras históricas que contêm os falsos positivos previstos no desenho. O critério de passagem é explícito: a regra dispara no evento sintético injetado, dispara na proporção esperada na janela histórica e não dispara no corpus de eventos benignos preparado para o teste.

A revisão por pares valida o que o teste não cobre, e o checklist típico do revisor inclui os itens abaixo. A revisão é o filtro de qualidade que os testes automatizados não substituem, pois avalia julgamento técnico e contexto organizacional.

• Correção da lógica em relação ao desenho, incluindo casos de borda como campos ausentes e janelas de agregação.
• Fidelidade do mapeamento ATT&CK, com a técnica correta e o nível certo de subtécnica, verificável contra a documentação pública.
• Existência e representatividade da fonte de dados no ambiente, cruzando com o inventário de telemetria.
• Precisão dos metadados de governança, pois catálogo sem dono e sem status é catálogo sem governança.
• Aderência às convenções do repositório, de nome de arquivo a padrão de descrição, mantendo o catálogo homogêneo.

6. Implantação, Ajuste Fino e Deprecação

A implantação segue o caminho por estágios da pipeline: a regra entra em ambiente de desenvolvimento ou laboratório, passa por homologação com dados reais em volume reduzido e chega à produção após a janela de observação definida no desenho. Deploy automatizado, descrito na pasta de Pipeline de Detecção, garante que a versão em produção é exatamente a versão aprovada no repositório, com registro do deploy e caminho de reversão pronto.

O ajuste fino é a fase que separa catálogos maduros de catálogos ruidosos, e funciona com métricas explícitas de observação pós-deploy: volume de alertas por dia, proporção de falsos positivos classificados na triagem, taxa de escalonamento e custo de execução da consulta no motor. Ajustes resultantes dessas métricas, como filtros de exceção documentados e mudanças de limiar, entram pelo mesmo fluxo de pull request de qualquer mudança de regra, mantendo o histórico coeso.

A deprecação é tratada como evento formal com critérios objetivos: a técnica deixou de ser relevante para o perfil de ameaça, a fonte de dados foi descontinuada, a regra acumula falsos positivos sem valor de triagem ou a regra foi substituída por versão melhor. A regra não é apagada, é marcada com status de deprecada e motivo, permanecendo consultável, e o conhecimento acumulado, como padrões de comportamento observados, migra para a nota de desenho da detecção sucessora.

7. Papéis e Responsabilidades no Ciclo

O DDLC não exige time grande, exige clareza de papéis, e em equipes pequenas uma mesma pessoa acumula papéis com transparência. A tabela abaixo define os papéis típicos com a responsabilidade central e a fase de maior atuação, em formato próximo de uma matriz RACI simplificada.

A separação mais importante é entre quem propõe e quem revisa: o autor da regra não aprova a própria regra, mesmo em times de duas pessoas, pois a revisão independente é o que garante que a lógica foi compreendida por outra pessoa. O dono do catálogo é um papel atribuível a alguém, nunca vago, porque métricas sem dono não são acompanhadas e deprecação sem dono simplesmente não acontece.

8. Artefatos por Fase do Ciclo

Cada fase produz artefatos concretos que sustentam a rastreabilidade do ciclo, e a tabela abaixo consolida o conjunto. Esses artefatos são a matéria-prima das auditorias de detecção e do treinamento de novos membros do time, que estudam casos reais percorrendo o rastro de artefatos de uma regra antiga.

9. Template de Documento de Desenho de Detecção

O template abaixo é o produto prático desta nota e deve ser preenchido antes da implementação de qualquer regra de criticidade média ou alta. Copiado para a pasta da regra, ele mantém o raciocínio do desenho junto ao código, e o revisor lê o desenho antes de julgar a lógica implementada.

# Desenho de Detecção: <nome da regra>

## Objetivo
Comportamento a detectar, em uma frase comportamental, sem nome de ferramenta.

## Origem e Justificativa
Fonte da ideia (intel, hunt, incidente, lacuna) e referência ou ticket.

## Mapeamento ATT&CK
Tática e técnica com subtécnica, por exemplo Execution, T1059.001.

## Fontes de Dados
Fonte primária e fontes alternativas, com verificação de habilitação
no ambiente e referência ao inventário de telemetria.

## Lógica de Detecção
Descrição da seleção: campos, condições, agregações e janela de tempo.
Consulta de referência ou expressão Sigma quando já rascunhada.

## Falsos Positivos Previstos
Lista de padrões legítimos esperados e estratégia para cada um:
filtro, baseline ou contexto no alerta.

## Plano de Teste
Evento sintético a injetar, corpus de regressão a usar e critérios
de passagem com números esperados.

## Plano de Rollout e Rollback
Estágios de implantação, janela de observação em cada estágio e
condição e comando de reversão.

## Métricas de Ajuste Fino
Volume esperado de alertas, limite aceitável de falsos positivos e
data da revisão de 30 dias.

O template é deliberadamente curto, com nove campos que um engenheiro experiente preenche em trinta minutos para uma regra comum, e o custo é pago com juros no tuning evitado. Regras de nível informativo podem dispensar o documento completo, mas a dispensa deve ser uma exceção registrada, não uma rota de fuga permanente.

10. Erros Comuns e Pontos de Atenção

• Pular o desenho para regras urgentes: pressa de incidente cria regra sem análise de falsos positivos, e o alerta em massa na semana seguinte custa mais que o tempo economizado. Urgência acelera o ciclo, não elimina fases.
• Backlog que só cresce: ideação sem mecanismo de priorização acumula centenas de itens, e o time para de olhar a lista. Cadência de triagem com corte periódico de itens vencidos mantém o backlog crível.
• Mapeamento ATT&CK decorativo: colocar a técnica que soa bem sem verificar a descrição oficial produz heatmaps de cobertura mentirosos, que derrubam a confiança no catálogo quando a simulação comprova a lacuna.
• Teste apenas sintético: dado sintético prova a lógica, não a operação, porque dados reais trazem volume, campo vazio e encoding que o sintético não reproduz. Combinar as duas camadas é obrigação, não luxo.
• Tuning como castigo silencioso: ajustes pós-deploy feitos direto no console sabotam o histórico do repositório, e o catálogo volta a derivar da fonte da verdade. Todo ajuste é pull request, sem exceção.
• Deprecação procrastinada: sem dono do catálogo e cadência trimestral, a desativação nunca acontece e o custo de execução e o ruído crescem sem contrapartida de valor.

11. Integração com o Restante da Biblioteca

O fluxo de ideação desta nota se conecta com o capítulo 7 de processos de hunting, cuja documentação de descobertas alimenta diretamente o backlog de detecção, e com o ciclo de inteligência do capítulo 1, cujo feedback loop devolve aos analistas de CTI a informação de quais detecções realmente valeram. A nota de repositórios em Git detalha a estrutura e as convenções usadas nas fases de implementação e revisão, e a nota de testes automatizados aprofunda a fase de teste com exemplos de pipeline.

Na pasta de Pipeline de Detecção, o deploy com Terraform e GitHub Actions opera as fases de implantação aqui descritas, e a simulação de alertas com inputs controlados fornece a verificação ponta a ponta que o plano de teste do desenho promete. No framework CTH, o controle AUT.3 consagra a automação de detecção que o DDLC operacionaliza, o controle SIM.4 sobre teste de detecção fornece os insumos de validação, e a nota de KPIs de CTI do capítulo 11 usa os artefatos de métricas de ajuste fino como fonte de indicadores de qualidade do programa.