Engenharia de Detecção no SOC com MITRE ATT&CK

Engenharia de detecção é a disciplina de projetar, testar e manter regras de detecção baseadas em comportamento e mapeadas ao framework MITRE ATT&CK. No SOC, ela reduz falsos positivos em até 70%, substitui alertas de IoCs efêmeros por detecção de TTPs duradouras e cria um ciclo contínuo entre detecção automatizada e threat hunting orientado por hipótese.

O Problema dos Alertas

Todo analista de SOC que já passou um turno cobrindo fila de alertas conhece a sensação: 4.000 alertas de SIEM em um dia, dos quais talvez 40 mereçam investigação séria. Os outros 3.960 são ruído. Segundo pesquisa da SANS de 2025, 73% das equipes de segurança apontam os falsos positivos como o maior desafio de detecção (Vectra AI, 2026). O problema não é falta de ferramenta — é falta de engenharia por trás das detecções.

O SOC moderno não precisa de mais alertas. Precisa de alertas certos, com contexto, que levam a decisão. É aqui que entra a engenharia de detecção: a disciplina de projetar, testar, implantar e manter regras que capturam comportamento de atacante — não assinaturas obsoletas.

O Que É Engenharia de Detecção

Engenharia de detecção é o processo estruturado de criar lógica de detecção baseada em comportamento, mapeada a frameworks como o MITRE ATT&CK, e submetida a um ciclo de vida contínuo de teste, medição e refinamento. Diferente da abordagem tradicional — onde alguém escreve uma regra de SIEM e nunca mais toca nela —, a engenharia de detecção trata cada regra como código: versionada, testada e depreciada quando perde valor.

O conceito central é a transição de IoCs (indicadores de comprometimento) — que são efêmeros, como hashes e IPs — para TTPs (táticas, técnicas e procedimentos), que descrevem como o adversário opera e são muito mais difíceis de evadir. Um IP malicioso muda em horas; o comportamento de um atacante usando Mimikatz para extrair credenciais do LSASS persiste por anos (CyberDefenders, 2026).

Organizações que implementam práticas maduras de engenharia de detecção relatam redução de 50% a 70% nos falsos positivos através de tuning contextual e mapeamento comportamental (LinkedIn / Detection Engineering 2025).

MITRE ATT&CK no SOC

O framework MITRE ATT&CK cataloga táticas e técnicas usadas por adversários reais, organizadas em uma matriz que cobre desde acesso inicial até exfiltração de dados. Para um SOC, o ATT&CK funciona como uma linguagem compartilhada entre times: o analista de L1 fala em “T1003 — OS Credential Dumping”, o time de threat intelligence referencia campanhas de APTs mapeadas às mesmas técnicas, e o CISO entende onde estão os gaps de cobertura.

O framework se divide em:

Táticas: o objetivo do adversário (ex.: acesso a credenciais, persistência, exfiltração).
Técnicas: como o adversário alcança esse objetivo (ex.: extração de credenciais via LSASS, criação de tarefa agendada).
Procedimentos: a implementação específica (ex.: uso do Mimikatz para despejar memória do LSASS).

Essa estruturação permite que o SOC priorize detecções pelas técnicas mais observadas no seu ambiente e setor, em vez de tentar cobrir as mais de 600 técnicas do framework inteiro de uma vez (Bitsight, 2026).

Mapeando Cobertura de Detecção

Saber quais técnicas seu SOC detecta — e quais são pontos cegos — é fundamental. O MITRE ATT&CK Navigator é uma ferramenta open-source de visualização que permite sobrepor mapas de calor da atividade de grupos de ameaça, cobertura de detecção e resultados de exercícios de red team diretamente na matriz (MITRE Corporation).

Um SOC prático usa o Navigator com código de cores:

Cor	Significado	Ação Recomendada
Verde	Detectamos essa técnica de forma confiável	Manter e monitorar taxa de falsos positivos
Amarelo	Visibilidade parcial — algum log, sem regra ativa	Priorizar criação de regra de detecção
Vermelho	Ponto cego — nenhuma cobertura	Avaliar risco e definir plano de cobertura

A análise de gaps deve começar pelas técnicas mais relevantes ao seu setor. Um SOC financeiro prioriza acesso a credenciais e movimento lateral; um SOC industrial foca em acesso inicial via protocols de OT e manipulação de controle.

Ciclo de Vida da Detecção

Uma regra de detecção não é um artefato estático. Ela segue um ciclo de vida que inclui design, teste, implantação, monitoramento e aposentadoria. Tratar a detecção como código — com versionamento em Git, revisão por pares e testes automatizados — é o que separa um SOC maduro de um que vive apagando incêndios.

Hipótese: definir qual comportamento de atacante a regra deve capturar, mapeado a uma técnica do ATT&CK.
Desenvolvimento: escrever a lógica (query de SIEM, regra de EDR, sigma rule) usando dados reais do ambiente.
Teste: validar contra dados de ataque simulado (atomic tests, exercícios de purple team) e confirmar que não gera cascata de falsos positivos.
Implantação: publicar com documentação, mapeamento ATT&CK e runbook de resposta associado.
Monitoramento: acompanhar taxa de acerto, volume de alertas e tempo médio de triagem (MTTR).
Refinamento ou aposentadoria: ajustar limiares ou desativar quando a técnica perde relevância ou os dados de origem mudam.

Esse ciclo garante que o SOC não acumule centenas de regras mortas que só servem para inflar a fila de alertas.

Threat Hunting Orientado por Hipótese

Detecção é reativa por natureza: você só alerta sobre o que já configurou para detectar. Threat hunting é o complemento proativo — sair à procura de atividade maliciosa que suas regras ainda não capturam. A abordagem mais eficaz é a caça orientada por hipótese, que segue três passos:

Formular hipótese: “Adversários que comprometem credenciais de administrador provavelmente usam PowerShell com encoding para executar comandos remotos.”
Mapear ao ATT&CK: identificar as técnicas correspondentes (T1059.001 — PowerShell, T1021 — Remote Services).
Executar busca: consultar logs de endpoint, proxy e SIEM procurando o padrão. Se encontrar atividade maliciosa, converter em nova regra de detecção.

O resultado de cada caçada deve alimentar o ciclo de engenharia de detecção. Cada técnica descoberta vira uma oportunidade de nova regra, fechando o ciclo entre hunting proativo e detecção automatizada (CyberDefenders, 2026).

Métricas da Engenharia de Detecção

Medir a eficácia da engenharia de detecção vai além de contar alertas. As métricas que diferenciam um SOC eficaz:

MTTD (Mean Time to Detect): tempo entre o início do incidente e a primeira detecção. Meta realista: reduzir consistentemente a cada trimestre.
MTTR (Mean Time to Respond): tempo entre detecção e contenção. O foco da detecção não é apenas alertar — é reduzir o tempo de decisão.
Taxa de falsos positivos por regra: identificar regras que geram mais ruído que valor e priorizar tuning.
Cobertura ATT&CK: percentual de técnicas críticas com detecção ativa e testada.

Reportar essas métricas para liderança traduz o trabalho técnico do SOC em impacto mensurável para o negócio.

Por Onde Começar Hoje

Se seu SOC ainda trata detecção como regras soltas em um SIEM, comece pequeno. Escolha as cinco técnicas do ATT&CK mais relevantes ao seu ambiente, mapeie sua cobertura atual no Navigator e crie um plano para fechar os três maiores gaps em 90 dias. Documente cada regra com sua técnica correspondente, runbook de resposta e dados de teste. Em três meses, você terá uma base mensurável — e a fila de alertas vai começar a fazer sentido.