Detection Strategies e Analytics (Substituição de Detections)

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Registra a maior
mudança defensiva já aplicada ao framework, introduzida na v18 de outubro de 2025,
quando o campo livre de detections foi substituído pelos objetos estruturados
Detection Strategies e Analytics. Dialoga com as notas de Deprecação de Data
Sources, Novo Modelo de Dados STIX para Defesa e com as notas de mapeamento do
grupo MAP do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

A versão 18 do ATT&CK, publicada em 28 de outubro de 2025, alterou profundamente a parte defensiva do framework. O antigo campo de detections presente em cada técnica, que era um parágrafo livre de orientação de detecção por plataforma, foi removido e substituído por dois novos objetos: Detection Strategies e Analytics. Essa mudança transformou a orientação de detecção de texto solto em dados estruturados, consultáveis, versionados e exportáveis junto com o restante do banco ATT&CK em STIX.

Para a biblioteca, esta nota é o ponto de entrada do capítulo de atualizações do ATT&CK. Ela se conecta diretamente às notas MAP.1 e MAP.2 do Framework CTH, que tratam de mapeamento de controles e heatmaps de cobertura, e também à nota de Hunting em Windows e Active Directory, pois muitos dos novos analytics descrevem telemetria de Security 4624, 4768 e 4769 já explorada em caças do capítulo 8. Ler esta nota antes das demais do capítulo evita confusão de nomenclatura, já que o termo "detection" deixou de designar um campo e passou a designar um conjunto de objetos.

2. O Modelo Antigo e Seus Limites

Até a v17, cada página de técnica exibia uma seção de detections com notas textuais, organizadas apenas por plataforma, por exemplo Windows, Linux ou macOS. O conteúdo era útil, porém inutilizável de forma automatizada: não havia identificador estável, não havia relacionamento explícito com fontes de dados, não havia versionamento independente e duas técnicas podiam receber orientações com granularidades totalmente distintas. times de detecção copiavam o texto manualmente para dentro de seus projetos de regras e cada ferramenta interpretava o material de um jeito.

Os limites práticos desse modelo ficavam evidentes no dia a dia de engenharia de detecção. Um parágrafo livre não pode ser vinculado a um analytic do SIEM em um banco de dados, não pode ser comparado em um diff entre versões do ATT&CK e não permite medir quantos analytics concretos existem por técnica. Além disso, a orientação genérica de texto raramente discriminava qual componente de dados sustentava a detecção, o que forçava o analista a inferir se a sugestão dependia de Event ID 4688, de logs de EDR ou de telemetria de rede. A v18 resolveu esses problemas convertendo a orientação em objetos com identidade própria.

3. O Novo Modelo: Estratégia, Analytics e Dados

O novo modelo é hierárquico e modular. Uma Detection Strategy descreve o comportamento do adversário que se pretende observar e por que aquela observação indica a técnica. Cada estratégia é composta por um ou mais Analytics, que descrevem como computar a detecção sobre dados concretos, incluindo a fonte de logs, o canal e os componentes de dados necessários. A estratégia se conecta à técnica por um relacionamento do tipo detects no modelo STIX, e os analytics se conectam à estratégia por referências diretas no campo x_mitre_analytic_refs.

A v18 entregou essa estrutura em escala nos três domínios. O domínio Enterprise recebeu 691 Detection Strategies e 1739 Analytics, o domínio Mobile recebeu 124 estratégias e 211 analytics, e o domínio ICS recebeu 83 estratégias e 82 analytics. Cada estratégia recebeu um identificador próprio no formato DET, como DET0103, e cada analytics recebeu um identificador no formato AN, como AN0110. A tabela a seguir resume os papéis de cada objeto do novo modelo defensivo.

4. Estrutura dos Objetos em STIX

Os dois novos objetos são SDOs customizados do STIX 2.1, prefixados com x-mitre, e o bundle passou a declarar x_mitre_attack_spec_version 3.3.0. O trecho abaixo mostra, simplificado, uma Detection Strategy real do bundle, composta por nome, domínio, referências externas com o identificador DET e a lista de analytics que a materializam.

{
  "type": "x-mitre-detection-strategy",
  "id": "x-mitre-detection-strategy--00060b87-7f99-45aa-9553-a4d94139195c",
  "spec_version": "2.1",
  "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 analytics, por sua vez, carrega os campos que um time de detecção mais usa: plataformas, referências de fonte de log com o componente de dados associado e elementos mutáveis, que indicam os parâmetros que precisam de calibragem local, como listas de permissão. O exemplo real a seguir é um analytics de DNS suspeito em Linux, que combina auditd com syslog e exige um feed de reputação de domínios.

{
  "type": "x-mitre-analytic",
  "id": "x-mitre-analytic--00112bcc-174f-4201-ac81-fe3edd1292e6",
  "name": "Analytic 0110",
  "external_id": "AN0110",
  "description": "Monitor /var/log/audit/audit.log and DNS resolver logs for repeated failed lookups or connections to high-entropy domain names.",
  "x_mitre_platforms": ["Linux"],
  "x_mitre_log_source_references": [
    {
      "x_mitre_data_component_ref": "x-mitre-data-component--a7f22107-02e5-4982-9067-6625d4a1765a",
      "name": "auditd:SYSCALL",
      "channel": "socket/connect"
    },
    {
      "x_mitre_data_component_ref": "x-mitre-data-component--3772e279-27d6-477a-9fe3-c6beb363594c",
      "name": "linux:syslog",
      "channel": "Query to suspicious domain"
    }
  ],
  "x_mitre_mutable_elements": [
    {
      "field": "DomainReputationFeed",
      "description": "Whitelist/blacklist tuned with external threat intel sources"
    },
    {
      "field": "ProcessWhitelist",
      "description": "Known safe daemons that frequently query domains"
    }
  ]
}

5. Impacto em Consumidores do Banco

Consumidores que tratavam o ATT&CK como um JSON de técnicas com um campo de texto detections quebraram na v18. Parsers que liam o campo antigo passaram a receber nada, páginas espelhadas do site perderam a seção de detecção e ferramentas que geravam relatórios de cobertura a partir dessas notas precisaram de ajuste. O caminho correto é consumir os objetos x-mitre-detection-strategy e x-mitre-analytic do bundle, cruzar o relacionamento detects para chegar às técnicas e usar os componentes de dados referenciados nos analytics para avaliar a viabilidade de implementação.

O impacto é maior onde a integração era mais rasa. Dashboards que apenas espelhavam o texto da página agora podem exibir o número de analytics por técnica, o que é uma métrica objetivamente melhor. Times que usavam as notas para priorizar cobertura devem reescrever essa lógica sobre as estratégias, porque agora é possível contar com precisão quantos analytics existem para T1059.003 ou para T1003.001 e quais deles dependem de componentes de dados que a organização efetivamente coleta. A tabela abaixo contrasta as duas eras de consumo.

6. Migração de Integrações e de Práticas Internas

A migração recomendada segue uma ordem simples: primeiro trocar a fonte de dados da integração, depois adaptar o modelo interno e por último recalibrar métricas. Na troca de fonte, apontar o coletor para os novos tipos no bundle e tratar a ausência do campo detections como esperada, não como erro. Na adaptação do modelo, registrar no inventário interno de detecções um vínculo entre cada regra do SIEM e o identificador AN correspondente, guardando também o DET, para que revisões futuras possam rastrear mudanças de estratégia. Na recalibração, substituir métricas vagas, como percentual de técnicas com nota de detecção, por métricas duras, como número de analytics mapeados para componentes de dados que a organização coleta.

O script de exemplo abaixo, em Python, mostra o núcleo de uma integração atualizada usando a biblioteca attackcti, listando estratégias e seus analytics a partir do bundle STIX.

from stix2 import MemoryStore

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

for strat in src.query("type = 'x-mitre-detection-strategy'"):
    an_ids = strat.get("x_mitre_analytic_refs", [])
    an_name = "Sem analytics"
    if an_ids:
        an = src.get(an_ids[0])
        an_name = an["name"]
    print(strat["external_references"][0]["external_id"], "|", strat["name"], "|", an_name)

Times que mantêm espelhos das páginas do ATT&CK devem reescrever o espelho para consumir as URLs de detectionstrategies, e times que alimentam TIPs devem confirmar que a plataforma suporta objetos customizados antes de atualizar o pipeline. O ponto crítico de governança é tratar cada AN como um contrato de telemetria: se o componente de dados exigido não existe no ambiente, o analytics vai para a fila de lacunas de coleta, e não para a fila de falsos positivos.

7. Erros Comuns e Pontos de Atenção

O erro mais frequente é assumir que Detection Strategy equivale a regra pronta. A estratégia descreve comportamento e os analytics descrevem lógica de alto nível, mas nenhum dos dois é um Sigma compilável, e a conversão para a linguagem do SIEM continua sendo trabalho de engenharia local. O segundo erro é ignorar os mutable elements, que existem justamente para indicar onde o ambiente do cliente precisa calibrar, e depois classificar como falso positivo um ruído que era falha de tuning previsto pela própria ATT&CK.

Um terceiro erro é esquecer que a mudança vale para os três domínios, inclusive ICS, e que estratégias de ICS trazem contexto de ativos que não existe no Enterprise. Por fim, cuidado com integrações que filtram objetos desconhecidos: qualquer pipeline que descarta tipos x-mitre não reconhecidos vai perder silenciosamente todo o novo modelo defensivo, e o time só vai perceber quando as métricas de cobertura caírem sem explicação.

8. Integração com o Restante da Biblioteca

Esta nota fundamenta as decisões de cobertura avaliadas em MAP.4, Análise de Lacunas de Detecção, porque a contagem de analytics por técnica e por componente de dados substitui a avaliação qualitativa que o Framework CTH fazia com base em texto. Também alimenta a nota de Automação de Detecção no grupo AUT, já que os identificadores AN podem ser registrados como metadados de regras e validados automaticamente a cada nova versão do ATT&CK.

Na prática de hunting, as estratégias funcionam como hipóteses prontas e fundamentadas: cada DET descreve um comportamento observável que pode ser convertido em caça em horas, não em semanas. A leitura complementar recomendada é a nota de Deprecação de Data Sources deste mesmo capítulo, que explica a outra metade da mudança estrutural, e a nota de Novo Modelo de Dados STIX para Defesa, que detalha a mecânica de parsing e de migração de consumidores de STIX e TAXII.