Impactos nos Mapeamentos e Ferramentas de Detecção

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Trata do efeito
prático das versões novas sobre inventários de detecção, caças e ferramentas, com
automação de diff entre bundles STIX, processo de atualização e cronograma de
migração de 30, 60 e 90 dias. Opera as mudanças descritas nas duas notas anteriores
do bloco da v19 e conecta-se ao grupo MAP do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

Mapeamentos de ATT&CK não são artefatos estáticos: eles prometem que um inventário de detecções, caças e controles corresponde a um estado específico do framework. Quando uma versão nova revoga identificadores, move técnicas de tática e descontinua estratégias, essa promessa vira mentira silenciosa, e os dashboards continuam verdes enquanto a taxonomia por baixo deles mudou. A v19 de abril de 2026, com a divisão de Defense Evasion, foi o exemplo mais agressivo dessa classe de problema, e a v18, com a substituição de detections, já havia quebrado integrações raras.

Esta nota é a parte operacional do bloco da v19: assume que o leitor já viu as mudanças conceituais e precisa levantar, priorizar e executar a atualização. Ela conversa com MAP.1 a MAP.5, que sustentam os mapeamentos da biblioteca, e com a nota de Automação de Detecção do grupo AUT, porque a checagem de consistência entre regras e taxonomia deve rodar em pipeline, e não em revisão manual trimestral.

2. Como Versões Novas Quebram Mapeamentos

Há quatro mecanismos de quebra, com gravidades distintas. O primeiro é a revogação de identificador, em que a técnica citada no inventário deixa de existir como objeto ativo e recebe um sucessor, como T1562.001 para T1685; dashboards que agrupam por identificador começam a exibir buracos. O segundo é a movimentação de tática, em que o identificador permanece, mas a coluna da matriz muda, como aconteceu com centenas de técnicas que saíram de Defense Evasion para Stealth ou Defense Impairment; heatmaps por tática mudam de sentido sem nenhum aviso.

O terceiro mecanismo é a mudança de semântica com versão maior, em que o identificador e o nome sobrevivem, mas a descrição e a telemetria recomendada mudam de forma relevante; detecções continuam apontando para o ID, porém podem não corresponder mais ao que o ATT&CK descreve ali. O quarto mecanismo é a mudança estrutural de objetos acessórios, como a v18 fez com detections, Data Sources e Detection Strategies; integrações que consumiam aqueles objetos param de achar conteúdo válido mesmo sem nenhuma técnica mudar. Cada mecanismo pede um tipo de resposta, e confundi-los é a raiz de migrações malfeitas.

3. Inventário de Detecções e Caças como Objetos Versionados

A defesa estrutural contra quebras é tratar o próprio inventário como um conjunto de objetos versionados, e não como uma planilha. Cada item de detecção ou de caça deve registrar, no mínimo, o identificador ATT&CK mapeado, a tática, a versão do ATT&CK usada no mapeamento, a data da última revisão e o dono. Com esses campos, a checagem de consistência é uma consulta: quais itens citam identificadores que não existem mais, quais citam identificadores com versão menor que a atual e quais citam táticas que deixaram de conter a técnica.

A consulta abaixo, em KQL sobre uma tabela hipotética de inventário carregada no SIEM, lista itens cujo mapeamento cita identificadores da família T1562, justamente a família revogada na v19, e precisa de revisão prioritária.

InventarioDeteccoes
| where TecnicaATTCK startswith "T1562"
| project ItemId, NomeDeteccao, TecnicaATTCK, Tatica, VersaoATTCKMapeada,
          UltimaRevisao, Dono
| order by UltimaRevisao asc

O mesmo padrão vale para caças documentadas. Hipóteses do capítulo 8 da biblioteca que citam Impair Defenses, por exemplo, devem ser reetiquetadas conforme o comportamento real que a caça observa: se a hipótese busca desativação de ferramentas, o alvo é T1685 em Defense Impairment; se busca ocultação, o alvo pertence a Stealth. Essa distinção muda inclusive a ordem de execução das caças, porque impairment tende a ser mais urgente.

4. Automação de Diff entre Versões

A automação central do processo é o diff entre o bundle em produção e o bundle da versão nova. O script abaixo, em Python com stix2, compara dois bundles e produz três listas: objetos novos, objetos revogados e objetos com versão maior. É o insumo direto para os tickets de migração e elimina a dependência de leitura manual das release notes para levantamento técnico.

from stix2 import MemoryStore

def carregar(caminho):
    src = MemoryStore()
    src.load_from_file(caminho)
    return {o["id"]: o for o in src.query("type = 'attack-pattern'")}

velho = carregar("enterprise-attack-18.1.json")
novo = carregar("enterprise-attack-19.0.json")

novos, revogados, maiores = [], [], []
for oid, obj in novo.items():
    ext = obj.get("external_references", [{}])[0].get("external_id")
    if oid not in velho:
        novos.append(ext)
    elif obj.get("revoked") and not velho[oid].get("revoked"):
        revogados.append(ext)
    elif obj.get("x_mitre_version", "") > velho[oid].get("x_mitre_version", ""):
        maiores.append((ext, velho[oid]["x_mitre_version"], obj["x_mitre_version"]))

print("Novos:", len(novos))
print("Revogados:", len(revogados))
print("Versao maior:", len(maiores))
for ext, a, b in sorted(maiores)[:10]:
    print(ext, a, b)

Além do diff de objetos, vale diffar os objetos defensivos, x-mitre-detection-strategy e x-mitre-analytic, com a mesma função, trocando o filtro de tipo. Times que mantêm regras vinculadas a identificadores AN precisam saber quais estratégias mudaram entre versões, porque a mudança pode alterar o conjunto de componentes de dados exigidos e, portanto, a validade da detecção em produção. O changelog JSON oficial cobre boa parte disso, e o diff próprio serve como verificação independente, já que é executado sobre o par de bundles exatos que a organização consome.

Uma prática final é versionar o próprio script de diff junto com os bundles de referência usados em cada ciclo, em um repositório dedicado de migração. Assim, cada release futura reutiliza o mesmo pipeline, o histórico de execuções fica auditável e o esforço de migração cai a cada ciclo, transformando um evento traumático em rotina de manutenção.

5. Cronograma de Migração de 30, 60 e 90 Dias

A migração precisa de prazo, dono e critério de aceite. O cronograma abaixo assume o ciclo semestral, com releases maiores em abril e outubro, e revisões pontuais entre elas, como a v18.1 de novembro de 2025 e a v19.2 de agosto de 2026. As datas são relativas ao dia da release, e o mesmo desenho se aplica às releases ágeis, com escopo menor.

O erro de planejamento mais comum é alocar 90 dias apenas para a troca de identificadores e não reservar tempo para a revisão semântica, que é a parte cara. A troca mecânica é automatizável em horas; reler detecções cujo objeto mudou de versão maior exige conversa entre detecção e CTI, e é exatamente essa conversa que separa uma migração honesta de uma migração cosmética.

6. Ferramentas Afetadas e Checagens Específicas

Cada classe de ferramenta pede uma checagem própria. Camadas de Navigator devem ser reabertas na versão nova e comparadas visualmente com o diff, porque scores antigos podem não fazer sentido com as táticas novas. TIPs e plataformas como MISP e OpenCTI precisam ter seus conectores testados com o bundle novo, verificando que objetos customizados e revogados são tratados. Ferramentas de gestão de detecção, como repositórios de Sigma, devem ter o campo de tags auditado para encontrar referências a técnicas revogadas. Plataformas de BAS e de emulação, como Caldera, precisam de atualização de versão, pois os seus atores internos citam técnicas por ID.

A checagem de Sigma é a mais mecânica e rende resultado imediato: varrer o repositório de regras por tags com técnicas revogadas abre o trabalho com escopo exato. O trecho abaixo, em shell, lista as regras afetadas pela família T1562 num repositório de Sigma, servindo de ponto de partida para os tickets da janela de 31 a 60 dias.

A validação purple team fecha o ciclo dentro da janela de 61 a 90 dias. Exercícios de emulação que citavam técnicas movidas, como os planos de SIM.3 do Framework CTH, precisam ser reprocessados na taxonomia nova, e o resultado do reteste deve ser registrado contra os identificadores novos, para que a evidência de cobertura continue audível. Sem essa revalidação, a migração fica técnica e documental, mas não prova que as detecções continuam acendendo para o mesmo comportamento do adversário.

grep -rl "attack.t1562" rules/ | sort > revisar_t1562.txt
wc -l revisar_t1562.txt

Depois da varredura, cada regra da lista recebe um ticket com o sucessor correto, e a alteração é testada no ambiente de homologação antes da promoção. O mesmo roteiro se repete para qualquer família revogada em releases futuras, o que transforma a resposta à v19 em playbook permanente.

7. Métricas de Sucesso da Migração

A migração só fecha quando as métricas provam que o estado antigo saiu de circulação. As métricas abaixo são calculáveis por script sobre o inventário e o bundle, e vale registrá-las antes e depois da migração para demonstrar progresso de forma objetiva nos relatórios do grupo MET.

A última métrica é a que sustenta as outras ao longo do tempo, porque sem versão declarada ninguém consegue dizer, meses depois, contra qual estado do ATT&CK cada artefato foi validado. Times maduros tratam essa declaração como parte do definition of done de qualquer alteração em detecção ou caça, e não como atividade de projeto pontual.

8. Erros Comuns e Pontos de Atenção

O erro mais caro é adiar a migração por acreditar que identificadores antigos continuam funcionando, já que as páginas revogadas seguem no ar. Páginas revogadas são histórico, não contrato, e cada release que passa sem incorporação aumenta o custo de sincronização, porque diffs acumulam. O segundo erro é migrar só o Enterprise e esquecer ICS e Mobile, que também receberam mudanças relevantes, como as sub-técnicas industriais da v19. O terceiro erro é medir a migração por número de IDs trocados, métrica vaidosa que ignora as mudanças de semântica nas versões maiores, que são as que realmente afetam a validade das detecções.

Cuidado também com dependências indiretas: bibliotecas de terceiros, projetos comunitários de cobertura e integrações SaaS do próprio SIEM podem embutir versões do ATT&CK em seus produtos. O inventário de dependências do time deve registrar qual versão do ATT&CK cada ferramenta terceira usa, porque o dashboard interno pode estar correto na v19 enquanto o relatório da ferramenta parceira ainda trabalha na v17, gerando inconsistências difíceis de diagnosticar em revisões conjuntas.

9. Integração com o Restante da Biblioteca

Esta nota executa o que as notas de Defense Evasion e de Mudanças em Técnicas descrevem, e fecha o bloco da v19 com processo e prazo. No Framework CTH, ela materializa MAP.5, Evolução Contínua da Cobertura, alimenta as métricas do grupo MET com o tempo de incorporação de release, e dá conteúdo concreto ao AUT.3, Automação de Detecção, com o pipeline de diff e de checagem de referências.

Para o leitor que organiza a biblioteca em plano de estudo, a sequência recomendada do bloco da v19 é a divisão da tática, o panorama de técnicas, esta nota operacional e, por fim, o bloco da v19.2, que mostra o novo modelo de releases ágeis e a expansão da cobertura para Kubernetes, CI/CD e sistemas de IA. O exercício final sugerido é rodar o diff entre o bundle usado no último relatório de cobertura e o bundle atual, entregando a lista de dez objetos mais impactantes ao dono de cada categoria.