Mudanças no Modelo de Dados e Detecções

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Detalha a
evolução do modelo de dados do framework: a substituição do texto livre de
detections pelos objetos Detection Strategies e Analytics e a passagem das
fontes de dados declarativas para data components e log sources. Explica o
que muda para quem consome via STIX e TAXII e como migrar integrações, com
diff de objeto como evidência. Dialoga com as notas de Detection Strategies,
Deprecação de Data Sources e Novo Modelo de Dados STIX do capítulo.

1. Contexto e Posicionamento na Biblioteca

O ATT&CK não é apenas uma página web: é um banco de objetos STIX 2.1 consumido por TIPs, SIEMs, plataformas de CTI e scripts internos. Quando o modelo de dados muda, a mudança atravessa a API, o bundle e o dashboard, e o custo real aparece nas integrações, não no site. Esta nota consolida em um só lugar a trajetória do modelo de dados defensivo, o que as notas de versão v18 registram pontualmente, e orienta a migração de quem consome o banco por STIX e TAXII.

A leitura assume familiaridade com a nota de Detection Strategies e Analytics, que apresenta os novos objetos, e com a nota de Deprecação de Data Sources, que registra o lado da coleta. Aqui o foco é o diff: o que exatamente saiu, o que entrou, como um consumidor detecta a mudança e como se reescreve uma integração sem reescrever o produto inteiro.

2. Trajetória do Modelo: De Texto Livre a Objetos

A primeira mudança estrutural do modelo defensivo ocorreu quando as fontes de dados deixaram de ser uma lista de strings no objeto da técnica, como Data Source: Process Monitoring, e passaram a ser representadas por objetos Data Component ligados a Log Sources. Essa separação distinguiu o dado em si, por exemplo Process, do seu canal de observação, por exemplo process creation com Event ID 4688, e permitiu falar com precisão de qual componente de dados um analytic precisa. Por anos as duas representações coexistiram, com o campo x_mitre_data_sources de string marcado como legado.

A segunda mudança, a maior, chegou na v18 de outubro de 2025: o texto livre de detections, que existia apenas nas páginas do site e nunca foi campo confiável do bundle, foi substituído por dois SDOs customizados, x-mitre-detection-strategy e x-mitre-analytic, ligados às técnicas por relacionamentos do tipo detects e entre si por referências x_mitre_analytic_refs. Na mesma release, o campo legado de data sources foi descontinuado, e o bundle passou a declarar x_mitre_attack_spec_version 3.3.0. O resultado é um modelo em que detecção e dado têm identidade própria, versionável e consultável como qualquer outra parte do framework.

A escala da mudança fica clara nos números entregues pela v18, que a nota de versão deste capítulo registra em detalhe. A tabela abaixo resume o volume de objetos defensivos por domínio na release, e serve de dimensão para estimar carga de processamento nas integrações que passam a carregar esses objetos.

3. O Que Muda para Consumidores STIX e TAXII

Para quem consome o bundle, a mudança visível é tipológica: o conjunto de objetos ganhou dois tipos novos, x-mitre-detection-strategy e x-mitre-analytic, e os relacionamentos detects ligam estratégias a técnicas. O consumidor ingênuo, que itera o bundle tratando só technique e relationship conhecidos, não quebra, mas perde todo o material defensivo, porque pipelines que filtram tipos desconhecidos descartam silenciosamente os SDOs novos. O sintoma clássico é o dashboard de cobertura que continua no ar com metade dos dados sumida.

No TAXII, a mecânica é igual: os objetos novos chegam nos mesmos collections, com id, spec_version 2.1 e created e modified próprios. Três precauções práticas definem uma integração saudável. Primeiro, o parser precisa aceitar qualquer objeto cujo type comece com x-mitre sem descartar, guardando o cru para processamento futuro. Segundo, filtros de domínio devem considerar x_mitre_domains, porque estratégias existem nos três domínios com volumes distintos. Terceiro, o campo x_mitre_attack_spec_version do bundle passa a ser o gatilho de compatibilidade: mudança de minor indica alteração de contrato, e é ela que deve disparar a regressão dos parsers, não a data da release.

Vale listar as perguntas que o modelo novo responde e o antigo não respondia, porque são elas que justificam o esforço da migração diante do comitê.

• Quantos analytics concretos existem para uma técnica dada, com contagem exata em vez de impressão editorial.
• Quais componentes de dados cada analytics exige, com referência estruturada ao log source, permitindo cruzar com o inventário de coleta da casa.
• O que mudou na orientação de detecção entre duas versões, com diff por objeto em vez de comparação de prosa.
• Quais técnicas perderam cobertura de orientação na release, pergunta impossível no modelo de texto livre e trivial no grafo de relacionamentos.

4. Diff de Objeto: Técnica na v17 e na v18

O bloco abaixo mostra, simplificado, o diff de um objeto de técnica entre a v17 e a v18, com as linhas removidas e adicionadas no formato usual de patch. O exemplo usa T1059.001, PowerShell, e concentra os campos defensivos relevantes, omitindo metadados descritivos.

  {
    "type": "attack-pattern",
    "id": "attack-pattern--0af0ca99-...-e1e2",
    "name": "PowerShell",
    "external_references": [{"external_id": "T1059.001", ...}],
    "x_mitre_platforms": ["Windows"],
-   "x_mitre_data_sources": [
-     "Command: Command Execution",
-     "Process: Process Creation",
-     "Script: Script Execution"
-   ],
+   "x_mitre_data_components": [
+     "x-mitre-data-component--6fec6fa5-...-1e1e",
+     "x-mitre-data-component--3d3af2c1-...-2c2c"
+   ],
-   "x_mitre_version": "1.2",
+   "x_mitre_version": "2.0",
    ...
  }

  # Relacionamentos novos que chegam no mesmo bundle:
+ {"type": "relationship", "relationship_type": "detects",
+  "source_ref": "x-mitre-detection-strategy--...-DETF3A1",
+  "target_ref": "attack-pattern--0af0ca99-...-e1e2"}

A leitura operacional do diff orienta a reescrita. O campo de strings sumiu, então todo código que avaliava viabilidade de detecção lendo x_mitre_data_sources precisa ler os componentes referenciados e, a partir deles, os log sources. O relacionamento detects é a nova porta de entrada para o material defensivo: o consumidor deve indexar estratégias por target_ref e contar analytics por estratégia para reproduzir, com precisão, o que antes se estimava pelo texto do site. O bump de x_mitre_version do objeto é o marcador que o diff automatizado usa para separar mudança de modelo de revisão editorial comum.

5. Migração de Integrações em Quatro Movimentos

A migração recomendada segue uma ordem que minimiza risco: inventário, tolerância, reescrita e regressão. No inventário, listar todos os consumidores do bundle, interno e de terceiros, com o campo que cada um lê, porque a lista de leitores define a área de explosão. Na tolerância, atualizar parsers para aceitar tipos x-mitre desconhecidos antes de qualquer release, de modo que o dia da atualização não derrube nada. Na reescrita, migrar a lógica do campo antigo para os novos objetos, com prioridade para as métricas de cobertura, que alimentam comitê. Na regressão, rodar o conjunto de testes comparando a saída da integração entre bundle v17 e v18, aceitando diferenças explicáveis e tratando como bug qualquer perda silenciosa.

# Núcleo de parser tolerante e migrado
from stix2 import MemoryStore

src = MemoryStore()
src.load_from_file("enterprise-attack.json")

# 1) Tolerância: guardar tipos x-mitre sem descartar
desconhecidos = [o for o in src.source["objects"] if o["type"].startswith("x-mitre")]

# 2) Índice de técnicas por relacionamento detects
tec_por_estrategia = {}
for rel in src.query("relationship_type = 'detects'"):
    tec_por_estrategia[rel["source_ref"]] = rel["target_ref"]

# 3) Métrica nova: analytics por técnica, substituindo leitura de texto
analytics_por_tecnica = {}
for an in src.query("type = 'x-mitre-analytic'"):
    for estr in an.get("x_mitre_analytic_refs", []):
        tec = tec_por_estrategia.get(estr)
        analytics_por_tecnica[tec] = analytics_por_tecnica.get(tec, 0) + 1

O ponto de governança que fecha a migração é registrar no inventário interno, para cada regra ou analytics local, o identificador AN e DET correspondentes. Esse vínculo é o que permite a releases futuras serem adotadas com diff barato, porque o time compara seus identificadores com os do banco em vez de comparar texto com texto.

6. Testes de Regressão e Critérios de Aceite

A regressão é o movimento mais negligenciado da migração, e por isso merece critérios explícitos. O objetivo não é comparar conteúdo entre versões, já coberto pelo diff, e sim garantir que a integração continua produzindo as mesmas saídas esperadas sobre a base nova. O conjunto mínimo de testes abaixo deve rodar em CI para cada bundle consumido, e a execução deve ser barata o suficiente para rodar toda semana, não só no dia da release.

• Teste de tipo: o parser conta quantos objetos de cada type recebeu, e qualquer contagem zero para tipos esperados, inclusive x-mitre-detection-strategy e x-mitre-analytic, falha o teste com mensagem apontando o filtro suspeito.
• Teste de identificador: o índice por external_id deve resolver todas as técnicas do domínio consumido, e IDs presentes no bundle mas ausentes no índice indicam bug de extração.
• Teste de grafo: cada relacionamento detects deve ter source_ref e target_ref resolvíveis no mesmo bundle, e relacionamentos pendentes ou órfãos são tratados como defeito, não como tolerância.
• Teste de métrica: a contagem de analytics por técnica é comparada com o número publicado na nota de release, com tolerância pequena, e desvio grande significa que o parser está perdendo objetos.
• Teste de carga: carregar o bundle completo deve ficar dentro do tempo acordado, porque integração que funciona em amostra e trava em carga produzirá outage no dia da atualização real.
• Teste de idempotência: rodar o parser duas vezes sobre o mesmo bundle deve produzir saída idêntica, porque integração não determinística corrompe métricas históricas sem erro aparente.

O aceite da integração migrada exige os seis testes verdes sobre o bundle novo e uma conferência humana de amostra, por exemplo dez estratégias aleatórias, conferidas contra a página do ATT&CK. Esse par de critérios, automação e amostra manual, pega tanto defeito estrutural quanto defeito semântico, e é a diferença entre migrar e apenas não ter quebrado ainda.

7. Caso Prático: Dashboards e TIPs Depois da v18

Um TIP que importava apenas objetos attack-pattern e relacionamentos do tipo uses perdeu, após a v18, a capacidade de responder quais técnicas têm orientação de detecção estruturada, porque os objetos novos foram arquivados sem processamento. A correção típica tem três entregas: coleta e indexação dos tipos novos, painel de contagem de analytics por técnica cruzado com o inventário de regras locais, e alerta de diferença quando uma técnica ganha ou perde analytics entre bundles. Nenhum desses entregáveis existia como possibilidade no modelo antigo, e essa é a medida real do ganho: a mudança de modelo doeu na migração e melhorou o produto de forma permanente.

O mesmo vale para dashboards de cobertura internos. O que antes era uma estimativa textual, técnica com nota de detecção ou não, vira uma contagem exata, e a nota de Detection Strategies e Analytics deste capítulo mostra como registrar o vínculo entre cada regra local e seu AN de referência, fechando o ciclo entre framework, inventário interno e métrica.

As três entregas da correção desse TIP, na ordem em que costumam ser executadas, valem como receita para qualquer plataforma de CTI na mesma situação.

• Indexar os objetos x-mitre-detection-strategy e x-mitre-analytic na ingestão, mesmo sem uso imediato, para que o dado comece a acumular histórico.
• Publicar o painel de analytics por técnica cruzado com o inventário de regras locais, que é a primeira métrica nova visível ao time.
• Criar o alerta de diferença entre bundles, que passa a avisar quando uma técnica ganha ou perde orientação estruturada entre versões.

8. Erros Comuns e Pontos de Atenção

O erro mais caro é o parser que descarta tipos desconhecidos: ele não falha no dia da release, falha nos meses seguintes, quando as métricas de cobertura ficam sem fonte e ninguém conecta os dois fatos. O segundo erro é assumir que o texto de detecção do site é o dado canônico; ele é uma renderização, e a automação deve consumir os objetos. Um terceiro é tratar data components e data sources como sinônimos: o componente é a granularidade do dado, o log source é onde ele aparece, e confundir os dois produz análise de viabilidade errada, como exigir log de proxy onde o analytics pede telemetria de processo.

Também é comum esquecer que a mudança vale para os três domínios e que bundles de ICS e Mobile carregam estratégias com campos próprios, por exemplo contexto de ativo industrial. Por fim, cuidado com versões de spec: atualizar o bundle sem olhar x_mitre_attack_spec_version e depois culpar a versão do ATT&CK por um problema de contrato de spec é confusão frequente em pós-mortem de integração.

9. Integração com o Restante da Biblioteca

Esta nota é a base técnica para o controle MAP.4 do Framework CTH, cuja análise de lacunas passa a contar analytics por componente de dados coletado, e para a nota de Migração de Mapeamentos e Controles deste capítulo, que usa o mesmo diff automatizado em escala. No eixo de infraestrutura de CTI, ela conecta com a nota de Formatos de Inteligência STIX-TAXII do grupo PLT, que define os contratos de troca, e com a nota de Automação de Coleta via APIs, que alimenta os pipelines afetados. Para o capítulo 18, o vínculo é direto com Detection as Code, porque o identificador AN no frontmatter de cada regra é o que torna a regressão contra novas versões do ATT&CK um teste automatizado e não um projeto manual.