A maioria dos times defensivos não sabe onde não enxerga. As regras existem, os alertas chegam, mas pouca gente consegue responder com precisão quais técnicas do MITRE ATT&CK têm cobertura real de detecção e quais dependem de telemetria que nunca chega ao SIEM. O DeTT&CT, estrutura de código aberto criada por Marcus Bakker e Ruben Bouman, organiza essa resposta em arquivos YAML pontuados e visualizados no ATT&CK Navigator. A ação prioritária é direta: inventariar as fontes de log que você já coleta, pontuar a qualidade delas e só então decidir o que passa a ser coletado a seguir.
O problema da cobertura cega
Painéis de SOC medem volume de alertas, tempo médio de resposta e falsos positivos, mas nenhum desses números revela o que falta. Uma operação pode ter centenas de regras ativas e ainda assim depender de duas ou três fontes de log para tudo. Quando um invasor usa uma técnica que não gera evento nas fontes disponíveis, a lacuna não aparece em relatório algum: aparece meses depois, no incidente. Quem é afetado: equipes de detecção, de engenharia defensiva e gestores que aprovam orçamento de ferramenta sem um mapa comparável entre opções.
No vocabulário do ATT&CK, fontes de dados representam os assuntos de informação que podem ser coletados por sensores e logs, e cada uma traz componentes que identificam as propriedades relevantes para detectar uma técnica ou sub-técnica específica, segundo a definição publicada pelo MITRE. Essa taxonomia permite falar de cobertura sem depender de nome de produto: o que interessa não é qual EDR você comprou, e sim quais fontes ele entrega de fato ao seu pipeline.
O trabalho começa como qualquer esforço de inventário de ativos: sem saber o que existe, não há como medir o que falta. No caso da detecção, o inventário é de telemetria, não de servidores.
Como o DeTT&CT pontua
O projeto no GitHub reúne quatro partes: uma CLI em Python, arquivos de administração em YAML, um editor gráfico para criar e editar esses arquivos e tabelas de pontuação separadas para detecções, fontes de dados e visibilidade. A proposta central da estrutura é pontuar e comparar a qualidade das fontes de log, a cobertura de visibilidade e a cobertura de detecção sobre a mesma matriz, cobrindo os domínios Enterprise, ICS e Mobile do ATT&CK.
A separação em três camadas é o que dá valor prático ao método. Qualidade da fonte de dados responde se o que você coleta é confiável e completo. Visibilidade responde o que dá para enxergar com essas fontes, mesmo sem regra escrita. Cobertura de detecção responde onde existe regra madura e centralizada. Conflitar as três é o erro clássico: um time acha que detecta porque comprou telemetria, quando apenas vê.
O quarto eixo compara a sua cobertura com o comportamento de grupos de ameaça mapeados no ATT&CK. O resultado sai como camadas coloridas no Navigator, o que transforma uma discussão abstrata sobre lacunas em uma decisão visual: quais técnicas usadas por atores que miram o seu setor dependem de fontes que você nem coleta.
Priorize as fontes de log
O modo genérico da CLI lista estatísticas por plataforma de quantas técnicas cada fonte de dados cobre. Na saída de exemplo do próprio projeto, Command Execution cobre 255 técnicas e Process Creation cobre 206, seguidas de telemetria de arquivos e de tráfego:
| Fonte de dados | Técnicas cobertas |
|---|---|
| Command Execution | 255 |
| Process Creation | 206 |
| File Modification | 98 |
| File Creation | 88 |
| Network Traffic Flow | 82 |
A leitura é fria: antes de discutir logs exóticos, garanta telemetria de processo e de comando em todos os endpoints. São as fontes que sustentam mais técnicas da matriz, e é nelas que a maior parte das trilhas de ataque deixa rastro. A contagem muda conforme a versão do ATT&CK, então trate os números como ordenação de prioridade, não como meta de projeto.
O caminho inverso também importa: telemetria poderosa que ninguém consulta é custo puro. Um exemplo que o portal já detalhou é o caso em que logs de infostealer viram atalho para o SSO corporativo — a fonte existia fora do perímetro do SOC, e a lacuna era de incorporação, não de tecnologia.
Procedimento de adoção
O método abaixo reproduz o fluxo previsto pela estrutura e cabe em um ciclo de quatro a seis semanas com uma pessoa dedicada:
- Instale a CLI a partir do repositório oficial e rode o modo genérico para conhecer as fontes de dados do ATT&CK.
- Liste, em planilha ou no próprio YAML, quais fontes você coleta de fato hoje, por plataforma, e onde elas terminam.
- Pontue a qualidade de cada fonte com base na tabela do projeto: completude, centralização e confiabilidade do evento.
- Registre as detecções existentes por técnica, indicando o tipo de sistema a que cada uma se aplica, para não inflar cobertura com regra que roda em um só servidor.
- Exporte as camadas para o ATT&CK Navigator e sobreponha o comportamento dos grupos que miram o seu setor.
- Repita o ciclo quando trocar de ferramenta, quando o ATT&CK mudar de versão ou quando um incidente revelar fonte ausente.
Prioridades P1 e P2
P1 — fechar as lacunas das fontes de alto rendimento: telemetria de processo e de comando em endpoint, centralizada e com qualidade pontuada, antes de qualquer aquisição nova. Em paralelo, registrar a cobertura atual em YAML para que a próxima decisão seja comparável a esta.
P2 — automatizar a manutenção. O ecossistema do projeto inclui uma biblioteca de terceiros, a Dettectinator, que lê detecções direto do SIEM ou do EDR e atualiza o arquivo YAML, reduzindo o esforço manual que costuma encerrar esse tipo de iniciativa depois do primeiro trimestre. Comparar a cobertura com grupos de ameaça a cada ciclo é a segunda frente: transforma o mapa em pauta de trabalho.