Deprecação de Data Sources

Nota do capítulo 20, dedicado às atualizações do MITRE ATT&CK. Documenta a
descontinuação formal dos objetos Data Sources na v18 de outubro de 2025 e a
consolidação dos Data Components como granularidade primária de dados. Complementa
a nota de Detection Strategies e Analytics e sustenta as decisões de cobertura
de coleta dos grupos DAT e MAP do Framework CTH.

1. Contexto e Posicionamento na Biblioteca

Na v18 do ATT&CK, publicada em outubro de 2025, os objetos Data Sources, aqueles identificados pelos códigos DS0001 a DS0038, foram formalmente descontinuados em todos os domínios. Eles continuam presentes no histórico de versões para referência, porém marcados como deprecados, e o site do ATT&CK direciona o leitor para os Data Components e para as novas Detection Strategies como a forma correta de raciocinar sobre dados de detecção. Para um time de CTI ou de threat hunting, essa mudança altera o vocabulário de mapeamento de coleta que havia sido adotado por centenas de ferramentas e planilhas nos últimos anos.

Esta nota posiciona a mudança dentro do estudo integrado da biblioteca: as notas DAT.1 a DAT.5 do Framework CTH descrevem o que coletar e com que qualidade, e este texto explica por que o ATT&CK mudou a unidade de medida dessa conversa. Ler esta nota junto com a de Detection Strategies é essencial, porque a deprecação dos Data Sources e a criação das estratégias são duas faces da mesma reestruturação da parte defensiva do framework.

2. De Fontes a Componentes: O Que Mudou

O modelo antigo tratava a fonte como a unidade de mapeamento: uma técnica era ligada a fontes como DS0009 Process, DS0026 Active Directory ou DS0015 Application Log. O problema é que uma fonte abriga comportamentos muito distintos entre si. A fonte Process serve tanto para detectar execução de comandos quanto para detectar acesso a credenciais na memória, e o evento concreto que suporta cada caso é diferente. O modelo novo adota o Data Component como unidade, descrevendo a ação específica observável, como Process Creation, Process Access, Active Directory Credential Request ou Windows Registry Key Deletion, cada um com seu identificador DC.

Os componentes não ficam soltos: cada analytics das novas Detection Strategies referencia explicitamente os componentes de dados de que precisa, por meio de x_mitre_log_source_references, e cada componente passou a declarar fontes de log concretas em x_mitre_log_sources. Na prática, isso significa que o ATT&CK agora responde, de forma estruturada, não apenas qual dado detecta uma técnica, mas qual canal e qual identificador de evento sustentam essa detecção. O componente real DC0084, Active Directory Credential Request, por exemplo, declara WinEventLog:Security com EventCode 4768 e 4769 nas suas fontes de log, além de eventos NTLM e requisições LDAP bind.

3. O Papel Histórico das Fontes e Onde Elas Falhavam

Os Data Sources foram introduzidos para dar consistência às notas de detecção das técnicas e, por muitos anos, cumpriram bem esse papel. Eles permitiram a primeira geração de mapeamentos de coleta, inspiraram projetos de cobertura baseados em ATT&CK e serviram de vocabulário em avaliações como as de NDR e EDR, que descreviam o que observavam em termos de fontes. O problema surgiu quando o uso cresceu mais rápido que o modelo: planilhas corporativas começaram a medir cobertura por fonte, como se presença da fonte equivalesse a capacidade de detecção, e a distância entre ter o log e ter a detecção ficou invisível nas métricas.

A falha conceitual central era misturar plano de coleta com capacidade analítica. Uma fonte como DS0022 File se materializa de formas completamente diferentes em Windows, Linux e macOS, e ainda assim recebia um único rótulo no mapeamento. Da mesma forma, DS0014 Pod e DS0031 Cluster existiam para ambientes de Kubernetes, mas pouco diziam sobre qual evento de API do plano de controle sustentava cada detecção. O componente de dados resolve isso ao nomear a ação observável e ao deixar a fonte concreta, com canal e filtro, em um campo próprio.

4. Por Que a Mudança Era Necessária

A granularidade da fonte era grosseira demais para engenharia de detecção e para medição de cobertura. Dizer que uma organização tem a fonte Process coletada não informa se o Event ID 4688 está habilitado com linha de comando, se o EDR cobre process access em LSASS ou se a telemetria chega ao SIEM dentro do SLA. Componentes de dados aproximam o mapeamento da realidade operacional, porque um componente corresponde a algo que se pode habilitar, coletar, versionar e auditar. Com isso, a conversa entre engenharia de detecção, engenharia de dados e hunters passa a usar o mesmo vocabulário.

Há também um ganho de precisão nas lacunas. No modelo antigo, uma lacuna em DS0009 Podia significar dezenas de comportamentos não cobertos; no modelo novo, uma lacuna em Process Access com canal de acesso a LSASS é uma lacuna específica, com caminho de remediação claro. A v18 atualizou os componentes em massa justamente para sustentar esse raciocínio: o domínio Enterprise passou a ter 106 componentes, o Mobile 17 e o ICS 36, todos versionados e referenciados pelos analytics. A tabela abaixo ilustra a diferença de vocabulário.

5. Impacto em Mapeamentos e Ferramentas

Ferramentas construídas sobre o modelo antigo foram o ponto de maior atrito. Camadas do ATT&CK Navigator que coloriam técnicas por presença de fonte de dados, planilhas de gap analysis organizadas por DS, e integrações em TIPs que armazenavam referências x-mitre-data-source deixaram de refletir o estado atual do framework. Projetos comunitários de cobertura de detecção, que usavam fontes como chave de agregação, precisaram migrar seus dicionários para componentes. Times internos herdam o mesmo problema: qualquer inventário que diga "temos DS0029 Network Traffic coberto" precisa ser reescrito em termos dos componentes de Network Traffic que efetivamente são gerados e ingeridos.

Há ainda um efeito sutil em relatórios de CTI. Relatórios que descreviam capacidades de atores por fonte de dados precisam ser relidos, porque a precisão agora exigida é de componente. Um relatório que afirma que o grupo monitorado depende de Active Directory para persistência ganha mais valor se declarar quais componentes, como Credential Request ou Object Modification, sustentam as detecções correspondentes. Essa revisão de linguagem deve fazer parte do ciclo de revisão de mapeamentos descrito nas notas do grupo MAP.

6. Caminho de Migração para Consumidores

A migração recomendada tem quatro etapas sequenciais. Primeiro, inventariar todos os pontos internos que referenciam DS, em planilhas, camadas de Navigator, regras, TIPs e documentação. Segundo, construir um dicionário de tradução de fontes para componentes, usando o próprio bundle STIX como fonte da verdade, já que os componentes mantêm descrição e referências de log. Terceiro, reescrever os inventários de cobertura em termos de componentes, marcando quais componentes são gerados, coletados e retidos no ambiente. Quarto, atualizar os processos de revisão, de modo que novas detecções sejam registradas sempre pelo par componente e analytics, e nunca mais por fonte.

O script abaixo demonstra o núcleo da etapa dois: extrair do bundle a lista de componentes ativos, com suas fontes de log, para servir de base ao dicionário de tradução.

from stix2 import MemoryStore

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

comps = src.query("type = 'x-mitre-data-component'")
for dc in comps:
    ext = dc["external_references"][0]["external_id"]
    logs = dc.get("x_mitre_log_sources", [])
    ch = "; ".join(l.get("channel", "") for l in logs)[:80]
    print(f"{ext} | {dc['name']} | {ch}")

O mapeamento antigo versus novo abaixo exemplifica como o mesmo cenário de detecção se registra antes e depois da v18. O caso é a técnica T1558.003, Kerberoasting, muito usada por atores como APT29 e explorada em caças do capítulo 8 da biblioteca.

Depois de traduzir o vocabulário, a validação de cobertura passa a ser uma consulta direta ao SIEM por componente, e não uma afirmação genérica. O exemplo abaixo, em KQL sobre telemetria de endpoint, verifica se o componente de Process Creation está gerando eventos com as propriedades exigidas por analytics de linha de comando nos últimos sete dias.

DeviceProcessEvents
| where Timestamp > ago(7d)
| summarize Eventos = count(),
            ComLinhaDeComando = countif(isnotempty(ProcessCommandLine)),
            ComHashes = countif(isnotempty(InitialFileHash))
            by bin(Timestamp, 1d)
| extend PercentualLinha = round(100.0 * ComLinhaDeComando / Eventos, 1)
| order by Timestamp desc

Um resultado com Eventos alto e PercentualLinha baixo indica que o componente existe, porém está empobrecido, situação que no vocabulário da biblioteca é uma lacuna de qualidade registrada pela nota DAT.5, e não uma lacuna de coleta. Esse tipo de diagnóstico só se tornou expressável no vocabulário ATT&CK porque o componente e o canal passaram a ser entidades separadas com campos próprios.

A mesma lógica se aplica a caças. Um analytics de Kerberoasting ancorado no componente Active Directory Credential Request e no canal EventCode 4769, com propriedade de criptografia RC4, converte-se em regra de SIEM e em caça com o mesmo vocabulário. O esqueleto abaixo, em formato Sigma, mostra como o par componente e canal de log vira o logsource da regra, eliminando a ambiguidade que o modelo de fontes tinha.

title: Solicitacao de TGS com criptografia RC4 (Kerberoasting potencial)
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketEncryptionType: '0x17'
    filter_admins:
        TargetUserName|endswith: '$'
    condition: selection and not filter_admins
tags:
    - attack.credential_access
    - attack.t1558.003

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

A migração precisa de critérios objetivos, caso contrário vira um exercício de documentação que ninguém fecha. As métricas abaixo combinam o estado do inventário com o estado da coleta, e todas podem ser calculadas automaticamente a partir do bundle STIX e das consultas de presença no SIEM, sem depender de autoavaliação manual.

O ponto de atenção nessas métricas é não perseguir 100 por cento de cobertura de analytics, porque nem todo analytics faz sentido para o ambiente, e coerção produz falsos positivos em massa. A meta saudável é 100 por cento de decisão documentada: para cada analytics relevante, o inventário registra se ele foi implementado, descartado com justificativa ou movido para o roadmap de coleta.

8. Erros Comuns e Pontos de Atenção

O erro mais comum é tratar a deprecação como remoção imediata e quebrar integrações que filtram objetos com x_mitre_deprecated verdadeiro, quando a decisão correta é manter leitura histórica e parar de usar os objetos em mapeamentos novos. Outro erro frequente é assumir que componente de dados equivale a log pronto: o componente declara a ação observável, mas cabe à organização garantir que o canal indicado esteja habilitado, como ativar a auditoria de Credential Request em controladores de domínio, o que gera volume considerável e exige plano de retenção.

Cuidado também com falsos equivalentes ao traduzir. Uma fonte pode se decompor em vários componentes, e dois componentes de fontes diferentes podem sustentar o mesmo analytics, então a tradução one to one raramente existe. Por fim, não confundir componente de dados com fonte de log em si, porque o componente é o conceito, e o campo x_mitre_log_sources apenas sugere implementações típicas; ambientes com EDR, por exemplo, podem materializar Process Access por telemetria própria, sem nenhum Event ID do Windows.

Vale registrar um risco de governança durante a janela de transição, que incluiu revisões pontuais após a v18.0, como o ajuste v18.1 de novembro de 2025. Times que congelaram planilhas no momento da deprecação podem encontrar pequenas divergências entre o que arquivaram e o estado consolidado posterior, então qualquer dicionário de tradução deve citar a versão do bundle usada na conversão. Sem essa citação de versão, auditorias futuras não conseguem reproduzir o mapeamento, e o inventário perde rastreabilidade justamente no ponto em que precisaria prová-la.

9. Integração com o Restante da Biblioteca

Esta nota recalibra o vocabulário das notas DAT.1 e DAT.4 do Framework CTH, que tratam de inventário de dados para hunting e de centralização em SIEM, e fornece a unidade de medida que MAP.4 usa para declarar lacunas de cobertura. Ao reescrever o inventário de coleta em componentes, o time também melhora a nota de Qualidade e Retenção de Dados, porque cada componente passa a ter dono, canal e política de retenção explícitos.

Para hunting, o ganho é direto: hipóteses de caça passam a nascer já ancoradas em componentes, o que acelera a etapa de coleta do hunt loop descrita no capítulo 7. A leitura recomendada em sequência é a nota de Novo Modelo de Dados STIX para Defesa, que mostra como esses componentes viajam no bundle e como automações devem tratar os novos campos, e a nota de Impactos nos Mapeamentos e Ferramentas de Detecção da v19, que mostra o efeito cumulativo dessas mudanças sobre inventários em produção.