Coleta e Normalização de Dados

Nota 03 do capítulo 07 (Processo e Metodologias de Hunting), tratando dos dados sobre os quais toda caça é executada.
Cobre o mapeamento de dados por técnica ATT&CK, a normalização de logs com CIM, ECS e OCSF, o enriquecimento no momento da consulta e as lacunas de coleta como resultado legítimo de caça.
Consome o plano de caça da nota 01 e a evidência esperada da nota 02, e fornece a base de dados que a execução da nota 04 consulta.

1. Contexto e Posicionamento na Biblioteca

Toda hipótese formulada na nota 02 declara evidência esperada em uma fonte e em um campo, e essa declaração só se sustenta se a coleta e a normalização forem reais. Uma caça contra movimento lateral com logs de autenticação incompletos, campos renomeados por fonte ou carimbos de tempo inconsistentes produz resultados que parecem refutações e são apenas cegueira. Esta nota posiciona os dados como matéria-prima do processo: mapear o que existe, padronizar o vocabulário dos campos, enriquecer no momento certo e registrar o que falta como resultado de caça, e não como falha pessoal do hunter.

Na biblioteca, a nota consome a telemetria interna e o pipeline de coleta descritos no capítulo 02 e os controles DAT do capítulo 15, que definem o que deve ser coletado por categoria de fonte. Dialoga com o mapeamento ATT&CK do grupo MAP do mesmo capítulo, porque a cobertura de dados é a metade da cobertura de detecção que o grupo mede. À frente, a execução da nota 04 assume campos normalizados, e a documentação da nota 05 registra lacunas de coleta que retroalimentam o capítulo 02 e o planejamento de ingestão do SIEM.

2. Mapeamento de Dados por Técnica ATT&CK

O mapeamento de dados por técnica responde à pergunta central do hunting: para cada técnica relevante, quais fontes, campos e identificadores de evento permitem observá-la? O ATT&CK fornece a estrutura com suas fontes de dados e componentes de dados, e ferramentas como o ATT&CK Navigator e o DeTT&CT transformam esse mapeamento em matriz visual de cobertura. A prática recomendada mantém uma tabela viva que cruza técnica, fonte, campo chave, retenção e cobertura estimada, revisada a cada caça e a cada mudança de arquitetura de coleta, porque cobertura declarada que não é testada em caça tende a envelhecer mal.

A qualidade do mapeamento é julgada por quatro dimensões, emprestadas da qualidade de dados aplicada a telemetria. Completude: o campo existe em todas as fontes que prometem registrá-lo. Tempestividade: o evento chega ao índice dentro da latência esperada, porque caça contra dados atrasados compara janelas desiguais. Consistência: o mesmo conceito tem o mesmo nome e o mesmo formato em todas as fontes, o que é o trabalho da normalização da seção 3. Validade: os valores respeitam o domínio esperado, com carimbos de tempo em UTC e ações no vocabulário estável. Um mapeamento sem nota nessas quatro dimensões é uma hipótese de cobertura, e não um fato.

O mapeamento serve a dois usos complementares. Antes da caça, ele diz ao hunter se a evidência esperada da hipótese é tecnicamente observável no ambiente, evitando caças fadadas ao resultado vazio. Depois da caça, ele é corrigido com o que a execução revelou, tanto sobre fontes que registraram mais do que o esperado quanto sobre campos ausentes que ninguém havia notado. A pontuação de cobertura por fonte transforma o mapeamento em ranking acionável para o backlog de coleta. Os quatro critérios abaixo são suficientes para uma primeira nota de 0 a 5 por fonte:

• Cobertura de parque: proporção de hosts que efetivamente enviam a fonte, medida por amostragem e não declarada.
• Densidade de campo: proporção de eventos com os campos chave preenchidos, e não apenas presentes no esquema.
• Retenção efetiva: período real disponível para consulta, comparado com a janela exigida pelas hipóteses da fila.
• Custo de ingestão: volume e preço de trazer a fonte para o índice, que limita quantas melhorias cabem no ano.

O quadro abaixo exemplifica o formato para cinco técnicas do domínio Enterprise, e a tabela completa da seção 6 expande o mesmo padrão campo a campo.

Técnica T1059.001 PowerShell
  Fonte 1: EDR de processo | Campos: linha de comando, processo pai, hash
  Fonte 2: Log do PowerShell | Event ID 4103 e 4104 | Campo: ScriptBlockText
  Retenção: 90 dias | Cobertura estimada: 95% dos servidores, 70% das estações
  Observação: 4104 só registra scriptblock com conteúdo interpretável

Técnica T1003.001 LSASS Memory
  Fonte 1: Sysmon | Event ID 10 | Campos: TargetImage lsass.exe, GrantedAccess
  Fonte 2: EDR | Acesso a processo e leitura de memória
  Retenção: 180 dias | Cobertura estimada: 100% dos hosts com agente
  Observação: GrantedAccess 0x1010 e 0x1410 são os padrões de dumping

3. Normalização de Logs: CIM, ECS e OCSF

Ambientes reais agregam fontes que nomeiam o mesmo conceito de formas diferentes: o processo executado aparece como NewProcessName no Windows, process.command_line no ECS e process.cmd no OCSF. Sem normalização, cada caça reescreve a mesma lógica por fonte, as junções entre fontes quebram e as consultas viram patrimônio de quem as escreveu, em vez da instituição. Os três esquemas dominantes atacam o problema de formas complementares, e a escolha depende da plataforma, mas a decisão estrutural é uma só: padronizar o vocabulário no ponto de ingestão, e não na cabeça de cada hunter durante a consulta.

A escolha entre esquemas é, na prática, a escolha da plataforma, e a camada de tradução é o que importa. Ambientes com mais de um produto convivem com mais de um esquema, e a defesa contra o caos é uma camada interna de nomes canônicos, mesmo que mínima, com conversores declarados por fonte. O antipadrão é permitir que cada consulta defina seus próprios apelidos de campo, o que multiplica interpretações e transforma qualquer troca de analista em reescrita de consulta. O nome canônico interno também facilita migrar consultas entre plataformas, porque a lógica de negócio fica separada do nome do campo físico.

A normalização não é apenas renomear campos, e inclui decisões de valor que a caça usa o tempo todo. Carimbos de tempo precisam convergir para UTC com fuso explícito, porque janelas de sessão quebram com horas locais misturadas. Valores de ação precisam convergir para vocabulário estável, como permitir, negar e desconhecido, porque stack counting por ação com valores soltos produz pilhas falsas. Identidades precisam convergir para uma forma canônica por usuário, com domínio explícito, porque o mesmo humano aparece como três contatos distintos em três fontes. O bloco abaixo ilustra o antes e o depois de uma normalização de autenticação em SPL usando o CIM do Splunk.

// Antes: lógica acoplada ao sourcetype bruto, quebrando a cada mudança
index=wineventlog (EventCode=4624 OR EventCode=4625)
| stats count by Account_Name, WorkstationName

// Depois: consulta contra o modelo de dados Authentication do CIM
| datamodel Authentication Authentication search
| search Authentication.action="failure" Authentication.app="windows"
| stats count as Falhas by Authentication.user, Authentication.src

4. Enriquecimento no Momento da Consulta

Enriquecimento é a junção da telemetria bruta com contexto que a torna triável: criticidade do ativo, dono do host, sensibilidade da identidade, reputação de endereço e correspondência com inteligência de ameaças. A recomendação prática da biblioteca é enriquecer no momento da consulta, com tabelas de referência atualizadas e consultáveis, em vez de gravar contexto na ingestão sempre que possível. Contexto gravado na ingestão congela e envelhece: o host que era de desenvolvimento quando o evento foi gravado pode ser de produção quando a caça o lê, e a reputação de um domínio muda em dias. Enriquecer na consulta permite também trocar a fonte de contexto sem reprocessar a telemetria.

O bloco abaixo demonstra o padrão em SPL, combinando uma tabela de IOC exportada do MISP com um inventário de ativos, e restringindo a saída ao que é realmente triável. O mesmo padrão existe no KQL com tabelas de referência e no SQL das plataformas de data lake, e a estrutura da consulta se mantém: telemetria primeiro, junções de contexto depois, filtro de relevância por último.

index=proxy sourcetype=zeek_http earliest=-7d
| lookup misp_iocs domain AS host OUTPUT event_tag, misp_confidence
| lookup asset_inventory hostname AS clienthost OUTPUT criticality, owner
| where isnotnull(event_tag) OR criticality="alta"
| stats count as Requisicoes, dc(clienthost) as Hosts by host, event_tag, criticality
| sort -Requisicoes

Duas regras protegem o enriquecimento de virar algoritmo opaco. A primeira é documentar a origem e a atualização de cada tabela de referência, porque um inventário sem data é um inventário desconhecido. A segunda é manter a correspondência com IOC explícita e reversível na consulta, registrando a versão da tabela usada, já que indicadores expiram e um match contra feed desatualizado é um dos falsos positivos mais caros de explicar depois.

O mesmo padrão em KQL usa tabelas de referência em linha para listas pequenas, ou consulta a tabela de IOC sincronizada da plataforma. O exemplo abaixo cruza eventos de rede com infraestrutura de campanha conhecida, mantendo o resultado dentro do teto de triagem:

let ioc = datatable(Dominio: string, Campanha: string)[
  "cdn-update.example.net", "2025-04-campanha-A",
  "mirror-sync.example.com", "2025-04-campanha-A"
];
DeviceNetworkEvents
| where Timestamp > ago(1d)
| extend Dominio = tostring(split(RemoteUrl, "/")[0])
| join kind=inner ioc on Dominio
| project Timestamp, DeviceName, RemoteUrl, Campanha, InitiatingProcessFileName
| take 200

Enriquecimento tem limite prático: cada junção de referência adiciona custo e ponto de falha à consulta, e a tabela que não responde por timeout derruba a caça inteira. A prática recomendada limita as junções de contexto às que mudam decisão de triagem, e mantém o resto para a fase de relato, quando o resultado já é pequeno. O mesmo raciocínio vale para enriquecimento por API no momento da consulta, que é útil em caças manuais e proibitivo em agendas de alta frequência.

5. Lacunas de Coleta como Resultado de Caça

Nem toda caça termina em achado de adversário, e a que termina em lacuna de coleta documentada termina bem. A lacuna aparece de três formas principais: campo ausente, como linha de comando não coletada em parte do parque; fonte ausente, como logs de DNS que existem no projeto e nunca foram ingeridos; e cobertura ausente, como hosts que simplesmente não reportam. Tratar a lacuna como resultado exige registrá-la no relato da nota 05 com precisão suficiente para gerar um requisito de coleta, e não uma frase genérica de que a visibilidade precisa melhorar.

O registro mínimo de lacuna tem cinco campos: técnica investigada, fonte esperada, o que efetivamente falta, hosts e períodos afetados e impacto sobre a hipótese. Esse registro alimenta o backlog de coleta do capítulo 02, que prioriza com o mesmo raciocínio de custo e valor da nota 02, e permite fechar o ciclo no capítulo 15, onde a cobertura de dados por técnica é medida de novo. Sem esse registro, a mesma lacuna será redescoberta por cada hunter que passar pela mesma técnica, pagando o custo de descoberta repetidas vezes.

Registro de lacuna: HUNT-2025-014-R

- Técnica investigada: T1078.003 Contas locais
- Fonte esperada: EID 4624 com auditing de logon avançado
- O que falta: Event ID 4625 habilitado em 40% dos servidores legados
- Afetados: 118 servidores Windows 2012 do datacenter B, período completo
- Impacto: refutação da hipótese impossível para esses hosts
- Ação gerada: requisito de coleta COL-2025-021, prioridade alta

O registro só vira requisito depois de verificado, e a verificação é curta: confirmar na configuração da fonte que o campo está desabilitado, e não apenas ausente na amostra consultada, e estimar o custo de habilitar o que falta. Configurações mudam, e lacuna registrada por outro analista seis meses antes pode ter sido corrigida silenciosamente por uma atualização de agente. A checagem evita que o backlog de coleta acumule pedidos já atendidos, e evita que a caça pague o custo de descobrir a mesma lacuna duas vezes.

A prioridade da lacuna também é relativa ao portfólio de hipóteses, e não absoluta. Lacuna que bloqueia três hipóteses de alta prioridade vira requisito imediato; lacuna que bloqueia uma hipótese de custo alto pode aguardar o próximo ciclo de ingestão, com a hipótese mantida na fila em estado bloqueado. Essa leitura de portfólio é o que impede que o backlog de coleta seja consumido por pedidos isolados, cada um justificado sozinho e, juntos, inviáveis.

6. Tabela Técnica x Fonte x Campo

A tabela abaixo é o extrato operacional do mapeamento da seção 2, no formato esperado nas caças da biblioteca. Cada linha liga uma técnica a uma fonte concreta, aos campos que a caça consulta e ao identificador de evento quando existe. É essa tabela que a nota 02 usa ao declarar evidência esperada e que a nota 04 usa ao escrever consultas, e sua manutenção é o que impede que hipóteses prometam campos inexistentes.

7. Erros Comuns e Pontos de Atenção

O erro mais caro é assumir cobertura sem testar, porque inventários declarativos envelhecem enquanto o parque muda e o projeto de ingestão não é atualizado. O teste mínimo é amostral: escolher hosts representativos e verificar, por consulta direta, se o evento esperado chega e chega completo. O segundo erro é normalizar tarde demais, acumulando consultas acopladas a nomes brutos de campo que quebram a cada atualização de agente ou de plataforma. O terceiro é enriquecer demais na ingestão, gravando contexto volátil dentro da telemetria e criando dados que precisam ser reprocessados quando o contexto muda.

Um erro sutil envolve a retenção: caçar uma técnica com janela de 90 dias contra fontes com 30 dias de retenção real produz refutações falsas, e a inconsistência só aparece quando alguém compara a janela declarada no plano com a retenção efetiva por fonte. A tabela de mapeamento da seção 6 existe, entre outras razões, para expor essa inconsistência antes da caça, e não durante a discussão de resultado.

A normalização também tem custo, e ignorá-lo gera frustração operacional. Conversões pesadas na ingestão aumentam a latência de chegada e consomem capacidade de processamento, e nem toda fonte precisa de normalização completa para a caça funcionar. A decisão racional é normalizar profundamente as fontes que atendem hipóteses da fila, e aceitar nomes brutos nas fontes marginais, com documentação do mapeamento manual no plano de caça. A revisão periódica da fila mostra quando uma fonte marginal se tornou central e merece a conversão completa.

8. Integração com o Restante da Biblioteca

Esta nota converte as promessas das notas 01 e 02 em dados utilizáveis, e a execução da nota 04 devolve ao mapeamento desta nota as correções de cobertura e campo descobertas em campo aberto. As lacunas registradas seguem para a nota 05 como desdobramento formal da caça, e a nota 06 assume que consultas automatizadas só podem depender de fontes estáveis e normalizadas, porque automação sobre campo inconsistente produz alertas quebrados em silêncio.

Com os capítulos anteriores, a nota consome a telemetria e o pipeline de coleta do capítulo 02, e devolve a ele requisitos concretos de ingestão. Com o capítulo 04, compartilha o vocabulário de fontes de dados do ATT&CK, e com o grupo MAP do capítulo 15 compartilha a matriz de cobertura que junta dados e detecção. Com o capítulo 18, a tabela técnica por fonte por campo é o insumo direto da engenharia de detecção, porque regra sem fonte de dados confirmada é alerta hipotético.