Heatmaps de Evolução Temporal

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK e às ferramentas
de visualização do framework. Trata o heatmap do ATT&CK Navigator como registro
histórico do programa: cobertura por trimestre, comparação de períodos e
gradiente de cor por score, gerados automaticamente a partir de resultados de
Caldera e de plataformas BAS. Dialoga com a nota anterior de Criação de Camadas
de Cobertura, com Medição de Cobertura e Gaps em Tempo Real do capítulo 19 e
com os KPIs de cobertura do capítulo 11.

1. Contexto e Posicionamento na Biblioteca

Um heatmap pontual responde como estamos; um heatmap evolutivo responde para onde estamos indo, e é essa segunda pergunta que sustenta orçamento, prioriza engenharia e demonstra valor ao comitê. Esta nota ensina a usar o Navigator como instrumento de série temporal: cada trimestre fecha uma layer congelada, a comparação entre layers vira evidência de progresso ou regressão, e a geração deixa de ser manual para nascer dos resultados de testes automatizados de detecção.

A nota é a continuação direta de Criação de Camadas de Cobertura, que define o formato de layer e os três tipos de camada. Aqui o foco muda da construção manual para o pipeline: como extrair resultados de Caldera e de ferramentas de BAS, como converter esses resultados em scores, como publicar o heatmap trimestral e como evitar que a automação codifique erros com eficiência crescente.

2. Heatmap como Registro de Evolução

O heatmap do Navigator colore cada técnica segundo o score e o gradiente configurados, e é essa coloração, repetida ao longo do tempo, que forma a série temporal. A disciplina central é o congelamento: ao fim de cada trimestre, a layer corrente é copiada para um arquivo imutável com nome de período, por exemplo deteccao-enterprise-2026-T2.json, e o repositório Git garante que nenhum score histórico seja reescrito silenciosamente. A comparação só é honesta se os dois períodos forem reconstrutíveis do mesmo jeito.

O gradiente deve ser estável entre períodos, com minValue e maxValue fixos, porque mudar a escala muda as cores sem mudar os fatos e fabrica progresso visual falso. A recomendação da biblioteca é manter a escala 0 a 5 dos níveis de detecção e reservar cores fortes para os extremos, vermelho no zero e verde no cinco, com âmbar no meio. Comentários por técnica devem carregar a data da última evidência, o que permite a um revisor distinguir um score antigo confiável de um score que já deveria ter sido revalidado.

A escolha do gradiente merece decisão consciente, porque é ela que o comitê lê primeiro. A tabela abaixo compara três configurações usuais e quando cada uma serve melhor, lembrando que qualquer configuração vale para a série inteira uma vez adotada.

3. Comparação de Períodos e Métricas de Evolução

O Navigator compara camadas pela operação de combinar duas layers com expressão de score configurada, mas a comparação interpretável costuma exigir cálculo externo. O padrão prático é carregar as duas layers em script, computar a diferença por técnica e produzir três camadas derivadas: a do período novo, a delta colorida por ganho e perda, e a média móvel de dois trimestres para amortecer ruído de tuning. A tabela a seguir lista as métricas de evolução que o grupo MET da biblioteca espera ver no relatório trimestral.

Regressão é a métrica mais valiosa e a mais ignorada. Cobertura cai por causas banais: regra desativada por ruído, plataforma migrada sem recriar analytics, técnica movida em nova versão do ATT&CK sem reatribuição. O heatmap evolutivo existe justamente para expor essas perdas na janela de um trimestre, antes que virem surpresa em teste de intrusão ou incidente.

O resumo de delta que acompanha o heatmap segue o formato abaixo, gerado pelo job de comparação e anexado à ata do comitê. Ele vale tanto quanto a imagem do mapa, porque é o resumo que sobrevive quando a reunião termina.

Delta 2026-T3 contra 2026-T2, dominio enterprise
Ganhos: 12 tecnicas subiram, media de 2,9 para 3,3
Regressoes: 4 tecnicas, causa comum desativacao de canal de logs
Gaps novos: 1 tecnica de adversario prioritario sem telemetria
Area fria: 87 tecnicas com evidencia maior que 2 trimestres
Acao proposta: reativar canal e converter 6 invisiveis em backlog DET

O congelamento do período vai além do arquivo de layer, e registrar o pacote completo é o que permite reabrir qualquer comparação meses depois.

• A layer do período com o hash do commit, que identifica o arquivo exato usado nas comparações daquele ciclo.
• O runs.jsonl dos testes que gerou os scores, com a versão do simulador registrada, porque a mesma técnica pode se comportar diferente entre versões do emulador.
• O resumo de delta e a ata da revisão humana, com os ajustes manuais justificados, para que a diferença entre automação e decisão fique explícita.
• A versão do ATT&CK vigente, porque a nota de migração deste capítulo precisa saber sobre qual base a série foi calculada.

4. Geração Automática a partir de Resultados de Testes

A fonte de dados ideal para o score de detecção é a execução controlada de técnicas contra a produção ou contra ambiente espelhado, registrada por ferramentas de duas famílias. A primeira família é a emulação com Caldera e Atomic Red Team, em que cada execução tem identificador de técnica ATT&CK e telemetria esperada conhecida. A segunda família é a plataforma de BAS comercial, que produz relatórios estruturados de sucesso e falha de detecção por técnica. Em ambos os casos, o contrato é o mesmo: uma tabela com techniqueID, tática, data da execução, resultado de alerta e identificador da regra que deveria ter alertado.

A conversão em score segue regra determinística para evitar subjetividade. Execução detectada automaticamente com regra conhecida gera no mínimo 4; detectada apenas em telemetria de caça manual gera 2; executada e invisível gera 0; técnica não executada no período mantém o score anterior, com o comentário marcando a idade da evidência. O script central do pipeline não conhece ATT&CK em profundidade: ele só liga resultados de teste a entradas de layer, e a inteligência fica nos dados de entrada.

import json, pathlib

FAIXA = {"detectado": 4, "telemetria": 2, "invisivel": 0}

def carregar_resultados(caminho):
    # Linhas: techniqueID, tactic, data, resultado, regra
    return [json.loads(l) for l in pathlib.Path(caminho).read_text().splitlines()]

def layer_base():
    base = json.loads(pathlib.Path("layer-2026-T2.json").read_text())
    for t in base["techniques"]:
        t["comment"] = t["comment"] + " | evidencia: " + str(t.get("idade", "n/a"))
    return base

def aplicar_resultados(layer, resultados):
    indice = {t["techniqueID"]: t for t in layer["techniques"]}
    for r in resultados:
        tec = indice.setdefault(r["techniqueID"], {
            "techniqueID": r["techniqueID"], "score": 0, "comment": ""
        })
        tec["score"] = FAIXA[r["resultado"]]
        tec["comment"] = "Teste {0} em {1}; regra {2}".format(
            r["resultado"], r["data"], r.get("regra", "sem regra"))
    layer["techniques"] = list(indice.values())
    layer["name"] = layer["name"].replace("2026-T2", "2026-T3")
    return layer

if __name__ == "__main__":
    atual = aplicar_resultados(layer_base(), carregar_resultados("caldera_runs.jsonl"))
    pathlib.Path("layer-2026-T3.json").write_text(json.dumps(atual, indent=2))

Duas precauções mantêm essa automação honesta. A primeira é exigir par de execução e verificação: um teste que não pode provar que a telemetria chegou ao SIEM não pode baixar score, porque o falso negativo pode estar no coletor e não na regra. A segunda é manter o manual disponível: técnica que o simulador não suporta continua sendo pontuada por revisão humana, e a layer registra no metadata que aquela evidência é manual e não automatizada.

5. Fluxo de Geração Automática do Heatmap Trimestral

O fluxo completo, aplicado na cadência trimestral, tem seis passos que viram jobs encadeados. A sequência abaixo é o contrato do pipeline e vale tanto para Caldera quanto para BAS, trocando-se apenas o conector de entrada.

1. No dia 1 do trimestre, o job extrai do Caldera (API) e do BAS os resultados
   do trimestre fechado e grava runs.jsonl versionado.
2. O conector normaliza identificadores para o ATT&CK vigente, resolvendo
   técnicas movidas ou renomeadas conforme a nota de Migração de Mapeamentos.
3. O construtor de layer aplica a regra de score determinística sobre a layer
   base do trimestre anterior e grava layer-YYYY-TN.json proposta.
4. O job de comparação gera a delta contra o trimestre anterior e monta um
   resumo: ganhos, regressões e gaps de adversários prioritários.
5. Um humano revisa a proposta no Navigator, ajusta casos de borda e aprova
   o commit, com comentários citando tickets de evidência.
6. A layer aprovada é publicada no diretório de períodos e o dashboard do
   comitê aponta sempre para a layer do trimestre corrente.

A cadência pode ser mais fina sem custo grande: mensal para o recorte de adversários prioritários, que muda rápido conforme a CTI, e trimestral para a cobertura completa, que muda devagar. O erro a evitar é rodar o pipeline de ponta a ponta sem revisão humana: a delta trimestral é exatamente onde anomalias de automação aparecem, como dezena de técnicas rebaixadas por um simulador que parou de alcançar os agentes.

6. Portões de Qualidade do Pipeline

Automatizar a geração sem portões de qualidade apenas industrializa erro. Cada job do pipeline deve parar e alertar quando uma das condições abaixo ocorre, e o alerta deve exigir decisão humana antes de publicar a layer. O conjunto é pequeno e cobre as falhas observadas na prática.

• Divergência de escala: o construtor detecta gradientes com minValue ou maxValue diferentes entre a layer base e a proposta, e bloqueia a publicação até alguém confirmar a mudança consciente de escala.
• Volume anômalo de mudanças: mais de 15 por cento das técnicas mudando de score num único ciclo dispara revisão, porque o esperado é evolução gradual e não reescrita do mapa.
• Regressões sem explicação: toda técnica com queda de score precisa carregar resultado de teste correspondente no runs.jsonl, e queda sem teste é tratada como defeito do conector.
• Evidência vencida: técnicas cuja última evidência tem mais de dois trimestres são marcadas na legenda como área fria, impedindo que cobertura antiga seja exibida como atual.
• Falha de par de execução: teste que não encontrou a telemetria esperada no SIEM dentro da janela acordada é marcado como inválido, e não como invisível, até verificação do coletor.

Esses portões transformam o pipeline em sistema auditável. Quando o comitê questiona um número, a resposta é o portão que aprovou o dado, e a discussão muda de confiança genérica para verificação pontual.

7. Caso Prático: Do Teste Atomic Red Team ao Delta

Considere o trimestre que fecha em 30 de setembro de 2026. O time executou o perfil de Atomic Red Team contra dez endpoints canário, cobrindo 45 técnicas, e o Caldera rodou duas sequências de emulação de APT29. O resultado bruto mostra 28 execuções detectadas automaticamente, 9 visíveis apenas em telemetria de caça, 6 invisíveis e 2 invalidadas por falha de coletor. O conector converte tudo em scores, o construtor gera a layer proposta, e a comparação contra o T2 revela: média subiu de 2,9 para 3,3, quatro regressões, todas rastreadas a uma desativação acidental de canal de logs no SIEM durante migração de índices, e um gap novo em T1078.004 porque o adversário prioritário entrou na lista no trimestre.

Esse caso ilustra o valor real da série temporal: o número que moveu o comitê não foi a média que subiu, foi a descoberta de que uma mudança de infraestrutura de logs tinha apagado detecções três semanas antes, invisível a qualquer relatório pontual. A delta também virou requisito de trabalho para o time de detecção, com as 6 execuções invisíveis convertidas em backlog priorizado pela relevância para adversários.

8. Erros Comuns e Pontos de Atenção

O erro estrutural é deixar a escala de cores mudar entre períodos, o que compara cores em vez de comparar scores. O segundo é pontuar por volume de testes executados em vez de por resultado de detecção, transformando o heatmap em mapa de atividade do simulador. Um terceiro erro é ignorar técnicas não testadas: elas devem carregar o score anterior com idade de evidência registrada, porque tratá-las como zero destrói a série e tratá-las como cinco fabrica cobertura.

Também é comum automatizar a geração e esquecer a revisão, deixando regressões de coletor serem publicadas como fato no comitê. Outro deslize frequente é misturar em uma única série recortes com plataformas diferentes, por exemplo comparar um trimestre filtrado só de Windows com o trimestre anterior de domínio completo, e anunciar queda que é diferença de recorte. Por fim, cuidado com a tentação de publicar heatmaps diários: sem janelas acordadas, a série vira ruído, e o comitê para de olhar.

9. Integração com o Restante da Biblioteca

O pipeline desta nota alimenta diretamente os KPIs de CTI do capítulo 11, em particular a métrica de cobertura, e fornece a evidência de evolução que o controle MAP.5 do Framework CTH exige a cada ciclo. A conexão com o capítulo 19 é operacional: BAS contínuo e medição de gaps em tempo real são as fontes de dado que tornam o heatmap trimestral barato. Com o capítulo 18, a interface é o repositório de regras, cujos identificadores aparecem nos metadados das layers e permitem rastrear qualquer mudança de score até o commit que a causou.

No plano mais amplo da biblioteca, esta nota fecha o ciclo iniciado em Criação de Camadas de Cobertura: camadas definem a medição, heatmaps evolutivos provam que a medição anda, e a nota de Histórico de Versões e Impactos Operacionais deste mesmo capítulo garante que a base do mapa, o próprio ATT&CK, mude sem quebrar a série.