MAP.4 - Análise de Lacunas de Detecção

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 define lacuna de detecção, método sistemático de
identificação, classificação por natureza e priorização de fechamento, com backlog vivo e
métricas. Seu papel é transformar os dados do MAP.1, MAP.2 e MAP.3 em uma fila racional de
trabalho que fecha primeiro as lacunas de maior risco.

1. Contexto e Posicionamento no Framework CTH

As lacunas de detecção são o lado negativo do mapa de cobertura: as técnicas que um adversário
pode exercer no ambiente sem gerar alerta, sem registro em log ou contra uma regra que existe
mas falha. Sem análise sistemática, a melhoria da detecção acontece por intuição, por pressão
de fornecedor ou pelo último incidente na memória, e lacunas críticas podem permanecer abertas
enquanto recursos se concentram em detecções de baixo valor. O MAP.4 substitui esse
comportamento por um processo repetível, que cruza três fontes de verdade e entrega uma fila
priorizada com dono e prazo.

O controle conecta-se a todos os grupos do framework: recebe cobertura do MAP.1 e MAP.2,
relevância do MAP.3 e validação empírica do SIM.5, e devolve trabalho concreto para DAT.x,
AUT.3, PRT.x e SIM.4. É também um dos controles que mais claramente traduz o programa de CTI e
hunting em linguagem de gestão, porque cada lacuna fechada pode ser narrada como risco
reduzido com custo e prazo associados.

2. Definição de Lacuna de Detecção

Uma lacuna é qualquer técnica relevante para a organização em uma de três condições. A
primeira é técnica sem telemetria: o ambiente não produz o dado que permitiria observar a
técnica, como não coletar criação de tarefa agendada em servidores Windows, caso em que
nenhuma regra futura funcionará enquanto a fonte não existir. A segunda é técnica com
telemetria e sem detecção: o dado chega ao SIEM, mas não existe regra, correlação ou análise
analítica que o consuma, o que caracteriza a lacuna mais barata de fechar. A terceira é
detecção não validada: a regra existe e dispara, mas nunca foi testada contra execução real da
técnica, de modo que sua cobertura é uma hipótese e não um fato.

Essa tipologia evita o erro de tratar lacuna como binário. Técnica coberta por detecção
parcial, que funciona apenas em um subconjunto de sistemas ou só para uma variante do
comportamento, também é lacuna, e deve entrar na fila com escopo explícito do que está e do
que não está coberto. A definição adotada deve estar escrita no documento do programa, porque
métricas de cobertura só são comparáveis entre trimestres quando o critério de coberto é
estável.

3. Identificação de Lacunas

A identificação nasce do cruzamento de três camadas de informação. Da cobertura teórica vem o
MAP.1 e o heatmap do MAP.2, que mostram técnicas com detecção ausente ou parcial. Da
relevância vêm os perfis de atores do MAP.3 e a avaliação de ameaça do CTI.2, que mostram quais
técnicas têm probabilidade real de aparecer no ambiente. Da validação empírica vêm os
resultados de simulação do SIM.4 e a medição do SIM.5, que expõem detecções que existem no
catálogo mas falham na prática, além dos achados de hunting e incidentes, que revelam técnicas
nem sequer documentadas nos perfis.

Uma forma operacional de executar o cruzamento é comparar as camadas JSON do Navigator, como
ilustrado no MAP.2, e enriquecer o resultado com os registros de simulação. O produto é uma
lista de técnicas candidatas, que passa por triagem para virar lacuna formal: cada candidata é
checada contra os ativos da organização, porque técnica que depende de plataforma inexistente
no parque não é lacuna real, e contra o cenário do setor, para filtrar ruído.

# Entradas: camadas JSON do Navigator e export de resultados de simulacao
lacunas = []
for t in relevancia["techniques"]:
    tid = t["techniqueID"]
    if t.get("score", 0) >= 2 and score_det.get(tid, 0) == 0:
        lacunas.append({"tecnica": tid, "natureza": "a_confirmar",
                        "origem": ["map.2", "map.3"]})

A triagem final deve ser revisada por quem conhece a arquitetura, para classificar a natureza
de cada lacuna conforme a tipologia da próxima seção e evitar que a fila cresça com itens
irreais. Técnicas que dependem de plataforma não existente no parque saem da lista com
justificativa registrada, e não silenciosamente, preservando a confiabilidade da contagem.
O resultado da triagem é a lista formal de lacunas que entra no backlog da seção de
acompanhamento.

4. Classificação de Lacunas por Natureza

A natureza da lacuna define o tipo de projeto de fechamento, custo estimado e responsável
provável. Classificar corretamente evita a confusão mais comum da área: pedir ao time de
detecção uma regra que é impossível sem fonte de dados nova. A tabela a seguir resume as
quatro naturezas operacionais encontradas com mais frequência na prática de mercado, com a
ação típica e o custo relativo de fechamento.

Uma lacuna pode ter natureza composta, por exemplo telemetria parcial em parte do parque e
ausência de regra no restante. Nesses casos, o registro no backlog deve quebrar a lacuna em
sub-itens por natureza, porque os donos e os prazos são diferentes, e a contagem de
fechamento fica honesta.

5. Priorização do Fechamento

A priorização equilibra três eixos: o risco do ator, medido pela presença da técnica nos
perfis de ameaça alta do MAP.3; a criticidade do ativo, herdada do inventário do INS.1 e da
segmentação do ambiente; e o custo de fechamento, derivado da natureza da lacuna. A matriz a
seguir é um exemplo ilustrativo de como combinar os eixos em prioridade de trabalho.

A classificação em quatro níveis do framework segue a mesma lógica: lacuna crítica combina
ausência total de detecção com alta probabilidade de exploração por ator relevante; lacuna
alta envolve ausência ou cobertura parcial com probabilidade média; lacuna média combina
cobertura parcial com probabilidade baixa; e lacuna baixa envolve detecção de alta confiança
ou probabilidade muito baixa. A justificativa de cada classificação deve estar escrita, pois
ela é o que permite revisar prioridade quando o cenário muda sem refazer a análise do zero.

6. Planos de Fechamento por Tipo

Cada lacuna recebe um plano coerente com a sua natureza. Lacunas de falta de fonte de dados
geram projetos de coleta no DAT.1 e no DAT.2, com análise de impacto de agente, volume de log e
licença, e só depois de implantada a fonte a lacuna muda de natureza para falta de regra.
Lacunas de falta de regra entram no pipeline do AUT.3 como requisição de detecção, com
hipótese, consulta Sigma ou KQL proposta e critério de aceitação. Lacunas de regra quebrada
geram ticket de correção com teste de regressão, usando o cenário que expôs a falha como caso
de teste permanente.

Lacunas cuja detecção é inviável ou insuficiente têm o plano voltado à prevenção, movendo o
fechamento para o PRT.1, PRT.2 ou PRT.3 conforme a superfície, com o registro indicando que a
cobertura será preventiva e não analítica. Por fim, lacunas de detecção não validada geram
agenda de simulação no SIM.4, e só saem da fila quando o teste comprova o disparo no tempo
esperado. Em todos os casos, o fechamento é declarado apenas quando a evidência está registrada
no catálogo do MAP.1, mantendo o ciclo honesto.

7. Backlog Vivo com Dono

O backlog de lacunas é um artefato vivo, revisado mensalmente com a equipe de detecção e
trimestralmente com a alta direção. Cada item deve ter dono nomeado, prazo acordado, natureza,
prioridade e link para a evidência de fechamento. Itens sem dono não são backlog, são lista de
desejos, e a experiência de mercado mostra que lacuna sem dono não fecha. O formato mínimo por
item pode seguir o modelo abaixo.

id: LAC-2025-014
tecnica: T1053.005
descricao: "criacao de tarefa agendada sem alerta em servidores Windows"
natureza: falta_de_regra
prioridade: critica
justificativa: "tecnica central do ator principal; telemetria 4698 presente"
dono: "analista de deteccao, equipe SIEM"
prazo: 2025-05-15
plano: "regra Sigma com teste no golden dataset e simulacao SIM.4"
evidencia_fechamento: null
status: em_progresso

A fila vive no sistema de trabalho da equipe, seja Jira, Azure DevOps ou quadro do projeto de
detecção, e o catálogo YAML espelha o estado para as automações do MAP.2. A disciplina de
dono e prazo é o que conecta o MAP.4 ao calendário real do time; sem isso, o backlog cresce
monotonicamente e a confiança da gestão no processo se perde.

8. Métricas de Fechamento

A métrica central é a curva de lacunas abertas por prioridade ao longo do tempo, com meta de
redução, por exemplo 20% por trimestre, para os níveis crítico e alto. Complementam o painel o
tempo médio de fechamento por natureza, que revela gargalos entre coleta e detecção; a
proporção de lacunas críticas com mais de 90 dias abertas, indicador direto de risco aceito
involuntariamente; e a taxa de reabertura, que mede lacunas fechadas no papel que a simulação
reabriu na prática. Esses indicadores alimentam o MAP.5 e o reporte executivo do MET.5.

Cuidado com o incentivo perverso de medir apenas volume fechado: regra fácil sobre técnica
irrelevante fecha item rápido e não reduz risco. Por isso a contagem deve ser ponderada pela
prioridade, e o relatório trimestral deve sempre mostrar a composição do que foi fechado, com
a justificativa de cada classificação auditável no histórico do item.

9. Salvaguardas por Nível de Maturidade

10. Erros Comuns e Pontos de Atenção

• Tentar cobrir tudo: a fila que lista igualmente todas as técnicas da matriz é inexecutável;
  o recorte de relevância do MAP.3 é o que torna o backlog realista.
• Lacuna sem dono: item sem responsável nomeado e sem prazo não fecha; a governança do
  backlog precisa cobrar dono desde a abertura.
• Confundir lacuna de visibilidade com lacuna de detecção: abrir regra para técnica sem fonte
  de dados gera ticket impossível e desgasta a equipe; a natureza vem primeiro.
• Declarar fechamento sem evidência: lacuna encerrada por "regra implantada" sem simulação
  tende a voltar; o critério de saída deve exigir validação registrada.
• Priorizar pela facilidade: fechar primeiro o que é barato e não o que é crítico produz
  métrica bonita com risco constante; a ponderação por prioridade existe para impedir isso.
• Ignorar lacunas reveladas em exercícios: cada SIM.x que expõe falha e não gera item no
  backlog desperdiça o custo do teste e transmite à equipe que o exercício é ritual.

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

O MAP.4 é o consumidor direto do MAP.2 e do MAP.3 e o fornecedor de trabalho para o DAT.1 e
DAT.2, quando a lacuna é de fonte, o AUT.3, quando é de regra, o SIM.4, quando é de validação,
e o PRT.x, quando a resposta é prevenção. Os achados dos hunts executados conforme o TH.4 e os
incidentes do IR.x realimentam a análise com técnicas observadas que nenhum perfil documentou.
Na medição, a curva de fechamento integra o painel do MET.5, e a maturidade do processo de
lacunas é critério de avaliação no GOV, porque fechar lacunas de forma sistemática é uma das
expressões mais concretas de programa de detecção maduro.