Alerting and Detection Strategy (ADS) Framework

Nota do Capítulo 18, pasta de Frameworks de Detecção.
Apresenta o framework ADS, criado e popularizado pela Palantir, que transforma cada detecção em um documento estruturado com objetivo, detalhes técnicos, cenário pretendido, blind spots, prioridade e critérios de invalidação.
Dialoga com as métricas de qualidade desta pasta, com a nota de Detection as Code e com a Hunting-to-Detection Bridge, que usa a ADS como destino padrão de promoções.

1. Contexto e Posicionamento na Biblioteca

As notas da pasta anterior mediram a qualidade das detecções, e esta pasta trata dos frameworks que organizam o trabalho de criá-las. O Alerting and Detection Strategy, ADS, é o framework de referência para documentar detecções, publicado pela equipe de segurança da Palantir e adotado de forma ampla pela comunidade de detection engineering. A ideia central é radical na simplicidade: uma detecção não é uma consulta, e sim um documento vivo que explica o que a regra observa, por que existe, onde falha e como se aposenta, com a consulta sendo apenas um dos campos.

O posicionamento na biblioteca é o de contrato entre todas as funções que tocam a detecção. O engenheiro de detecção escreve a ADS e declara a intenção, o analista de triagem lê a intenção para contextualizar o alerta, o time de resposta usa os blind spots para saber onde olhar quando a detecção cala, o purple team usa o cenário pretendido para emular a técnica certa e a gestão usa a prioridade para discutir investimento. Sem esse contrato, o conhecimento de cada regra vive na cabeça do autor e se aposenta com ele.

Na esteira do capítulo, a ADS é o artefato que conecta as duas pastas vizinhas. As métricas de qualidade medem a detecção de fora, e a ADS registra a detecção de dentro, com o histórico de decisões. A Hunting-to-Detection Bridge adota a ADS como destino obrigatório de toda promoção de caça, garantindo que o conhecimento acumulado na investigação não se perda na conversão para regra. A nota a seguir estrutura o documento, justifica a prática, mostra um exemplo preenchido e descreve o ciclo de vida.

2. O Framework ADS e Sua Filosofia

O ADS nasceu da observação de que alertas criados às pressas envelhecem mal e morrem mal compreendidos. Quando o único artefato de uma detecção é a consulta no SIEM, ninguém sabe meses depois qual era a intenção, por que certas exclusões existem, quais falsos positivos já foram considerados e qual era o cenário de ataque previsto. O framework responde com um documento padrão, versionado no controle de código junto com a consulta, de modo que cada mudança de detecção carrega a explicação da mudança no mesmo commit.

A filosofia do framework tem três princípios que valem ser explicitados porque orientam todas as decisões de preenchimento. Primeiro, a detecção é um produto com ciclo de vida, e não um script solto, então o documento precisa cobrir do nascimento à aposentadoria. Segundo, a intenção é informação crítica, e não ornamento, porque a triagem decide severidade comparando o que aconteceu com o que a regra pretendia observar. Terceiro, os limites são tão valiosos quanto a capacidade, e campos como blind spots e invalidação protegem o programa contra falsa sensação de cobertura.

Duas consequências práticas se derivam dos princípios. A ADS é escrita antes ou junto da consulta, e nunca depois, porque documentar depois vira transcrição de código, e transcrição não revela intenção. E a ADS é revisada por outra pessoa que não o autor, preferencialmente um analista sênior e um engenheiro, porque o documento tem dois públicos de verdade, o time que opera e o time que planeja, e a revisão cruzada é o teste de que ambos entendem.

A variedade de campos da ADS às vezes intimida times no começo da adoção, e a resistência quase sempre vem de confundir o documento com burocracia de auditoria. O argumento que costuma destravar a adoção é operacional: a ADS substitui a reunião de alinhamento sobre a regra, o e-mail de contexto e a memória do autor, e o custo de preenchimento é pago uma vez, enquanto o benefício é cobrado a cada alerta. Times que medem o tempo de triagem antes e depois da adoção raramente voltam atrás.

3. A Estrutura do Documento

O documento ADS completo tem campos fixos, e a tabela a seguir descreve cada um com o seu propósito operacional. Times em início de adoção podem começar com um subconjunto, mas os campos de objetivo, cenário pretendido, blind spots e invalidação não são negociáveis, porque são exatamente os que nunca podem ser recuperados a partir do código da consulta.

A lógica dos campos segue a vida do alerta. Na triagem, o analista consome objetivo, detalhes técnicos e falsos positivos para decidir rápido e com contexto. Na investigação, blind spots orientam o que procurar além do alerta, transformando o documento em insumo de resposta a incidentes. Na governança, prioridade sustenta a discussão de investimento e invalidação força revisões periódicas, evitando o zoológico de regras antigas que ninguém tem coragem de apagar nem confiança de manter.

Um detalhe de implantação poupa trabalho futuro: os campos de metadados técnicos, prioridade, mapeamento ATT&CK e autoria devem ser legíveis por máquina, preferencialmente no mesmo formato estruturado da regra, com o texto da ADS referenciando os IDs. Assim o catálogo, as métricas da pasta anterior e as camadas de Navigator são gerados automaticamente a partir do que a ADS já declara, sem digitação duplicada, que é a principal fonte de dessincronização entre documento e regra.

A ordem dos campos no documento também comunica prioridade de leitura. Objetivo e cenário pretendido vêm primeiro porque são os campos do triador sob pressão, detalhes técnicos vêm depois porque servem à investigação, e manutenção fecha porque interessa a poucos. Documentos que abrem com a condição da consulta forçam o leitor a extrair a intenção do código invertido, e é exatamente esse esforço que o framework existe para eliminar.

4. Por que Documentar a Detecção Importa

O primeiro benefício é a triagem mais rápida e melhor, e é também o mais mensurável. Um alerta chega com a ADS anexada e o analista sabe em trinta segundos o que a regra pretendia observar, quais falsos positivos são conhecidos e qual a severidade acordada, em vez de reconstruir a intenção pela linha de comando da consulta. Em times com rotatividade, o documento é o mecanismo que impede o conhecimento operacional de evaporar a cada troca de plantão, e a qualidade da triagem deixa de depender de quem está de escala.

O segundo benefício aparece nos incidentes, quando a detecção é o ponto de partida da investigação. Blind spots documentados dizem à resposta onde a regra é cega, e a investigação compensa as lacunas conhecidas em vez de descobri-las sob pressão. O histórico de mudanças da ADS também funciona como trilha de auditoria, explicando por que uma exclusão foi inserida após um incidente anterior e até quando ela vale, informação que evita tanto a repetição de erros quanto a remoção prematura de salvaguardas.

O terceiro benefício é de governança e planejamento, e é o que interessa à gestão. Com todas as detecções em formato ADS, o catálogo se torna consultável por objetivo, prioridade e cenário, permitindo responder perguntas que nenhum painel de SIEM responde: quantas detecções cobrem exfiltração, qual é a prioridade média da fila, quantas regras foram invalidadas no ano e por quê. É a partir dessa visão que o programa de detecção conversa com orçamento, e não a partir de contagem bruta de regras.

No incidente, a ADS responde a quatro perguntas que nenhum outro artefato responde com confiabilidade.

• O que a regra observava, para que a investigação saiba qual comportamento foi detectado e qual é o recorte do alerta.
• O que a regra não vê, para que a resposta compense os blind spots conhecidos em vez de descobri-los em tempo real.
• O que já foi considerado ruído, para que o time não gaste horas refazendo o tuning que já existe.
• Quem decide sobre mudanças na detecção, para que ajustes urgentes sigam o caminho de governança mesmo sob pressão.

5. Exemplo de ADS Preenchida

O exemplo a seguir mostra uma ADS completa para a técnica de dump de LSASS via comsvcs.dll, em formato de documento versionado junto com a regra no repositório. O texto condensa em campos o que normalmente estaria espalhado entre a cabeça do autor, comentários na consulta e um e-mail esquecido, e o formato é deliberadamente legível por humanos, com os metadados estruturados no arquivo de regra.

ADS DETEC-0051 - MiniDump de LSASS via comsvcs.dll

OBJETIVO
Observar criação de dump de memória do processo LSASS via MiniDumpW da
comsvcs.dll, técnica T1003.001, por processo fora da lista de ferramentas
de backup homologadas.

DETALHES TÉCNICOS
Fontes: eventos de criação de processo (Sysmon 1 / EDR) e acesso a
arquivos (Sysmon 10). Condição: processo cuja linha de comando contém
comsvcs.dll e MiniDump com handle de leitura em lsass.exe, excluindo
ferramentas de backup assinadas na lista EXC-2025-007 (expira 2026-02-28).
Plataforma: SIEM central, índices de endpoint Windows.

CENÁRIO PRETENDIDO
Operador com acesso administrativo em workstation de servidor executa
rundll32 com comsvcs.dll para exfiltrar credenciais em memória, padrão
recorrente em LockBit e em toolkits de acesso inicial.

BLIND SPOTS
Não cobre dump via DBUtil e ferramentas diretas que não usam comsvcs.dll,
não cobre dump feito por driver legítimo abusado e não cobre hosts fora
da integração de EDR, cerca de 4% da frota.

FALSOS POSITIVOS
Ferramentas de backup e diagnóstico homologadas já excluídas com
justificativa. Suporte de fabricante de banco gerou 2 FP em 90 dias.

PRIORIDADE
High, resposta em até 4 horas. Alerta despachado ao plantão com
enriquecimento de linhagem de processo.

INVALIDAÇÃO
Revisar se Sysmon 10 for desligado, se a frota mudar de EDR sem
equivalência de eventos ou se a lista EXC-2025-007 expirar sem renovação.
Revisão anual obrigatória em março.

MANUTENÇÃO
Autor: engenharia de detecção. Revisores: triagem sênior e resposta.
Histórico: v2 incluiu exclusão de backup após tuning de 2025-07.

Três detalhes do exemplo ilustram o padrão de qualidade esperado. As exclusões citam o ID do registro de tuning com data de expiração, conectando a ADS à governança descrita na nota de SNR. Os blind spots nomeiam ferramentas alternativas conhecidas, o que transforma o documento em insumo direto para a fila de cobertura por tática. E o cenário pretendido cita grupos de ameaça, conectando a detecção ao perfil de adversários relevantes e justificando a prioridade alta para quem revisa o catálogo meses depois.

O tamanho do exemplo também é um recado de implantação. Uma ADS completa cabe em pouco mais de uma página quando o time escreve com precisão, e documento mais longo quase sempre indica campos preenchidos com clichê. A meta de qualidade não é o volume do texto, e sim a capacidade de cada campo de ser lido por alguém que nunca viu a regra e agir com base nele sem perguntar nada ao autor.

6. Ciclo de Vida da Detecção via ADS

O framework organiza o ciclo de vida da detecção em estados explícitos, e a ADS é o registro que acompanha a transição de cada estado. A vantagem de formalizar o ciclo é dupla: as métricas da pasta anterior passam a ser calculadas por estado, e a discussão de aposentadoria deixa de ser tabu, porque toda regra nasce com critérios de invalidação que definem quando ela deve sair ou mudar.

A implantação do ciclo no repositório é o que transforma o framework em prática de engenharia. Cada ADS vive em um arquivo versionado com status no metadado, o merge na implantação exige revisão, e a validação da cadência dispara trabalho automático no pipeline, na linha do Detection as Code. O histórico de transições, quando registrado no próprio arquivo, permite reconstruir a biografia de qualquer regra em segundos, e essa biografia é o que falta na maioria das análises post-mortem de detecção que falhou.

A revisão trimestral do catálogo percorre os estados com três decisões disponíveis, e documentar as escolhas é parte do ritual.

• Manter, quando a regra continua válida, coberta por validação recente e sem pendências de tuning.
• Reescrever, quando a intenção continua boa, mas a condição envelheceu, e a ADS recebe nova versão com o histórico preservado.
• Aposentar, quando o critério de invalidação foi atingido, e a aposentadoria é registrada com motivo, para que a técnica tenha outra detecção planejada ou seja aceita como risco.

Uma prática de gestão fecha o ciclo: a revisão trimestral do catálogo percorre todas as ADS em estado de tuning ou invalidação pendente e decide cada uma. O resultado típico é que uma fração das regras é aposentada a cada trimestre, e isso é sinal de saúde, e não de perda, porque catálogo enxuto e explicado rende mais que catálogo grande e opaco, tanto na fila quanto na confiança dos analistas.

7. Erros Comuns e Pontos de Atenção

• Tratar a ADS como burocracia e escrever o documento depois da consulta, quando a intenção já se perdeu e o texto vira transcrição de código.
• Preencher blind spots com texto genérico, do tipo pode não funcionar em todos os ambientes, que não orienta investigação nem cobertura.
• Deixar de datar e expirar exclusões citadas nos detalhes técnicos, transformando o tuning em buraco permanente de cobertura.
• Manter a ADS fora do controle de versão, no wiki ou em documento solto, perdendo a amarração entre a versão do texto e a versão da regra.
• Escrever a prioridade sem acordá-la com a triagem, gerando documentos que prometem urgência que a fila não reconhece.
• Ignorar o campo de invalidação, mantendo indefinidamente regras que as próprias condições do ambiente já anularam.
• Confundir revisão de ADS com aprovação de regra, delegando ao documento o papel de pipeline, quando as duas governanças são complementares e distintas.

O ponto de atenção central é resistir à tentação de gerar ADS por script para todo o catálogo de uma vez. A conversão em lote produz documentos ocos que descreditam o framework dentro do time, e a adoção real começa pelas detecções novas e pelas regras mais críticas, avançando na medida em que o documento demonstra valor na triagem e nos incidentes.

8. Integração com o Restante da Biblioteca

Na sequência da pasta, a Hunting-to-Detection Bridge adota a ADS como destino estruturado da promoção de caças, e a nota de Detection as Code mostra onde o documento vive no repositório e como o pipeline valida os metadados. As métricas da pasta anterior encontram na ADS a fonte dos metadados que as alimentam, de prioridade a mapeamento ATT&CK, fechando o circuito entre documento e medição.

No restante da biblioteca, a ADS dialoga com o controle AUT.3 do capítulo 15, que trata automação de detecção, e com o controle SIM.5, que mede cobertura e consome os blind spots para explicar diferenças entre cobertura nominal e real. Com o capítulo 19, a relação é direta: o cenário pretendido de cada ADS é a lista de entrada da agenda purple, e a validação do ciclo alimenta o estado de validação do ciclo de vida, transformando o framework no registro permanente do esforço contínuo de verificação.

Um hábito final conecta a ADS ao dia a dia do SOC sem custo adicional. Toda vez que um alerta da regra gerar confusão de triagem, a resposta correta é atualizar a ADS, mesmo sem mudar a consulta, porque confusão recorrente é sintoma de intenção mal escrita. Esse hábito transforma o documento em registro vivo de mal-entendidos esclarecidos, e é exatamente esse registro que diferencia um catálogo maduro de um amontoado de consultas com nomes bonitos.