MAP.1 - Mapeamento de Controles CTH para ATT&CK

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 estabelece a fundação do vocabulário comum entre
CTI, Threat Hunting, detecção e resposta, vinculando cada controle do framework às técnicas
da matriz ATT&CK Enterprise. Seu papel é transformar a arquitetura defensiva em um mapa
verificável de cobertura, base para heatmaps, análise de lacunas e evolução contínua.

1. Contexto e Posicionamento no Framework CTH

O Framework CTH organiza o programa de CTI e Threat Hunting em oito grupos de controles, e o
grupo MAP é o responsável por amarrar todos eles à taxonomia do MITRE ATT&CK. Sem esse
vínculo, cada equipe fala sua própria língua: o SOC descreve alertas por nome de regra, o CTI
descreve campanhas por narrativa e o hunting descreve achados por consulta. O mapeamento de
controles para técnicas ATT&CK cria a camada de tradução que permite comparar cobertura,
comunicar riscos à gestão e identificar sistematicamente onde a defesa não chega.

O ATT&CK Enterprise organiza o comportamento adversário em 14 táticas, que representam o
objetivo do adversário em cada momento da intrusão, e centenas de técnicas e sub-técnicas,
identificadas por códigos no formato TXXXX e TXXXX.XXX. Quando cada controle do framework é
vinculado às técnicas que ele efetivamente combate, a organização passa a enxergar sua postura
defensiva como uma matriz: de um lado o que o adversário pode fazer, do outro o que a
organização consegue prevenir, detectar ou ao menos observar. Essa matriz é a matéria-prima de
todos os demais controles MAP.x.

2. Por que Mapear Controles para Técnicas

O primeiro ganho é a visibilidade do que cada controle combate na prática. Um controle como
PRT.1 (Proteção de Endpoint) não é uma caixa preta: ele detecta processos suspeitos, bloqueia
execuções não assinadas e fornece telemetria de processo, e cada uma dessas capacidades
corresponde a um conjunto específico de técnicas ATT&CK. Ao tornar esse vínculo explícito, o
gestor deixa de avaliar ferramentas por ficha comercial e passa a avaliá-las por cobertura
real contra técnicas priorizadas. A mesma visibilidade serve ao operador, que passa a saber
quais detecções dependem de qual ferramenta antes de planejar qualquer troca ou manutenção.

O segundo ganho é a identificação de sobreposição e lacuna. Sobreposições revelam investimento
redundante, por exemplo três ferramentas que geram o mesmo alerta de T1059 (Command and
Scripting Interpreter), enquanto lacunas revelam técnicas relevantes sem nenhum controle
associado. A análise de sobreposição também expõe dependências ocultas: se três detecções
dependem da mesma fonte de log e essa fonte cai, a cobertura despenca de uma vez.

O terceiro ganho é a linguagem comum. Auditorias internas, requisições de investimento,
relatórios de CTI e testes purple team passam a usar o mesmo identificador TXXXX, o que
elimina ambiguidade e permite benchmark com práticas de mercado. Essa padronização é condição
prévia para os controles MAP.2, MAP.4 e MAP.5 funcionarem com dados confiáveis.

3. Metodologia de Mapeamento em Passos

O mapeamento deve ser conduzido de forma sistemática, controle por controle, e documentado de
maneira reprodutível. Os passos recomendados são os seguintes.

1. Inventariar os controles implantados, listando para cada um o escopo real de operação,
   inclusive limites como cobertura de sistemas, versões de agente e sistemas sem suporte.
2. Descrever as capacidades e a telemetria de cada controle, separando três dimensões: o que
   o controle previne (ações bloqueadas), o que detecta (regras e alertas) e o que apenas
   observa (telemetria disponível para hunting).
3. Para cada capacidade, identificar as técnicas ATT&CK cobertas, sempre com evidência: a
   regra Sigma correspondente, o ID do evento Windows ou Sysmon, a consulta KQL/SPL ou o
   resultado de simulação que comprova a cobertura.
4. Classificar o nível de cobertura de cada vínculo em detecção, prevenção ou visibilidade,
   atribuindo confiança alta, média ou baixa conforme a evidência disponível.
5. Registrar a fonte de dados dependente de cada mapeamento, pois a cobertura é tão frágil
   quanto o log que a sustenta; esse vínculo alimenta a gestão de qualidade do DAT.5.
6. Validar os vínculos classificados como detecção por meio de simulação controlada (SIM.4 e
   SIM.5), reclassificando como cobertura parcial tudo aquilo que existe só no papel.
7. Publicar o resultado em camadas do ATT&CK Navigator e em catálogo versionado, garantindo
   que o mapa seja consumível por humanos e por automações.

A distinção entre mapeamento direto e indireto merece atenção. O mapeamento direto ocorre
quando o controle tem como objetivo explícito detectar ou mitigar uma técnica, como um WAF
configurado contra exploração web em relação a T1190. O mapeamento indireto ocorre quando o
controle contribui para a detecção sem ser projetado para ela, como a coleta de logs de
endpoint do DAT.1 que viabiliza visibilidade sobre dezenas de técnicas sem detectar nenhuma
por si só. Confundir os dois tipos infla artificialmente a cobertura e esconde dependências.

4. Exemplo de Tabela de Mapeamento

A tabela a seguir é um exemplo ilustrativo, com valores plausíveis e simplificados, e não um
mapa pronto para uso. Cada organização deve derivar suas próprias linhas a partir dos controles
efetivamente implantados e das evidências que possui.

Repare que DAT.1 aparece com cobertura de visibilidade, não de detecção: ele fornece os dados
que outras regras consomem. Esse cuidado evita o erro clássico de declarar que a coleta de logs
"detecta" técnicas, quando na verdade ela apenas viabiliza a detecção. Cada linha da tabela
deve apontar para a evidência concreta, e vínculos sem evidência devem ficar fora do mapa até
que a validação seja feita.

5. Manutenção do Mapeamento como Documento Vivo

O mapeamento envelhece rápido: novas detecções entram, fontes de log mudam, a própria matriz
ATT&CK ganha técnicas e sub-técnicas a cada versão trimestral do MITRE. Por isso o mapa deve
viver em repositório versionado, com catálogo legível por máquina, e não em planilha solta ou
slide de apresentação. Um formato simples de catálogo YAML por controle facilita automação e
revisão por diff.

controle: PRT.1
nome: Proteção de Endpoint (EDR-AV)
mapeamentos:
  - tecnica: T1059.001
    cobertura: [detecao, prevencao]
    confianca: alta
    evidencia: "alerta EDR de PowerShell ofuscado; bloqueio por política de execução"
    fonte_dados: "Sysmon Event ID 1; log do agente EDR"
    validado_por: "SIM.4 executado em 2025-03 (resultado: detectado em 4s)"
  - tecnica: T1562.001
    cobertura: [detecao]
    confianca: media
    evidencia: "alerta de desativação de proteção em tempo real"
    fonte_dados: "log do agente EDR"
    validado_por: "pendente de simulação"
atualizado_em: 2025-04-02
responsavel: "equipe de detecção"

A rotina de manutenção deve estar embutida no processo: toda nova regra aprovada no pipeline do
AUT.3 atualiza o catálogo no mesmo merge, toda simulação do SIM.4 atualiza o campo de
validação, e a revisão trimestral (MAP.1.4) consolida o estado. Alterações no mapa devem
seguir o mesmo rigor de pull request exigido das detecções, com revisão por pares, porque o
mapa sustenta decisões de investimento e relatórios executivos.

6. Erros de Mapeamento Frequentes

• Mapear um controle genérico como cobrindo "tudo": vínculos sem evidência específica tornam o
  mapa inútil para análise de lacuna, porque nenhuma técnica aparece como descoberta.
• Confundir prevenção com detecção: declarar detecção de técnicas que o controle apenas
  bloqueia impede que o SOC saiba o que fazer quando o bloqueio falha.
• Confundir visibilidade com detecção: ter o log não é ter a regra; os dois vínculos devem
  ser registrados em dimensões separadas.
• Mapear pela ficha comercial do fornecedor: alegações de marketing não substituem evidência
  própria; a regra é mapear o que foi demonstrado no ambiente.
• Ignorar cobertura parcial: marcar uma técnica como coberta quando a detecção só funciona
  em um subconjunto de sistemas cria falsa sensação de segurança.
• Deixar o mapa congelar: mapeamento revisado uma vez ao ano não representa o ambiente real
  e descredita todo o programa de métricas.

7. Uso do Mapa em Auditoria e Investimento

Em auditorias, o mapa funciona como evidência objetiva de controles: o auditor pode escolher
amostras de técnicas prioritárias e trilhar, do controle até a detecção validada, toda a
cadeia de responsabilidade. Essa trilha reduz a dependência de declarações verbais e dá ao
programa de segurança um artefato verificável, inclusive para exigências regulatórias que
pedem demonstração de capacidade de detecção.

Em decisões de investimento, o mapa responde a pergunta difícil com dados: qual lacuna fechada
produz o maior ganho de cobertura contra os atores relevantes? Ao sobrepor o mapa de controles
com o perfil de ameaça do CTI.2, a organização identifica que um único investimento, por
exemplo habilitar uma fonte de log, desbloqueia dez técnicas priorizadas, enquanto outro
investimento caro cobre uma técnica de baixa relevância. O mapa também quantifica o custo de
desligar uma ferramenta, mostrando exatamente quais técnicas perdem cobertura.

8. Salvaguardas por Nível de Maturidade

A progressão entre níveis deve ser intencional: uma organização no nível básico não precisa de
automação, precisa de um mapa correto e atualizado duas vezes ao ano no mínimo. O salto para
o intermediário vale a pena quando o mapa já é confiável, pois automação sobre dados errados
apenas industrializa o erro. Já o nível avançado pressupõe cadência trimestral consolidada,
com relatório de cobertura consumido pela gestão como rotina, e não como evento excepcional.

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

O mapa de controles alimenta diretamente o MAP.2, que transforma os vínculos em heatmaps
visuais, e o MAP.4, que cruza o mapa com perfis de atores para gerar a fila de lacunas. A
coleta do DAT.1 e do DAT.2 determina quais vínculos de visibilidade são reais, e o AUT.3
insere no mapa cada detecção aprovada no pipeline. As simulações do SIM.4 e a medição do
SIM.5 são a prova empírica que converte cobertura teórica em cobertura validada.

No eixo de inteligência, o CTI.6 produz o mapeamento de TTPs de relatórios e incidentes para
ATT&CK com a mesma taxonomia, garantindo que ameaça e defesa falem o mesmo idioma. No eixo de
governança, o GOV consome o percentual de cobertura como indicador de maturidade, e o MET.5
apresenta a evolução ao quadro executivo. Manter essa rede de dependências explícita é o que
impede que o mapa vire um documento morto em alguma pasta compartilhada.