Testando e ajustando detecções

Uma detecção não ajustada que é acionada por atividades benignas é pior do que não ter detecção alguma. Os analistas aprendem a ignorar alertas ruidosos, e o único ataque real acaba perdido na fila. Isso é fadiga de alertas e é assim que invasões passam despercebidas até mesmo por centros de operações de segurança bem financiados.

O ajuste é o processo disciplinado de maximizar os verdadeiros positivos e, ao mesmo tempo, levar os falsos positivos a quase zero, sem deixar de detectar ameaças reais.

Qualidade da detecção com quatro resultados:

• Verdadeiro positivo (TP) — dispara diante de uma atividade maliciosa real
• Falso positivo (FP) — dispara diante de uma atividade benigna
• Verdadeiro negativo (TN) — permanece corretamente silencioso diante de uma atividade benigna
• Falso negativo (FN) — não detecta uma atividade maliciosa real

O ajuste envolve escolhas nesse espaço. Tornar uma regra menos rígida reduz os FNs, mas aumenta o risco de FPs; torná-la mais rígida produz o efeito oposto. O desafio é encontrar o equilíbrio que o SOC consiga sustentar.

Não é possível fazer ajustes às cegas. Crie um conjunto de amostras sabidamente maliciosas (a regra deve disparar) e sabidamente legítimas (a regra deve permanecer silenciosa). No modelo de detecção como código do Sigma, elas ficam como casos de teste ao lado da regra.

Gere telemetria real sabidamente maliciosa executando a técnica com segurança. A Atomic Red Team fornece testes pequenos e documentados, mapeados para ATT&CK, que você executa em um laboratório para confirmar que sua regra realmente dispara.

Execute o teste atômico, capture os registros e confirme que a detecção é acionada. Se isso não acontecer, sua regra tem uma lacuna de cobertura, independentemente de quão bom o YAML pareça.

Antes de implantar uma regra para gerar alertas, execute-a no modo de auditoria com dados históricos e em tempo real para descobrir o que normalmente a aciona. Essa linha de base revela os processos, administradores e ferramentas legítimos que, de outra forma, gerariam FPs.

O que parece malicioso em abstrato muitas vezes é uma tarefa de backup, um verificador de vulnerabilidades ou um agente RMM no seu ambiente específico. O estabelecimento da linha de base revela esses casos antes que eles acordem um analista durante a noite.

O ajuste mais limpo mantém intacta a lógica maliciosa e exclui os acionadores sabidamente legítimos por meio de filtros explícitos. Isso é auditável: um revisor vê exatamente o que foi excluído e por quê.

Prefira exclusões restritas e justificadas a ampliar a lógica principal, o que pode criar pontos cegos silenciosamente.

Toda exclusão é uma brecha onde um invasor pode se esconder. Se você filtrar toda a atividade de ParentImage que contenha o nome de uma ferramenta, um adversário que se passe por essa ferramenta conseguirá evitar sua detecção.

Diretrizes:

• Filtre pelo atributo mais específico disponível (caminho completo, editor assinado, resumo criptográfico)
• Documente por que cada filtro existe
• Reavalie os filtros periodicamente — os ambientes mudam
• Prefira aumentar um limite a remover uma condição

Alguns comportamentos só são suspeitos quando ocorrem em grande volume. Uma única tentativa de acesso malsucedida é normal; cinquenta em um minuto a partir de uma mesma origem, não. Use a agregação na condição para gerar alertas com base na taxa ou na contagem, em vez de alertar para cada evento.

O ajuste de limites reduz drasticamente o ruído em padrões de força bruta, varredura e exfiltração.

O ajuste é contínuo, não algo feito uma única vez. Acompanhe as métricas por regra e reavalie os piores casos:

• Volume de alertas por regra e por dia
• Taxa de FP com base nas classificações dos analistas
• Precisão = TP / (TP + FP)
• Impacto no tempo até a triagem

Uma regra que gere 200 alertas por semana, todos encerrados como benignos, deve ser ajustada, rebaixada para auditoria ou desativada. Deixe os dados orientarem a decisão.

Nem todo ruído é resolvido por supressão. Muitas vezes, um alerta é tecnicamente válido, mas precisa de contexto para ser classificado. O enriquecimento anexa esse contexto automaticamente para que os analistas decidam mais rápido.

• Criticidade e responsável pelo ativo
• Função do usuário e indicação de que a conta é privilegiada
• Reputação, segundo a inteligência de ameaças, de endereços IP, domínios e resumos criptográficos
• Indicação de que a máquina está em uma janela de manutenção

Alertas enriquecidos permitem atribuir pontuações de risco e priorizar casos, reduzindo o ruído efetivo mesmo quando o volume bruto de alertas não muda.

Ao ajustar uma regra, execute novamente todo o conjunto de testes na integração contínua. Os testes sabidamente maliciosos impedem que detecções reais sejam acidentalmente desativadas pelo ajuste; os testes sabidamente legítimos confirmam que o FP foi corrigido.

Esse ciclo fechado explica por que a detecção como código e o ajuste devem andar juntos: você pode refatorar de forma agressiva porque os testes detectam qualquer cobertura que seja prejudicada.

Aplique seu discernimento de ajuste a uma situação real de escolha.

O ajuste mantém as detecções confiáveis e úteis para orientar ações:

• FPs não gerenciados causam fadiga de alertas e comprometimentos não detectados
• Use a estrutura TP/FP/TN/FN para raciocinar
• Crie conjuntos de testes com amostras sabidamente legítimas e sabidamente maliciosas
• Use a emulação de adversário (Atomic Red Team) para provar que as regras disparam
• Estabeleça uma linha de base no modo de auditoria antes de gerar alertas
• Faça ajustes com filtros restritos e documentados e limites, não com exclusões amplas
• Meça a taxa de FP e a precisão; repita o processo nas piores regras
• Execute novamente os testes de regressão a cada alteração

Você concluiu o curso de engenharia de detecção do Sigma.