Detection engineering aplica o ciclo de vida da engenharia de software à criação de detectores: cada regra vira código versionado, testado e revisado por pares antes de chegar à produção. Em equipes de SOC, isso substitui a montagem manual de alertas por um processo repetível que transforma hipóteses sobre o comportamento de adversários em detecções que capturam classes de ameaça, não apenas hashes e domínios que mudam entre campanhas. Quem convive com alert fatigue ganha ruído a menos, porque a sinalização é desenhada na origem.
O conceito parte de uma premissa prática: um detector descreve um conjunto específico, porém abstrato, de comportamentos que um adversário executa. Ao mirar táticas, técnicas e procedimentos (TTPs), o SOC detecta movimento mesmo quando o atacante troca de ferramenta, o que importa diante de invasores que abusam de utilitários legítimos.
O que é detection engineering
Detection engineering é o conjunto de práticas que tratam a detecção de ameaças como um produto de software, e não como um script isolado. A equipe desenha regras a partir de fontes como o framework MITRE ATT&CK, relatórios de pesquisa aplicada, whitepapers e blogs da comunidade, e leva cada detector por um pipeline de controle de versão, testes e revisão por pares antes do merge em produção.
Na prática da Red Canary, um detector é comportamento de processo codificado numa linguagem interna, que combina atributos como relação processo-pai-filho, linha de comando, atividade de rede, comunicação entre processos e operações de registro ou arquivo. A meta é acertar o ponto entre comportamento específico demais e genérico demais.
Ciclo de vida do detector
O fluxo reproduz o desenvolvimento de software clássico e, em ambientes bem instrumentados, percorre da hipótese à produção em menos de quinze minutos. As etapas são:
- Hipótese: o analista levanta uma suposição sobre um TTP, por exemplo que um compilador legítimo não costuma abrir conexões de rede externas.
- Perfil de comportamento normal: consultas ao conjunto de dados respondem com que frequência o binário executa, quais processos filhos gera e se faz conexões internas ou externas.
- Escrita do detector: a hipótese vira código na linguagem do SIEM ou do motor de detecção, com metadados de nome, descrição e contexto para o analista.
- Teste: casos positivos e negativos confirmam que a regra dispara no comportamento-alvo e permanece silenciosa no uso legítimo.
- Revisão e publicação: após aprovação por pares, o detector entra em produção, é sincronizado com o motor e recebe testes funcionais em máquinas virtuais sempre que possível.
Versionar regras evita o cenário clássico de detectores órfãos, sem dono e sem teste. A mesma lógica que sustenta a qualidade de código de aplicação sustenta a qualidade da detecção.
Abuso de ferramentas legítimas
A detecção baseada em TTP ganha força justamente onde indicadores atômicos falham. O advisory conjunto AA23-320A do FBI e da CISA documenta que atores do grupo Scattered Spider evadem detecção usando técnicas living off the land e aplicativos legítimos já presentes na lista de permitidos para navegar pela rede da vítima.
A tabela de ferramentas do advisory lista utilitários legítimos, como AnyDesk, TeamViewer, Ngrok, Tactical.RMM, Splashtop e ScreenConnect, cujo uso isolado não indica ataque. Combinados com contexto de anomalia, porém, viram sinais de acesso remoto não autorizado: um detector que observa uma ferramenta de suporte iniciando sessão fora do horário esperado, ou a partir de um processo-pai incomum, converte esse abuso em alerta.
O grupo também combina engenharia social, troca de SIM e MFA fatigue para obter credenciais, instalar ferramentas de acesso remoto e, mais recentemente, implantar a variante de ransomware DragonForce para extorsão. Detectores que cobrem acesso a contas, como os discutidos no guia de sequestro de contas, fecham parte dessa superfície.
Métricas e tuning de detectores
Aceitar uma taxa mais alta de falsos positivos faz sentido quando existe supressão automatizada e métrica de conversão. O time mede quantos eventos verdadeiros viram detecções maliciosas ou suspeitas de fato, e usa esse rastro para afinar regras e priorizar cobertura nova. Sem métrica, a supressão vira silenciamento cego e a detecção degrada.
O tuning contínuo mantém os detectores relevantes quando adversários mudam de TTP. Conectar o repositório de detectores a um framework de testes funcionais, o equivalente ao Atomic Red Team mapeado ao MITRE ATT&CK, confirma a cobertura existente e aponta prioridades de desenvolvimento.
Implementação prática
Uma equipe de SOC pode começar pequeno e crescer. A tabela resume os pilares e o cuidado associado a cada um.
| Pilar | O que fazer | Armadilha comum |
|---|---|---|
| Detectors as Code | Versionar regras em Git com revisão por pares | Regras em produção sem histórico |
| Hipótese e perfil | Questionar o dataset antes de codificar | Codificar sem entender o normal |
| Teste | Criar casos positivos e negativos | Testar só o caminho de sucesso |
| Supressão e métrica | Medir conversão de evento em ameaça | Suprimir sem rastro de decisão |
| Cobertura ATT&CK | Mapear detectores a técnicas | Perseguir cobertura sem qualidade |
Para ameaças específicas, como ransomware, a mesma engenharia vira regras concretas sobre escalonamento, execução e criptografia em massa, tema tratado em detalhe na análise de detecção de ransomware.
