Novo Modelo de Dados STIX para Defesa

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Detalha a nova
representação em STIX 2.1 dos objetos defensivos introduzidos na v18: Detection
Strategies, Analytics e Data Components, com o relacionamento detects. É a base
técnica para as notas de migração de integrações deste capítulo e dialoga com as
notas de STIX e TAXII do grupo PLT do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

As mudanças defensivas da v18 do ATT&CK não ficaram restritas ao site: elas exigiram uma reescrita do modelo de dados STIX usado para distribuir o framework. O campo de detecção em texto livre dentro das técnicas desapareceu e deu lugar a três tipos de objetos customizados, x-mitre-detection-strategy, x-mitre-analytic e x-mitre-data-component, amarrados por relacionamentos do tipo detects e por referências diretas entre campos. O bundle passou a declarar a versão da especificação ATT&CK sobre STIX, o campo x_mitre_attack_spec_version, no valor 3.3.0, e a documentação oficial desse modelo passou a ser a página ATT&CK Data Model do projeto.

Para a biblioteca, esta nota cumpre o papel de referência de engenharia de dados da parte defensiva. Ela sustenta as automações discutidas nas notas PLT.3 e PLT.5, que tratam de formatos STIX e TAXII e de compartilhamento, e é pré-requisito para a nota de Impactos nos Mapeamentos e Ferramentas de Detecção, que usa diffs entre bundles como mecanismo de migração. Quem consome ATT&CK por API, por repositório GitHub ou por TAXII precisa entender os campos aqui descritos antes de tocar em qualquer pipeline.

2. Os Novos Objetos e Seus Papéis

O modelo defensivo novo tem quatro peças. A Detection Strategy é um SDO customizado que descreve o comportamento a ser detectado e agrupa os analytics que o materializam, com identificador externo no formato DET, como DET0103. O Analytics é outro SDO customizado que descreve a lógica de detecção sobre dados concretos, com identificador externo no formato AN, como AN0110. O Data Component, que já existia antes da v18, ganhou o papel de granularidade primária de dados e passou a declarar fontes de log em x_mitre_log_sources. Por fim, o relacionamento detects liga cada estratégia à técnica que ela observa, com a estratégia como source_ref e a técnica, um attack-pattern, como target_ref.

Os objetos antigos de fonte de dados, x-mitre-data-source, permanecem no bundle com x_mitre_deprecated verdadeiro, o que permite leitura histórica sem confundir automações novas. Na contagem da v18, o domínio Enterprise entregou 691 estratégias e 1739 analytics, o Mobile 124 e 211, e o ICS 83 e 82, o que dá a dimensão do volume que qualquer parser precisa suportar desde o primeiro dia. A tabela abaixo resume cada peça do modelo com seu tipo STIX e função.

3. Campos Relevantes de Cada Objeto

A Detection Strategy carrega nome, descrição, domínios, plataformas quando aplicável, referências externas com a URL de detectionstrategies e a lista x_mitre_analytic_refs, que aponta para os SDOs de analytics que a compõem. O Analytics carrega description, x_mitre_platforms, x_mitre_log_source_references e x_mitre_mutable_elements. Esses dois últimos campos são o que há de mais valioso para engenharia de detecção, porque declaram exatamente sobre quais componentes de dados e canais a lógica roda e quais parâmetros exigem calibragem local, como listas de permissão de processos ou feeds de reputação.

O campo x_mitre_log_source_references merece leitura atenta: cada entrada referencia um Data Component por STIX ID e traz, além disso, o nome da fonte e um canal com filtro, por exemplo auditd:SYSCALL com socket/connect ou WinEventLog:Security com EventCode=4768. Já os mutable elements descrevem campos ajustáveis do analytics, com nome do campo e orientação de ajuste, o que funciona como um contrato de tuning entre o ATT&CK e o time que vai implementar. Essa combinação transforma a orientação de detecção em dado processável, objetivo que o texto livre nunca alcançou.

4. Exemplo Real de Objetos no Bundle

O trecho abaixo reproduz, com campos de marcação omitidos, uma Detection Strategy real do bundle, mostrando o amarração entre os identificadores externos e as referências internas de analytics.

{
  "type": "x-mitre-detection-strategy",
  "spec_version": "2.1",
  "id": "x-mitre-detection-strategy--00060b87-7f99-45aa-9553-a4d94139195c",
  "name": "Behavioral Detection of Network Share Connection Removal via CLI and SMB Disconnects",
  "external_references": [
    {
      "source_name": "mitre-attack",
      "url": "https://attack.mitre.org/detectionstrategies/DET0103",
      "external_id": "DET0103"
    }
  ],
  "x_mitre_domains": ["enterprise-attack"],
  "x_mitre_analytic_refs": [
    "x-mitre-analytic--5d47e6b2-04fb-45ab-be98-7de1baabf508"
  ],
  "x_mitre_attack_spec_version": "3.3.0"
}

O relacionamento que conecta a estratégia à técnica segue o formato padrão de relationship do STIX 2.1, com o campo relationship_type em detects, e é por esse caminho que um parser determina a qual técnica cada estratégia pertence.

{
  "type": "relationship",
  "spec_version": "2.1",
  "id": "relationship--00b2d214-7126-4b80-866c-4321d6ace9b0",
  "relationship_type": "detects",
  "source_ref": "x-mitre-detection-strategy--be6a466c-40c6-4611-9b68-7cfcbcb35fb0",
  "target_ref": "attack-pattern--dca670cf-eeec-438f-8185-fd959d9ef211",
  "x_mitre_attack_spec_version": "3.3.0"
}

Note que os identificadores externos AN também usam âncora na URL da estratégia, como em detectionstrategies/DET0039#AN0110, o que deixa explícito no dado que o analytics pertence a uma estratégia específica. Automatizações que precisam listar analytics por estratégia devem usar x_mitre_analytic_refs como fonte primária e a âncora apenas como referência humana.

5. Como Consumidores de STIX Migram

A migração de um consumidor tem três frentes. Na frente de parsing, bibliotecas como stix2 aceitam objetos customizados, mas pipelines que fazem whitelist de tipos precisam incluir os três novos tipos e o relacionamento detects, e pipelines que descartam tipos desconhecidos vão perder todo o modelo defensivo em silêncio. Na frente de modelagem, armazenamentos internos devem criar tabelas ou índices para estratégias e analytics, com chaves pelos identificadores externos DET e AN, porque são esses identificadores que estabilizam comparações entre versões. Na frente de versão, o consumidor deve registrar a versão do bundle consumida e o valor de x_mitre_attack_spec_version, já que mudanças futuras dessa especificação podem introduzir campos novos.

O script abaixo, em Python com attackcti e stix2, mostra uma extração completa do grafo defensivo: para cada técnica, quantas estratégias a detectam, quantos analytics existem e quais componentes de dados são exigidos. Esse é o núcleo de qualquer relatório de cobertura baseado no modelo novo.

from attackcti import attack_client

lift = attack_client()
strategies = lift.get_stix_objects("detection-strategy")
analytics = {a["id"]: a for a in lift.get_stix_objects("analytic")}
relationships = lift.get_stix_objects("relationship")

detects = {}
for r in relationships:
    if r["relationship_type"] == "detects":
        detects.setdefault(r["target_ref"], []).append(r["source_ref"])

tech = lift.get_stix_objects("attack-pattern")
for t in tech:
    if t.get("revoked"):
        continue
    refs = detects.get(t["id"], [])
    if not refs:
        continue
    for s_ref in refs:
        strat = next(s for s in strategies if s["id"] == s_ref)
        print(t["external_references"][0]["external_id"], "|",
              strat["external_references"][0]["external_id"], "|",
              len(strat.get("x_mitre_analytic_refs", [])))

Times que usam TIPs devem verificar o suporte a objetos customizados antes de apontar o conector para o bundle novo, porque plataformas antigas podem rejeitar ou truncar x-mitre-detection-strategy. Em caso de incompatibilidade, o padrão mais seguro é persistir os objetos defensivos em um repositório próprio, sincronizado por script, e manter no TIP apenas o núcleo de técnicas e atores.

6. Relação com TAXII e Distribuição

O TAXII 2.1 continua sendo o canal de distribuição oficial, e os novos objetos viajam dentro das coleções como qualquer SDO customizado, respeitando content negotiation e filtros por tipo. O servidor ATT&CK expõe os objetos defensivos nas mesmas coleções de domínio, enterprise-attack, ics-attack e mobile-attack, e a recomendação prática é solicitar o bundle completo em vez de streams incrementais durante a migração, para garantir que estratégias, analytics, componentes e relacionamentos cheguem atomicamente consistentes.

Para ambientes sem acesso a TAXII, os repositórios públicos de dados STIX do ATT&CK, incluindo o repositório mitre-attack/attack-stix-data e o histórico do repositório mitre/cti, disponibilizam bundles por domínio e por versão, com tags que correspondem às releases, como a v18.1 de novembro de 2025. A prática recomendada é fixar a versão do bundle em produção, testar a migração em cópia do repositório e só então promover, exatamente como se faz com qualquer dependência de software.

A escolha do canal deve considerar o perfil de consumo, e não a preferência técnica do time. A tabela abaixo compara os canais oficiais e orienta quando usar cada um, considerando volume, latência e necessidade de histórico.

Uma recomendação operacional que evita dor posterior é registrar em log, em cada execução do pipeline, o hash do bundle consumido e a versão declarada. Esse registro torna auditável qualquer mudança de comportamento nas detecções, porque o time consegue demonstrar exatamente qual estado do ATT&CK alimentou cada versão do inventário, o que é valioso tanto para auditorias internas quanto para explicar regressões de cobertura a stakeholders do grupo MET.

7. Erros Comuns e Pontos de Atenção

O erro mais comum é confundir x_mitre_version do objeto com a versão do ATT&CK: o primeiro muda quando aquele objeto específico muda, e o segundo vive na coleção e nas notas de release. Outro erro é presumir que todo analytics tem componentes de dados referenciados; alguns analytics descrevem lógica sobre fontes que a organização precisa mapear por conta própria, então a ausência de x_mitre_log_source_references não invalida o analytics, apenas exige mais trabalho local. Há também quem trate mutable elements como meras notas, ignorando que eles definem os parâmetros de tuning e que produzir alertas sem calibrar esses campos é receita para falso positivo.

Um cuidado adicional é com revogações e deprecações combinadas. Na transição, técnicas revogadas continuam no bundle com o campo revoked verdadeiro e apontam para o sucessor por relacionamento revoked-by, e objetos defensivos também podem ser descontinuados entre versões, como ocorreu com estratégias da família Impair Defenses na v19. Pipelines que não filtram explicitamente revoked e deprecated misturam estado passado e presente nos dashboards de cobertura, o que compromete as métricas discutidas no grupo MET.

8. Integração com o Restante da Biblioteca

Esta nota é a camada de dados das decisões tomadas nas notas de Detection Strategies e de Deprecação de Data Sources, e é pré-requisito para implementar as automações de diff descritas em Impactos nos Mapeamentos e Ferramentas de Detecção. Ela também alimenta as notas PLT.3 e PLT.5 do Framework CTH, pois o compartilhamento de inteligência via MISP, OpenCTI ou TIPs comerciais passa a incluir o modelo defensivo completo, e não apenas técnicas e atores.

Para hunting, o modelo STIX permite gerar automaticamente um catálogo de hipóteses de caça a partir das estratégias, cada uma com a telemetria exigida já declarada, o que conecta esta nota ao grupo HNT e ao ciclo integrado de inteligência e caça descrito em INT.1. O próximo passo natural do leitor é baixar o bundle atual, rodar o script da seção 5 e comparar a saída com o inventário interno de detecções, transformando a leitura em diagnóstico concreto.