MAP.2 - Heatmaps de Cobertura por Tática

Este controle pertence ao grupo MAP (MITRE ATT&CK Mapping) do Framework CTH e deriva do
Capítulo 18 do documento de referência. Ele transforma o mapeamento de controles do MAP.1 em
visualizações sobre a matriz ATT&CK, usando camadas do ATT&CK Navigator com códigos de cor.
Seu papel é tornar forças e lacunas defensivas evidentes tanto para o analista técnico quanto
para a alta gestão, sustentando decisões de priorização e investimento.

1. Contexto e Posicionamento no Framework CTH

Um heatmap de cobertura condensa em uma única imagem aquilo que um relatório de cinquenta
páginas descreve com dificuldade: onde a organização vê, onde detecta e onde está cega. No
Framework CTH, o MAP.1 fornece os dados de mapeamento e o MAP.2 fornece a camada de
visualização e comunicação, com três níveis de cor padronizados: verde para detecção de alta
confiança, validada por simulação; amarelo para cobertura parcial, como regra não testada ou
visibilidade limitada; e vermelho para ausência de detecção. Essa padronização é o que permite
comparar trimestres entre si e comparar equipes diferentes dentro da mesma organização.

A visualização por tática também expõe desequilíbrios estruturais. É comum encontrar
organizações com cobertura forte em Command and Control, porque o IDS de rede e os feeds de
IOC sempre produziram alertas nessa tática, enquanto Credential Access e Defense Evasion
permanecem vermelhos, exatamente as táticas que precedem o impacto nos cenários modernos de
ransomware. Tornar esse desequilíbrio visível é o primeiro passo para rebalancear o
investimento de forma deliberada em vez de incremental.

2. A Camada do ATT&CK Navigator

O ATT&CK Navigator é uma ferramenta livre mantida pelo MITRE que sobrepõe anotações à matriz
ATT&CK. Uma camada (layer) é um documento JSON que atribui a cada técnica um score numérico,
uma cor, comentários e metadados; o Navigator renderiza esses atributos como um mapa de calor
sobre as 14 táticas. Como o formato é JSON aberto e documentado, camadas podem ser criadas à
mão, geradas por script, comparadas entre si e versionadas em Git.

Para criar uma camada manualmente, o fluxo básico é: abrir o Navigator, selecionar a versão da
matriz Enterprise correspondente à versão usada no MAP.1, criar a camada, selecionar as
técnicas e atribuir scores e cores conforme a legenda definida. Em seguida, exportar o JSON e
guardá-lo no repositório do programa. Para uso sério, entretanto, a criação manual deve ser
reservada apenas para explorações pontuais, porque não escala e não deixa trilha de auditoria
sobre a origem de cada score.

Um trecho de camada, reduzido a duas técnicas para ilustração, mostra os campos essenciais:

{
  "name": "Cobertura de Deteccao CTH, 2025 Q2",
  "domain": "enterprise-attack",
  "description": "Verde 3 = deteccao validada; amarelo 1 = parcial; vermelho 0 = ausente",
  "techniques": [
    {
      "techniqueID": "T1059.001",
      "score": 3,
      "comment": "KQL 4104 ofuscado; validado em SIM.4 em 2025-03"
    },
    {
      "techniqueID": "T1003.001",
      "score": 1,
      "comment": "visibilidade via Sysmon 10, regra em fase de teste"
    }
  ],
  "gradient": { "colors": ["#ff6666", "#ffe766", "#8ec843"], "minValue": 0, "maxValue": 3 }
}

O degradê do exemplo usa os mesmos três níveis da convenção CTH, mapeando score 0 a 3 nas cores vermelho, amarelo e verde. Camadas reais costumam registrar também a versão da matriz e a data de geração, metadados que mantêm o arquivo compatível com as atualizações do Navigator.

3. Tipos de Camada Úteis

Uma única camada responde a uma única pergunta. Empilhar tudo em um mapa só gera ruído, então
o programa deve manter um conjunto pequeno de camadas com finalidades distintas e documentadas.
O conjunto mínimo a seguir cobre as perguntas que aparecem em praticamente todo ciclo de
planejamento de detecção, e cada uma delas tem uma fonte de entrada diferente, o que facilita
a automação da geração.

A camada de visibilidade merece destaque porque costuma ser a mais reveladora no primeiro
ciclo: muitas técnicas ficam vermelhas não por falta de regra, mas por falta de fonte de
dados, e nenhuma quantidade de engenharia de detecção resolve isso. A camada de relevância,
por sua vez, evita o erro de tratar as centenas de técnicas da matriz como igualmente
importantes, calibrando toda a leitura posterior pelo que ameaça a organização.

4. Como Ler um Heatmap por Tática

A leitura começa pelas linhas vazias e pelas assimetrias entre táticas. Linhas vermelhas em
Reconnaissance e Initial Access, por exemplo, são comuns em ambientes jovens e têm leitura
dupla: a tática de reconhecimento externo é parcialmente visível apenas com telemetria de
superfície (INS.3), enquanto Initial Access vermelho em um ambiente com WAF e gateway de
e-mail sugere que os logs desses controles não estão sendo convertidos em regras. Já uma
tática de Discovery com boa cobertura verde, combinada com Persistence vermelha, indica um
programa que enxerga varreduras internas mas não presta atenção no que o adversário faz para
ficar, padrão frequente quando as detecções herdadas vieram de feeds de rede.

Padrões típicos e suas interpretações possíveis:

• Toda a matriz vermelha: o programa está no início; priorize telemetria básica de endpoint
  antes de qualquer regra sofisticada, porque sem fonte de dados não há cobertura possível.
• Verde concentrado em Command and Control com Credential Access vermelho: cobertura
  reativa orientada a IOC; migração para detecção comportamental de credenciais é o próximo
  passo natural, com hunting de LSASS (T1003.001) como candidato imediato.
• Amarelo dominante: o ambiente coleta dados e tem regras, mas não valida; um ciclo de
  simulação do SIM.3 e SIM.4 converte boa parte do amarelo em verde ou revela falsos positivos.
• Cobertura desigual dentro da mesma tática, ou verde concentrado nas sub-técnicas de um
  único produto: investigue se reflete priorização deliberada ou dependência de fornecedor
  único, cuja queda de agente derrubaria a tática inteira.

5. Combinação de Camadas e Priorização

O valor analítico máximo aparece quando camadas são combinadas. A interseção entre a camada de
relevância de ameaça (score alto em técnicas usadas pelos atores prioritários) e a camada de
cobertura de detecção (score baixo) produz a lista objetiva de prioridades: técnicas que
ameaçam de verdade e hoje não são detectadas. Essa interseção é a entrada direta do backlog do
MAP.4, e a operação é simples de automatizar porque ambas as camadas são JSON.

import json

relevancia = json.load(open("camada_relevancia.json"))
deteccao = json.load(open("camada_deteccao.json"))
score_det = {t["techniqueID"]: t.get("score", 0) for t in deteccao["techniques"]}

prioridades = []
for t in relevancia["techniques"]:
    if t.get("score", 0) >= 2 and score_det.get(t["techniqueID"], 0) == 0:
        prioridades.append(t["techniqueID"])
print("Tecnicas relevantes sem deteccao:", sorted(prioridades))

Uma segunda combinação útil cruza a camada de visibilidade com a de detecção: técnicas com
telemetria presente e detecção ausente são os fechamentos mais baratos, pois exigem apenas
regra, e não novo projeto de coleta. Já as técnicas sem visibilidade e com alta relevância
constituem a lista de projetos de coleta, mais caros e mais lentos, que precisam entrar no
planejamento com lead time realista.

6. Versionamento e Automação das Camadas

Camadas do Navigator são arquivos JSON e, como tal, devem viver no Git junto com o restante do
catálogo de detecções. Cada mudança de cobertura entra como commit associado ao merge que
aprovou a regra, o que cria trilha de auditoria completa: é possível responder com precisão
quando uma técnica virou verde e qual evidência sustentou a mudança. Revisão por pares no pull
request evita que scores sejam alterados sem justificativa.

A geração deve ser automatizada a partir de duas fontes: o catálogo de detecções do AUT.3, de
onde saem as regras ativas, seus mapeamentos e níveis de confiança, e os resultados de
simulação do SIM.5, de onde sai a validação empírica. Um job agendado converte o catálogo em
camada, aplica o degradê padronizado e publica o resultado no local acordado, eliminando
atualização manual e garantindo consistência entre os relatórios. O trecho a seguir ilustra o
contrato de entrada desse job.

job: gera_camada_cobertura
fontes:
  - catalogo_deteccao: repositorio AUT.3, branch main
  - resultados_simulacao: exportacao SIM.5, ultimo ciclo
saida:
  - camada JSON versionada em Git; percentual por tatica para o MET.5
regras:
  - score 3 somente com validacao de simulacao recente
  - score 1 quando regra existe sem validacao
  - score 0 quando nao ha regra ativa

7. Boas Práticas de Apresentação para Gestão

Para a gestão, o heatmap deve ser apresentado com legenda fixa, comparação com o trimestre
anterior e um recorte por ator prioritário, e não como a matriz completa de centenas de
células. Uma prática eficaz é acompanhar o mapa de três números: percentual geral de técnicas
prioritárias cobertas, percentual por tática para as três táticas mais relevantes e a lista
top cinco de lacunas em fechamento. Evite cores fora da convenção e scores que só fazem sentido para
quem escreveu a camada; a legenda verde, amarelo e vermelho existe justamente para ser
interpretável sem contexto adicional. Toda apresentação deve deixar explícito que o mapa
reflete detecção validada, parcial ou ausente, e não risco residual da organização, que
depende de outros controles de prevenção e resposta. Essa distinção protege o programa de
promessas que o heatmap não sustenta.

8. Salvaguardas por Nível de Maturidade

9. Erros Comuns e Pontos de Atenção

• Pintar de verde o que nunca foi testado: o heatmap deixa de medir cobertura e passa a medir
  autoconfiança; a validação por simulação é o que dá valor ao verde.
• Manter uma camada única gigante com tudo dentro, ou usar a matriz completa como escopo: a
  pergunta que o mapa responde fica indecifrável e, sem o recorte de relevância do MAP.3, a
  discussão vira caça a 100% da matriz, meta inatingível e paralisante.
• Atualizar o heatmap manualmente em véspera de comitê: o documento perde autoridade na
  primeira divergência com o catálogo real.
• Esquecer de versionar, ou apresentar o heatmap como medida de risco total: sem histórico
  ninguém explica por que uma técnica mudou de cor, e o mapa mede detecção sobre a matriz,
  não prevenção, resposta ou resiliência, que vivem em outros controles.

10. Integração com Outros Controles do Framework CTH

O MAP.2 consome o catálogo do MAP.1 e do AUT.3, os resultados do SIM.5 e os perfis do MAP.3,
e entrega visualizações para o MAP.4 transformar em fila de lacunas priorizadas. Os recortes
por ator alimentam o TH.5 na priorização de hipóteses de hunting, porque táticas vermelhas de
atores prioritários são candidatas naturais a hunt. A camada de visibilidade orienta o DAT.1
e o DAT.2 na expansão de coleta, e o reporte executivo do MAP.2 alimenta diretamente o
dashboard do MET.5. A evolução programada dessas camadas ao longo dos trimestres é governada
pelo MAP.5, que define cadência, gatilhos e metas.