Usar o MITRE ATT&CK no SOC significa transformar a matriz de táticas e técnicas em um sistema operacional de detecção: inventariar a telemetria disponível, mapear cada regra do SIEM às técnicas que ela realmente cobre, validar essa cobertura com testes controlados e converter as lacunas em um backlog priorizado de detection engineering. O MITRE ATT&CK é uma base de conhecimento de técnicas de adversários baseada em observações de ataques reais, e a detecção de comportamentos é um dos usos primários documentados pelo próprio MITRE. Para o analista de nível 1, isso entrega uma linguagem comum para triar alertas; para o time de engenharia, define onde a próxima regra deve nascer.
Do heatmap ao backlog operacional
O erro mais comum é tratar o mapa do ATT&CK como relatório de compliance: o time pinta de verde tudo o que acredita detectar e o gráfico vira enfeite de apresentação. Uma regra com tag de técnica não é garantia de detecção — ela pode depender de um log que não está sendo ingerido, gerar tanto ruído que acabou silenciada ou cobrir apenas uma das várias maneiras de executar o comportamento. O mapa só tem valor quando distingue estados de cobertura diferentes e alimenta decisões de engenharia.
| Estado | Definição | Ação no SOC |
|---|---|---|
| Fonte presente | Telemetria ingerida e consultável, sem regra associada | Criar regra ou justificar a ausência |
| Regra existente | Detect existe, mas nunca foi testado | Agendar validação controlada |
| Cobertura validada | Regra testada, afinada e monitorada | Vigiar regressão e novas implementações |
O caminho do heatmap decorativo ao backlog real segue uma ordem simples:
- Exporte todas as regras ativas do SIEM e etiquete cada uma com técnica, sub-técnica e a fonte de dados que ela exige.
- Cruze as fontes exigidas com o que está de fato ingerido: sem log, não existe detecção possível.
- Execute um teste controlado para cada regra prioritária e registre se passou, falhou ou está desativada.
- Pinte o mapa apenas com o estado validado e transforme cada lacuna em item de backlog com dono e prazo.
Priorização por perfil de ameaça
Perseguir a matriz inteira é receita de desperdício. O guia oficial orienta não perseguir cobertura total da matriz, mas priorizar apenas as táticas e técnicas mais relevantes para o contexto de cada organização, porque cada ambiente enfrenta uma ameaça própria. Na prática, o time lista os grupos de ameaça que miram o seu setor, exporta as técnicas observadas desses grupos na matriz e cruza com a cobertura validada interna: a interseção entre o que é usado por quem ataca o setor e o que não está coberto define a fila de trabalho. Incidentes próprios são o melhor insumo: um ransomware que derrubou a autenticação no ambiente, como no bypass de MFA pelo Gunra, mostra exatamente quais técnicas faltam no catálogo. O mesmo vale para movimento lateral: se o ataque chegou às credenciais, a detecção de pass-the-hash no SOC sobe na prioridade. Cobertura orientada à ameaça vale mais que percentual de matriz pintada.
Mapeando dados e regras
A matriz só descreve comportamento; quem detecta é o dado. Cada técnica do ATT&CK lista as fontes de dados que dão visibilidade sobre ela — criação de processo, tráfego de rede, eventos de registro. O trabalho começa pelo inventário: quais logs chegam ao SIEM, com qual qualidade e em quais plataformas. O evento 4688 do Windows Security e o Sysmon, por exemplo, sustentam boa parte das detecções de endpoint; sem eles, técnicas de execução e persistência ficam cegas. Depois do inventário, etiquete o acervo de regras com a técnica coberta e a dependência de dados, e registre o status de validação de cada item. Repositórios públicos como o Sigma ajudam a traduzir lógica de detecção entre plataformas sem reescrever tudo, e o Cyber Analytics Repository da MITRE serve de referência para o que já existe pronto. O objetivo é um registro vivo, versionado e consultável por técnica e por fonte de dados.
Validação com purple team
Regra sem teste é hipótese. A recomendação da equipe do ATT&CK é validar cada regra executando a técnica com o Atomic Red Team, projeto open source alinhado à matriz que fornece conteúdo de red team para testar analytics. O ciclo é direto: dispare o teste em ambiente controlado, confira se o alerta disparou, ajuste a lógica para reduzir falso positivo e repita até a detecção ficar estável. O estágio seguinte é o purple team contínuo: o lado vermelho tenta evadir a regra — renomear binário, trocar caminho, usar outra implementação — e o azul responde com lógica baseada em interação de sistema, não em nome de arquivo. Cada rodada atualiza o status de validação no registro de regras e realimenta o mapa de cobertura.
Cobertura além do verde
A evolução mais recente da área ataca justamente a fraqueza do heatmap. A pesquisa Summiting the Pyramid, do Center for Threat-Informed Defense, publicada em setembro de 2026, propõe medir cobertura pelo conceito de implementação: um caminho comportamental distinto de executar uma técnica do ATT&CK, caracterizado pelo trajeto de execução e pelas interações de sistema necessárias para realizá-lo. Uma tarefa agendada no Windows, por exemplo, pode nascer de PowerShell, de alteração direta no registro ou de schtasks.exe — mesma técnica, oportunidades de detecção diferentes. Com esse modelo, a cobertura passa a ser expressa como 2/8 quando apenas parte das implementações conhecidas de uma técnica é detectada, em vez de um verde binário que esconde tudo. Somam-se a isso pontuações de qualidade do sinal, com robustez contra evasão e precisão contra ruído. Dois times podem exibir a mesma caixa verde com capacidades muito diferentes por trás dela.
