Migração de Mapeamentos e Controles

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Define o
processo organizacional de migrar mapeamentos internos quando o framework
muda: inventário de mapeamentos, diff automatizado entre versões, reatribuição
de técnicas deprecadas e revogadas, e revisão de heatmaps e coberturas.
Dialoga com as notas de Evolução das Táticas e Técnicas, de Histórico de
Versões deste capítulo e com os controles MAP.1 a MAP.5 do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

Cada release do ATT&CK muda o chão sobre o qual a biblioteca construiu suas métricas: controles do grupo MAP apontam para técnicas, layers do Navigator carregam IDs, regras do SIEM citam técnicas em metadados, playbooks de resposta referenciam TTPs em títulos e filtros. Sem um processo de migração formal, o banco de mapeamentos apodrece em silêncio, e os números de cobertura continuam sendo publicados sobre um framework que já não é o que os números dizem medir.

Esta nota é o manual operacional da migração. Ela cobre o inventário dos mapeamentos, o diff automatizado entre versões do bundle, as regras de reatribuição para técnicas deprecadas e revogadas, a revisão de heatmaps e coberturas após a migração e o cronograma que encaixa tudo nas duas releases anuais. O princípio central é que migração é projeto com escopo, dono e critério de saída, não um ajuste feito por quem lembrou.

2. Por Que Mapeamento Desatualizado é Risco Ativo

Um mapeamento desatualizado produz três classes de dano, com gravidades distintas. O dano analítico é o mais silencioso: dashboards contam cobertura sobre IDs que não existem mais, e a média global parece boa porque o denominador está errado. O dano operacional aparece quando um playbook de resposta filtra alertas por técnica que foi renomeada ou fundida, e a caixa de busca simplesmente retorna vazio no pior momento. O dano de compliance é o mais visível: relatórios de risco que citam técnicas antigas perdem credibilidade perante auditoria e comitê, e o custo reputacional do dado ruim contamina todo o programa de CTI.

O risco cresce com o tempo entre releases adotadas, porque as mudanças se compõem: um time que pula duas versões acumula deprecações, revogações, mudanças de tática e mudanças de modelo de dados numa única migração, sem linha de base intermediária para comparar. A recomendação da biblioteca é nunca deixar a dívida atravessar mais de um ciclo semestral, e a tabela de versões da nota de Histórico de Versões deste capítulo fornece o calendário que sustenta essa disciplina.

3. O Processo de Migração em Seis Passos

O processo começa sempre pelo inventário. Mapeamentos vivem em mais lugares do que o comitê imagina: layers do Navigator, campos de metadados de regras Sigma e analytics do SIEM, notas do Framework CTH, playbooks de resposta, requisitos de teste de BAS, relatórios de CTI e até colunas de planilhas de priorização. O inventário deve registrar para cada mapeamento o ID citado, o artefato que o carrega, o dono do artefato e a forma de atualização, manual ou automatizada, porque o cronograma depende dessa classificação.

O passo seguinte é o diff automatizado entre a versão adotada e a nova, que produz três listas: técnicas novas, técnicas alteradas em revisão e técnicas deprecadas ou revogadas com seus substitutos. A reatribuição consome as listas na ordem de risco, deprecadas e revogadas primeiro, porque apontam para nada, depois alteradas, depois novas, que viram backlog de cobertura e não migração propriamente dita. A revisão final recalcula heatmaps e coberturas com os mapeamentos corrigidos, e a diferença em relação aos números pré-migração é a medida honesta do custo da mudança do framework, distinta do custo de maturidade do programa.

A recarga das layers merece checklist próprio, porque é o passo em que buracos aparecem silenciosamente no Navigator e são descobertos meses depois, no meio de uma apresentação.

• Procurar técnicas esmaecidas ou ausentes na layer recarregada, que indicam IDs que não existem mais na versão nova.
• Conferir se os recortes por tática somam o mesmo número de técnicas pontuadas, com a diferença explicada por escrito quando a tática mudou.
• Reexecutar a comparação de adversários prioritários contra detecção e verificar se o resultado bate com o relatório de lacunas arquivado no ciclo anterior.
• Atualizar a legenda quando estados mudaram, por exemplo quando técnica órfã em transição precisa de rótulo próprio até a reatribuição terminar.

4. Fontes de Mapeamento e Estratégia de Atualização

Nem toda fonte de mapeamento é migrada do mesmo jeito, e classificar as fontes é metade do trabalho de inventário. A tabela abaixo organiza as fontes típicas pela estratégia de atualização que cada uma admite. O princípio é automatizar tudo que é estruturado e formalizar revisão humana onde o mapeamento é prosa.

A classificação tem efeito colateral valioso: ela expõe mapeamentos em prosa, em planilhas e em cabeças de pessoas, que são exatamente os que a próxima migração vai esquecer. O investimento que fecha essa brecha é migrar o que dá para dados estruturados, e a nota de Detection as Code do capítulo 18 é o caminho natural para as regras.

5. Regras de Reatribuição e Casos de Borda

A reatribuição segue semântica, não intuição. Técnicas deprecadas carregam referência explícita de substituição, e a regra é migrar para o substituto e revisar se o contexto do mapeamento ainda vale, porque o substituto às vezes é mais granular e o mapeamento original se divide em dois. Técnicas revogadas apontam para o objeto que as fundiu, e o mesmo cuidado vale. Mudanças de tática, como a divisão de Defense Evasion na v19, exigem decisão extra: o mapeamento que citava a técnica com a tática antiga precisa escolher a tática nova correta, o que só é possível lendo a descrição da técnica, não o ID.

Os casos de borda são onde migrações amadoras falham. O primeiro é o mapeamento para técnica que foi dividida em subtécnicas: citar só a técnica-mãe passa a ser impreciso, e o correto é distribuir o mapeamento pelas subtécnicas que o artefato realmente cobre, o que exige olhar a regra ou o playbook. O segundo é o mapeamento para plataforma errada, comum quando técnicas ganham plataformas novas: a regra que rodava só em Windows pode agora ter análogo Linux declarado, o que abre cobertura sem trabalho novo. O terceiro é a revisão silenciosa de descrição, que não quebra nada mas pode mudar a interpretação de um mapeamento de relevância de adversário, e por isso a fila de revisão deve incluir alterações de revisão, não só deprecations.

6. Script de Diff em Pseudocódigo

O núcleo do diff é um algoritmo simples de comparar dois bundles STIX por identificador externo, e vale escrever em pseudocódigo para deixar claro que qualquer linguagem resolve. O script abaixo é a espinha dorsal usada nos exemplos das notas de versão deste capítulo.

funcao diff_attack(bundle_velho, bundle_novo):
    velho = indice_por_external_id(bundle_velho, tipo="attack-pattern")
    novo  = indice_por_external_id(bundle_novo,  tipo="attack-pattern")

    novos      = chaves(novo)  - chaves(velho)
    removidos  = chaves(velho) - chaves(novo)
    comuns     = intersecao(chaves(velho), chaves(novo))

    deprecados = []
    alterados  = []
    para id em comuns:
        a, b = velho[id], novo[id]
        se b.get("x_mitre_deprecated") e nao a.get("x_mitre_deprecated"):
            deprecados.adicionar({id, substituto: procurar_revoked_by(b)})
        senao se b["x_mitre_version"] != a["x_mitre_version"]:
            alterados.adicionar({id, de: a["x_mitre_version"],
                                 para: b["x_mitre_version"]})

    retornar relatorio(novos, removidos, deprecados, alterados)

funcao atribuir_substitutos(mapeamentos_internos, relatorio):
    para cada mapeamento em mapeamentos_internos:
        se mapeamento.id em relatorio.deprecados:
            mapeamento.novo_id = substituto
            mapeamento.status  = "reatribuido-automatico"
            mapeamento.prioridade_revisao = "alta"
    retornar fila_de_revisao(mapeamentos_internos)

Duas notas de implementação evitam dor. A função procurar_revoked_by resolve o relacionamento de revogação no bundle, não confia em texto de descrição, porque o relacionamento é dado estruturado e estável. E o relatório deve ser emitido em formato máquina, por exemplo JSON, além do resumo legível, porque o mesmo relatório alimenta o job que marca os mapeamentos internos e o comitê que aprova as exceções.

7. Cronograma de Migração Encaixado na Cadência Semestral

O cronograma recomendado assume duas releases por ano e um janelão de trabalho previsível, detalhado semana a semana na tabela abaixo. A meta operacional é encerrar a migração em seis semanas, antes que as caças e detecções do ciclo novo comecem a ser registradas sobre a versão vigente.

O dimensionamento do esforço depende do inventário estar vivo. Times que mantêm o inventário de mapeamentos como dado estruturado, e não como espalhado em artefatos, executam esse cronograma com um engenheiro e meio de esforço total; times que redescobrem os mapeamentos a cada ciclo gastam o ciclo inteiro só para saber o que precisa mudar. O investimento em inventário é, portanto, o fator determinante do custo anual de acompanhar o ATT&CK.

O formato da nota de migração que fecha o processo é deliberadamente curto, e o esqueleto abaixo é o modelo usado nas releases da biblioteca. Ele cabe em uma página e arquivado junto dos artefatos, vira a memória institucional da adoção.

Nota de migracao: ATT&CK v19
Data da release: abril de 2026
Adocao concluida: 15 de maio de 2026
Classificacao: mudanca de tatica, recortes por tatica revisados
Numeros: 214 mapeamentos afetados, 41 reatribuidos por script,
         26 revisados a mao, 9 tecnicas novas relevantes aos PIRs
Metricas: media de cobertura por tatica publicada antes e depois
Divergencias: integracao de fornecedor permanece na v17 ate setembro
Arquivos: diff.json, layer-pre.json, layer-pos.json, ata do comite

8. Erros Comuns e Pontos de Atenção

O erro mais comum é migrar só as layers do Navigator e esquecer os metadados de regras e playbooks, o que produz mapas bonitos sobre um estado interno antigo. O segundo é confiar em reatribuição automática sem revisão: o substituto estrutural é sempre melhor que o ID morto, mas a semântica do mapeamento original pode ter mudado, e só o dono do artefato sabe se a regra ainda cobre o comportamento descrito. Um terceiro é migrar sem comparar métricas antes e depois, perdendo a única chance de separar mudança de cobertura causada pelo framework de mudança causada pelo trabalho do time.

Também é frequente ignorar mudanças de tática porque o ID continua igual: a técnica existe, mas o recorte por tática do dashboard mudou de lugar, e o comitê vê queda inexplicável em uma tática e subida na outra. Um deslize sutil adicional é executar a migração em ambiente separado e nunca promover para produção, deixando versões divergentes entre o repositório de regras e as layers publicadas. Por fim, cuidado com exceções permanentes: se um mapeamento não pôde ser migrado, ele deve virar item de backlog com prazo, não uma linha congelada num arquivo de exceções que ninguém relê.

9. Integração com o Restante da Biblioteca

Este processo é a execução concreta do controle MAP.5, Evolução Contínua da Cobertura, e protege o investimento feito em MAP.1 e MAP.2, porque mantém os mapeamentos de controles e os heatmaps sobre a versão vigente do framework. Ele também preserva a série temporal construída na nota de Heatmaps de Evolução Temporal, que só é comparável entre trimestres se as camadas estiverem recalculadas sobre a mesma versão ou com a diferença de versão documentada. No eixo de detecção, a nota conecta com Detection as Code do capítulo 18, onde os IDs de técnica em metadados de regras são exatamente os mapeamentos que este processo migra, e com os testes automatizados em CI-CD, que são o lugar natural para uma verificação que falhe o pipeline quando uma regra citar ID deprecado.