Como validar uma regra de detecção antes da produção

Uma regra que dispara em um teste controlado ainda não está pronta para produção. Ela precisa encontrar o comportamento relevante, operar sobre dados confiáveis e gerar alertas que uma equipe consiga investigar.

Este artigo trata do que fica entre “a regra funcionou no meu teste” e “a regra melhora a capacidade de detecção da organização” — duas coisas bem diferentes.

Defina a hipótese detectável

Descreva o comportamento que a regra pretende observar, o ambiente em que ele ocorre e quais campos de telemetria são necessários.

Diferencie a técnica do indicador usado no teste. Essa distinção define a vida útil da regra:

Regras no primeiro nível têm valor, mas envelhecem em dias. Se a detecção depende de um único nome de processo ou endereço, sua cobertura é estreita — e o relatório de cobertura que ela produz é otimista demais.

Especifique também os limites conhecidos: fontes sem coleta, eventos perdidos, atraso de ingestão e sistemas fora do escopo. Esses limites fazem parte da capacidade real da regra. Uma detecção que cobre 40% da frota e é reportada como cobertura total é pior que nenhuma, porque produz confiança injustificada.

Prepare casos positivos e negativos

Monte exemplos autorizados que devem disparar e exemplos legítimos parecidos que não deveriam gerar incidente.

Os casos negativos são onde o trabalho realmente acontece, e a lista precisa ser específica do seu ambiente:

• a ferramenta de administração que faz exatamente o que a regra procura;
• o software de backup que lê volumes inteiros;
• o scanner de vulnerabilidade autorizado;
• a janela de implantação em que scripts executam em massa;
• o ambiente de desenvolvimento, onde quase tudo é atípico.

Execute os casos em ambiente controlado e registre os eventos brutos, não só o resultado da regra. Confira se ela usa os campos que você imaginou e se diferenças entre sistemas mudam o resultado — nomes de campo, formato de horário e níveis de detalhe de log variam entre plataformas e versões.

Um teste positivo responde “consegue detectar este caso?”. Casos negativos respondem “com que frequência interromperá a equipe sem necessidade?”. Nenhuma das duas perguntas basta sozinha.

Meça o custo operacional antes de publicar

Um dado que evita a maior parte dos problemas: rode a lógica retroativamente sobre dados históricos antes de publicar. Trinta dias de histórico respondem, sem custo operacional, quantos alertas a regra teria gerado — e quantos deles seriam legítimos.

A conta que decide a publicação:

alertas por dia × tempo médio de triagem = horas de equipe por dia

Uma regra que gera 40 alertas diários a 10 minutos cada consome quase 7 horas de analista por dia. Se a taxa de acerto esperada for baixa, essa regra não melhora a detecção: ela consome a capacidade que outras detecções precisariam.

Observe também volume, duplicações e atraso até o alerta. Uma regra muito sensível pode produzir tantos alertas que sinais importantes fiquem sem análise — o modo de falha mais comum e menos discutido em operações de detecção. Antes de criar exceções amplas, entenda quais padrões legítimos estão gerando ruído: uma exceção mal desenhada é um buraco permanente na cobertura.

Prefira reduzir ruído pela lógica a reduzir por exceção. Exigir duas condições correlacionadas costuma cortar falso positivo sem abrir a exceção que um adversário poderia habitar.

Escreva o alerta para quem vai recebê-lo às 3h

Priorize enriquecimento útil: identificação do ativo, papel da conta, ações relacionadas e acesso aos eventos originais. Um alerta deve facilitar a primeira decisão do analista.

O que um alerta acionável contém:

1. O que aconteceu, em uma frase sem jargão interno.
2. Por que isso importa — a hipótese que motivou a regra.
3. Contexto do ativo e da conta — criticidade, dono, privilégio.
4. Os primeiros três passos de verificação sugeridos.
5. Link para os eventos brutos, sem exigir que o analista reconstrua a consulta.
6. O que isso não é — o falso positivo conhecido e como descartá-lo.

O item 6 é o mais negligenciado e o que mais economiza tempo. Se a equipe já sabe que a regra dispara em uma janela de manutenção, escrever isso no alerta poupa a mesma investigação repetida dezenas de vezes.

Um alerta que só diz “atividade suspeita detectada no host X” transfere todo o trabalho de contexto para quem está de plantão — justamente quem tem menos tempo e informação para reconstruí-lo.

Trate a regra como um produto

Toda regra precisa de dono, propósito, fonte de dados, casos de teste e revisão prevista. Versione a lógica e registre a justificativa das mudanças — a pergunta “por que esta condição existe?” aparece meses depois, e sem resposta ninguém ousa mexer.

Gatilhos que exigem reavaliação:

• campo renomeado ou formato alterado pelo fornecedor;
• nova fonte de telemetria que muda a cobertura;
• mudança de processo operacional que cria falso positivo novo;
• atualização de sistema que altera o comportamento observado;
• a técnica que a regra cobria caiu em desuso.

Uma detecção também deve poder ser aposentada. Regras mantidas só porque já existem consomem triagem e criam a ilusão de cobertura.

Meça a saúde do conjunto, não apenas de cada regra:

A terceira linha merece atenção. Uma regra que nunca dispara pode significar que o comportamento não ocorre — ou que a fonte de dados parou de chegar há dois meses e ninguém percebeu. Silêncio não é evidência de segurança; monitorar a chegada da telemetria é tão importante quanto monitorar seu conteúdo.

Cuidado com o que a cobertura no mapa não diz

Mapear detecções contra as táticas do ATT&CK é útil e virou prática comum. Também é a fonte mais eficiente de falsa confiança em uma operação de detecção.

Três armadilhas na leitura de um mapa de cobertura:

A técnica marcada como coberta por uma regra frágil. Se a regra usa um nome de executável, a coluna fica verde e a evasão custa um mv. O mapa não distingue detecção comportamental de correspondência de string.

A técnica com muitos procedimentos e uma regra. Uma técnica do ATT&CK pode ser executada de dezenas de formas distintas. Cobrir uma delas colore a célula inteira — e a célula colorida é o que a liderança vê.

A cobertura que existe onde há telemetria fácil. Equipes tendem a escrever regras para as fontes que já coletam. O mapa então reflete a distribuição da telemetria disponível, não a do risco real do ambiente.

Uma leitura mais honesta anota, por técnica, três coisas: a fonte de dados exigida, se ela é coletada em toda a frota, e em qual nível a regra opera — valor específico, ferramenta ou comportamento. O resultado é menos colorido e muito mais útil para decidir o próximo investimento.

Quando a lacuna for de telemetria, escrever mais regras não resolve. Nenhuma lógica compensa um evento que nunca foi coletado — e esse é o motivo mais comum de uma detecção “pronta” não disparar em produção.

Registre a regra de forma que ela sobreviva a você

A documentação mínima de uma detecção cabe em uma página e responde ao que um plantonista ou um sucessor vai precisar:

O campo de exceções é o que mais envelhece mal. Exceções entram para resolver um ruído pontual, ninguém as remove, e depois de um ano a regra tem mais exclusões que lógica. Registrar motivo e data de revisão para cada uma transforma uma decisão temporária em algo que alguém vai reavaliar de fato.

Revise após publicar

Acompanhe o resultado em produção. Depois de cada investigação, pergunte se o alerta trouxe contexto suficiente para a primeira decisão. Se não trouxe, prefira enriquecer o evento, esclarecer a hipótese ou ajustar a documentação antes de ampliar exceções.

O objetivo não é maximizar a contagem de alertas. É aumentar a chance de reconhecer uma atividade relevante a tempo de agir. Uma detecção útil reduz incerteza para quem está de plantão.

Próximo passo

Escolha uma regra que já está em produção e responda três perguntas sobre ela: quantos alertas gerou no último mês, quantos viraram investigação real e quando a fonte de dados dela foi verificada pela última vez. Se alguma resposta não estiver disponível, essa é a lacuna a resolver antes de escrever a próxima regra.

Valide detecções apenas em ambientes próprios, de laboratório ou com autorização explícita para o teste.