Criação de Camadas de Cobertura

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK e às ferramentas
que sustentam sua operação. Aqui trata-se do ATT&CK Navigator e do conceito de
layer, a unidade de visualização que transforma o framework em mapa executável
de cobertura. Dialoga com as notas MAP.2 e MAP.4 do Framework CTH, com a nota
de Cobertura por Tática ATT&CK do capítulo 18 e com a nota seguinte de Heatmaps
de Evolução Temporal, que automatiza o que esta nota ensina a construir à mão.

1. Contexto e Posicionamento na Biblioteca

O ATT&CK Navigator é a aplicação web oficial do MITRE para manipular o framework visualmente, e a layer é seu formato de arquivo nativo: um documento JSON que associa pontuações, cores e comentários a técnicas e subtécnicas. Toda a disciplina de medir cobertura de detecção, registrar caças executadas e comparar adversários relevantes na biblioteca pressupõe que o leitor saiba ler, escrever e versionar layers. Sem esse domínio, as métricas do capítulo 11 e do grupo MAP do Framework CTH ficam presas em planilhas que ninguém confia.

Esta nota é o manual prático de criação de camadas. Ela define a estrutura do JSON, apresenta os três tipos de camada mais úteis para um programa de CTI e Threat Hunting, mostra o passo a passo da camada de detecção e ensina a exportar, combinar e versionar layers como artefatos de engenharia. A leitura preparatória recomendada é a nota de Cobertura por Tática ATT&CK, que define os números que a camada vai exibir, e a nota de Detection Strategies e Analytics, que explica de onde vêm as expectativas de detecção da v18 em diante.

2. O Navigator e o Conceito de Layer

Uma layer nunca altera o ATT&CK em si; ela é apenas uma visão anotada sobre ele. O documento guarda a versão do ATT&CK e do Navigator para a qual foi criada, a lista de técnicas pontuadas, a configuração de gradiente de cores e metadados de contexto. Quando o Navigator carrega uma layer construída para a v17 sobre a v19, o resultado é um mapa com buracos silenciosos, porque técnicas renomeadas ou movidas não são encontradas. Por isso, a primeira regra de higiene é fixar a versão no campo versions e revalidar a layer a cada atualização do framework, tema da nota de Migração de Mapeamentos e Controles deste capítulo.

O segundo princípio é que layer é artefato de trabalho, não print de tela. Uma boa camada carrega comentários por técnica com evidência, data e responsável, e metadados que ligam a pontuação a fontes verificáveis, como o identificador de um ticket, o nome de uma regra Sigma ou o registro de uma caça no repositório do time. A camada que circula em comitê deve ser reconstrutível a partir de dados brutos; caso contrário, ela deixa de ser métrica e vira marketing.

3. Estrutura JSON de uma Camada

A layer é um objeto JSON plano, legível por qualquer script. Os campos de primeiro nível descrevem o contexto e a apresentação, e o campo techniques é a carga útil analítica. Cada entrada de técnica usa techniqueID e, opcionalmente, tactic para desambiguar técnicas que aparecem em mais de uma tática, como T1106, presente em Execution e em outros contextos conforme a versão. A tabela a seguir resume os blocos que todo time deve conhecer de memória.

O campo score aceita valores numéricos e é interpretado pelo gradiente escolhido, enquanto color fixa uma cor que sobrepõe o gradiente quando é preciso marcar estados qualitativos, como vermelho para ausência total de dado. O campo comment é texto livre indexado pelo Navigator, e metadata aceita pares nome e valor, que permitem anexar identificadores de sistemas externos sem poluir o comentário legível.

4. Os Três Tipos de Camada de um Programa Maduro

A prática consolidada na biblioteca usa três famílias de camada, mantidas separadas e combinadas por operações. A camada de cobertura de detecção pontua cada técnica segundo a capacidade real de alertar, não segundo a promessa de ferramenta. A camada de caças executadas registra onde o time já caçou e com que resultado, funcionando como memória de longo prazo do programa de hunting. A camada de adversários relevantes, sobrepondo grupos como APT29, FIN7 e Scattered Spider, responde a pergunta prioritária dos PIRs: contra o que nós precisamos estar cobertos primeiro.

Manter as três camadas separadas é o que permite responder perguntas compostas sem manipular dados. A pergunta "onde os meus três adversários prioritários agem e eu não tenho detecção nem histórico de caça" é uma operação de três layers, executada no Navigator ou em script, e não uma estimativa de reunião.

As perguntas compostas mais úteis do programa são sempre combinações dessas camadas, e vale fixá-las para que o comitê aprenda a pedi-las por nome.

• Onde os adversários prioritários agem e não há detecção acima do nível 3, que é o recorte do relatório de lacunas exigido pelo controle MAP.4.
• Onde já houve caça nos últimos dois trimestres e a detecção ainda não absorveu o que a caça aprendeu, o que alimenta a ponte de hunting para detecção do capítulo 18.
• Quais técnicas da camada de adversários nunca foram testadas por BAS no período, que é a fila de entrada da rotina de purple teaming do capítulo 19.

5. Camada de Detecção Passo a Passo

A construção da camada de detecção segue uma sequência que transforma o inventário de regras em pontuação defensável. O processo abaixo presume o repositório de detecção do capítulo 18 como fonte, mas vale para qualquer inventário que tenha regra, técnica ATT&CK associada e data de último teste.

• Extrair do repositório a lista de regras ativas com seus IDs ATT&CK, reunindo em um único conjunto a visão de analytics do SIEM, regras Sigma e detecções de EDR, porque cobertura que ignora uma das três fontes é subestimação sistêmica.
• Classificar cada técnica pelo nível de maturidade acordado na biblioteca, de 0 a 5, usando a tabela de níveis da seção seguinte, e nunca pelo número de regras, porque três regras ruidosas valem menos que um analytic testado.
• Anotar em comment a evidência da pontuação com data, e em metadata os identificadores externos, ticket e caminho da regra, garantindo que qualquer revisor atravesse do mapa até a fonte em dois cliques.
• Recortar por domínio e plataforma com filters, gerando camadas separadas para endpoint, cloud e SaaS, pois médias compostas escondem diferenças de maturidade que o comitê precisa enxergar.
• Revisar a layer no Navigator antes de publicar, conferindo técnicas órfãs, cores incoerentes com a legenda e scores sem evidência, que são os três defeitos que descredibilizam o mapa.

A tabela de níveis abaixo é a escala de referência usada pelas camadas de detecção na biblioteca e alinhada com a nota de Cobertura por Tática ATT&CK do capítulo 18. Ela existe para impedir que pontuações mudem de significado entre times e trimestres.

6. Implementação Prática: JSON Mínimo Comentado

O documento abaixo é uma layer mínima e válida de cobertura de detecção, reduzida a quatro técnicas para caber na nota. Em produção a lista tem centenas de entradas, geradas por script a partir do inventário de regras, tema da nota de Heatmaps de Evolução Temporal.

{
  "name": "Cobertura de Deteccao - Enterprise - 2026-T3",
  "versions": { "attack": "19", "navigator": "5.1.0", "layer": "4.5" },
  "domain": "enterprise-attack",
  "description": "Score 0 a 5: 0 sem dado, 3 analytic parcial, 5 analytic testado",
  "filters": { "platforms": ["Windows", "Linux", "IaaS", "Office 365"] },
  "layout": { "layout": "side", "showID": true, "showName": true },
  "gradient": {
    "colors": ["#e04141", "#f5c242", "#8ec843"],
    "minValue": 0,
    "maxValue": 5
  },
  "techniques": [
    {
      "techniqueID": "T1003.001",
      "tactic": "credential-access",
      "score": 5,
      "comment": "Analytic de LSASS com Event ID 4656; testado em 2026-07-14",
      "metadata": [
        { "name": "regra", "value": "sigma/credential_access_lsass.yml" },
        { "name": "ticket", "value": "DET-2214" }
      ]
    },
    {
      "techniqueID": "T1059.001",
      "tactic": "execution",
      "score": 3,
      "comment": "Event ID 4104 habilitado, tuning de modulo suspeito pendente"
    },
    {
      "techniqueID": "T1078.004",
      "tactic": "defense-evasion",
      "score": 0,
      "comment": "Sem telemetria de console cloud; lacuna registrada no MAP.4"
    },
    {
      "techniqueID": "T1566.002",
      "tactic": "initial-access",
      "score": 4,
      "comment": "Detecção de link em e-mail coberta por gateway e EDR"
    }
  ],
  "legendItems": [
    { "label": "Sem telemetria", "color": "#e04141" },
    { "label": "Parcial", "color": "#f5c242" },
    { "label": "Testado", "color": "#8ec843" }
  ]
}

Três detalhes desse exemplo valem destaque operacional. O campo tactic desambigua a pontuação por tática, evitando que um score atribuído a Execution vaze para a mesma técnica vista em outra tática. Os metadados presos a cada técnica transformam a layer em índice do repositório de detecção, o que permite a um auditor atravessar do mapa até a regra em dois cliques. O score 0 explícito em T1078.004 é deliberado: técnica sem telemetria deve aparecer pintada, e não ausente, para não inflar artificialmente a média de cobertura.

7. Exportação, Combinação e Versionamento de Camadas

O Navigator exporta e importa layers pelo ícone de disco, mas o ciclo maduro inverte a dependência: a layer é gerada de dados e o Navigator serve de conferência visual. Para combinar camadas, o Navigator oferece a operação create layer from other layers, que recebe duas ou mais layers e um conjunto de operações por campo. Para score, as expressões usuais são min, max, sum, average e as lógicas and e or; para cor, prevalece a última layer da lista ou a operação de prioridade; para comment e metadata, a concatenação preserva as evidências de ambas as fontes.

O padrão de uso na biblioteca combina a camada de adversários com a de detecção usando a expressão and sobre o score normalizado, o que resulta em vermelho apenas onde o grupo relevante opera e a casa está cega, exatamente o recorte que alimenta MAP.4. A combinação de adversários entre si, por exemplo APT29 ou FIN7, com expressão or, produz o mapa de ameaça agregada do setor. Guardar o arquivo de operações junto das layers de entrada torna o cálculo reprodutível, o que permite reexecutar a mesma análise com dados do trimestre seguinte e comparar resultado com confiança.

O versionamento segue a disciplina de qualquer artefato de engenharia: as layers vivem em repositório Git, o nome do arquivo carrega domínio, trimestre e gerador, e cada mudança de score exige referência à evidência que a motivou. Quando a layer muda por causa de atualização do ATT&CK, o commit deve citar a versão nova e a nota de migração correspondente, mantendo a trilha entre framework e métrica.

Antes de publicar qualquer layer em comitê, a revisão abaixo custa dez minutos e evita os constrangimentos mais comuns da apresentação de cobertura.

• Conferir que cada técnica pontuada acima de 0 carrega comment com data e evidência, porque score sem evidência é declaração, não medição.
• Conferir que a legenda cobre todos os estados usados e que nenhuma cor fora do gradiente ficou sem rótulo.
• Conferir que filters e gradient são coerentes com o recorte prometido no título da camada, sem mistura de domínios.
• Conferir que a versão do ATT&CK declarada em versions é a adotada pelo programa naquele momento, e não a última disponível por inércia.
• Conferir que técnicas órfãs, renomeadas na última release, não aparecem esmaecidas no mapa sem explicação no relatório que as acompanha.

8. Erros Comuns e Pontos de Atenção

O erro mais caro é pontuar promessa de ferramenta como se fosse detecção real. Comprar um EDR não dá score 5 em dezenas de técnicas; dá telemetria, que é insumo para analytics que precisam ser escritos, testados e tunados. A segunda armadilha é misturar camadas num único arquivo, acumulando score de detecção e de relevância de adversário no mesmo campo, o que destrói a possibilidade de operações e torna o mapa inauditorável. Um terceiro erro frequente é esquecer o campo tactic e descobrir, na revisão trimestral, que a mesma técnica carrega dois scores conflitantes porque duas pessoas pontuaram táticas diferentes.

Também é comum tratar gradientes como escolha estética. O gradiente define o que salta aos olhos do comitê, e faixas mal calibradas, por exemplo minValue 0 e maxValue 100 com scores só entre 2 e 3, produzem um mapa monocromático que esconde os gaps. Um defeito silencioso adicional é publicar camada sem legenda coerente com as cores usadas, forçando o leitor a adivinhar estados, e com isso reabrir discussões que a legenda encerraria. Por fim, cuidado com layers herdadas de colegas de outras organizações: sem os metadados de evidência, herdar um score é herdar uma suposição alheia, e o time responde por ela.

9. Integração com o Restante da Biblioteca

Esta nota operacionaliza MAP.2, que exige heatmap de cobertura por tática, e fornece o formato de troca para MAP.5, que trata da evolução contínua da cobertura. A camada de adversários relevantes consome diretamente o trabalho do grupo ANA, em especial o mapeamento de TTPs de CTI.6, e a camada de caças é a saída natural do controle TH de documentação de descobertas do capítulo 7. No capítulo 18, a nota de Cobertura por Tática ATT&CK define os níveis de score usados aqui, e a nota de Medição de Cobertura e Gaps em Tempo Real do capítulo 19 mostra como BAS atualiza esses scores entre revisões manuais.

A nota seguinte, Heatmaps de Evolução Temporal, assume que o leitor domina este documento e automatiza todo o ciclo: geração de layers a partir de resultados de Caldera e de plataformas BAS, comparação de trimestres e publicação da evolução como série histórica. O par de notas forma, com o Navigator, o instrumento de medição contínua do programa completo de CTI e Threat Hunting descrito na esteira do Framework CTH.