Falta de Dados ou Qualidade de Logs

Nota 01 do capítulo 12 - Desafios e Boas Práticas. Abre o capítulo de desafios pelo obstáculo mais estrutural do hunting: dados insuficientes ou de baixa qualidade inviabilizam a hipótese antes da primeira consulta.
Trata diagnóstico de lacunas com matriz técnica x dados, priorização de coleta por valor de caça, saneamento de dados e a negociação da coleta com a TI.
Dialoga com o grupo DAT do capítulo 15, com a nota de qualidade de dados do capítulo 02 e com a salvaguarda TH.1.

1. Contexto e Posicionamento na Biblioteca

Nenhum desafio limita tanto o alcance real de um programa de hunting quanto a coleta insuficiente. Hipótese boa, analista bom e plataforma boa produzem zero resultado quando o dado que responderia à pergunta nunca foi coletado, e a dor é silenciosa: a consulta retorna vazia, o analista não sabe se a resposta é que nada aconteceu ou que nada foi registrado, e a lacuna permanece invisível até a próxima caça tropeçar nela de novo. Esta nota trata o problema como tratável, com diagnóstico, priorização, saneamento e negociação, porque coleta melhora por gestão, e não por lamento.

O posicionamento no capítulo é de fundação: as notas seguintes assumem dados presentes e tratam do que fazer com eles. A nota conecta a salvaguarda TH.1, que exige o inventário dos dados disponíveis, aos grupos DAT do capítulo 15, que definem o que coletar por domínio, e ao capítulo 02, que já estabeleceu os critérios de qualidade de fontes. O leitor deve sair da nota com três artefatos: uma matriz de lacunas da própria organização, um backlog de coleta priorizado e um roteiro de negociação com a TI.

2. O Problema da Coleta Insuficiente

O problema tem três faces distintas que exigem soluções diferentes, e confundi-las é o primeiro erro de diagnóstico. A face de ausência é o dado que nunca existiu: o host não tem Sysmon, a GPO desativou a auditoria de processo, o DNS interno não é logado. A face de paridade é o dado que existe para uma parcela do parque e não para o resto, e caçar sobre cobertura parcial produz conclusões erradas com aparência de rigor, porque o achado ausente na área sem telemetria parece inexistente. A face de qualidade é o dado presente mas insuficiente: sem campo de linha de comando, truncado, duplicado, com fuso errado ou com hora dessincronizada.

O custo da lacuna não se distribui de forma uniforme no tempo, e esse é o argumento financeiro da coleta. Dado não coletado hoje é passado que não se investiga amanhã: quando a organização descobre no sexto mês que precisa de eventos de criação de processo, ela não pode retroativamente caçar os 180 dias anteriores, e o adversário que passou nesse período permanece indetectável para sempre. A decisão de coleta é, portanto, uma decisão sobre o futuro investigável da organização, e merece a mesma seriedade de uma decisão de backup.

Os sintomas operacionais da coleta insuficiente são reconhecíveis e valem como lista de verificação da própria operação: consultas que retornam vazio com frequência acima do esperado; hipóteses adiadas no backlog com o rótulo informal de quando tivermos esse log; divergência entre o que o inventário da TH.1 declara e o que a consulta real encontra; e investigações em que a cronologia tem buracos inexplicáveis entre eventos que deveriam encadear. Cada sintoma é um ponteiro para uma célula da matriz da seção 3, e a prática recomendada é registrar o sintoma no momento em que aparece, porque a memória do buraco é curta.

3. Diagnóstico de Lacunas: Matriz Técnica x Dados

O diagnóstico começa pelas hipóteses que a organização quer poder caçar, e não pelo catálogo de fontes. O método cruza as técnicas ATT&CK prioritárias para o perfil de ameaça com as fontes e campos que as responderiam, marcando o estado de cada célula. O fragmento abaixo ilustra o formato:

Cada linha da matriz é um requisito de coleta candidato, e o estado da célula define o tipo de trabalho: ausente exige habilitar, parcial exige ajustar campo ou retenção, coletado exige apenas manutenção. A leitura vertical, por técnica, revela quais hipóteses estão viáveis hoje; a leitura horizontal, por fonte, revela qual mudança de configuração destrava quantas perguntas, e é essa leitura que alimenta a priorização da seção seguinte. Ferramentas como o DeTT&CT e o ATT&CK Navigator visualizam essa matriz em escala, com pontuação de cobertura por técnica e por fonte de dados.

3.1 Estados e Evidência

Os três estados da matriz têm definição operacional que impede autodeclaração otimista. Coletado significa que o evento chega ao SIEM com os campos necessários e que a verificação foi feita consultando o dado, e não lendo a configuração; parcial significa que o evento chega, mas falta campo, cobertura de parque ou retenção; ausente significa que não há coleta, com a causa registrada, quando conhecida. A regra de evidência é a mesma da avaliação de maturidade do capítulo 06: mostrar a consulta, e a célula que não tem consulta que a prove é tratada como ausente até segunda ordem.

3.2 Medindo a Cobertura Real

Além do estado por célula, a matriz precisa da medida de paridade, quantos hosts de cada classe realmente reportam cada fonte. A consulta abaixo, executada no próprio SIEM, separa o host que não existe do agente que morreu:

Heartbeat
| where TimeGenerated > ago(24h)
| summarize UltimoEvento = max(TimeGenerated) by Computer, SourceSystem
| where UltimoEvento < ago(1h)

A leitura operacional do resultado define a ação: host ausente na lista é ativo desligado ou aposentado, e host presente no inventário e ausente no heartbeat é agente morto, que é o defeito silencioso mais comum de paridade. A prática recomendada é executar a verificação semanalmente, porque a paridade degrada continuamente com imagem nova, descomissionamento e falha de agente, e um buraco de paridade de 15 por cento do parque é suficiente para esconder exatamente o host que o adversário escolheu.

4. Priorização de Coleta por Valor de Caça

Coleta compete por orçamento de ingestão, armazenamento e atenção da TI, e a priorização correta cruza valor analítico com custo. O valor analítico de um dado é função da relevância das técnicas que ele destrava para o perfil de ameaça da organização e do número de hipóteses do portfólio que ele habilita; o custo é função de volume de ingestão, impacto de performance nos hosts, esforço de implantação e atrito organizacional. A tabela consolida os critérios com escala sugerida:

A recomendação de gestão é priorizar pelo quociente entre valor e custo, com ajuste de urgência para técnicas ativas no setor no momento, e não pelo critério de completude que tenta cobrir tudo. A prática de mercado mostra que poucas fontes, bem escolhidas, habilitam a maioria das hipóteses de alto valor: telemetria de processo, autenticação, tarefa agendada e DNS cobrem um conjunto desproporcional de técnicas de intrusão comuns, e é por isso que programas maduros começam por aí, antes de discutir captura integral de pacote.

O exemplo abaixo pontua três requisitos do backlog com a escala da tabela, em uma leitura de quociente simples entre o somatório de valor e o de custo:

A leitura do exemplo é o ponto da seção: os dois primeiros requisitos custam menos que um terço do terceiro e destravam cinco vezes mais hipóteses, e a fila se decide por número, e não por entusiasmo com tecnologia nova. O requisito de pontuação baixa não é negado; ele volta à pauta quando o perfil de ameaça mudar, o custo cair ou a hipótese que ele destrava subir de prioridade, e é a reavaliação periódica que mantém a fila viva.

5. Saneamento: Clock Skew, Campos Faltantes e Eventos Desativados

O saneamento ataca os três defeitos de qualidade que mais sabotam correlação na prática. O primeiro é o clock skew, a divergência de relógio entre hosts, que desloca eventos no tempo e quebra cronologias: uma cadeia de execução em host com relógio 4 minutos adiantado aparece depois do efeito, e o analista descarta a correlação que era a resposta. A correção é sincronização NTP com servidor autoritativo e monitoramento de drift, com verificação simples e contínua:

w32tm /query /status
w32tm /query /configuration
w32tm /stripchart /computer:ntp.interno.corp /samples:3 /dataonly

O segundo defeito é o campo faltante, o evento chega, mas sem o atributo que a caça precisa. O caso canônico é o evento 4688 de criação de processo do Windows, que por padrão não registra a linha de comando e que, sem ela, vira contagem sem conteúdo; a habilitação é feita por GPO ou registro, com o custo conhecido de aumento de volume e a recomendação de começar pelos servidores. O terceiro defeito é o evento desativado, em geral por GPO de hardening herdada de outra era, que calou auditorias inteiras sem que ninguém documentasse o porquê; auditorias de linha de defesa, como as do CIS e o próprio 4688, estão entre as vítimas mais comuns. O trecho abaixo é o diagnóstico mínimo de auditoria e a habilitação do campo crítico:

auditpol /get /category:"Detailed Tracking"
auditpol /get /subcategory:"Process Creation" /subcategory:"Account Management"

rem Habilitar linha de comando no 4688
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" ^
  /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f

Duas regras de saneamento fecham a seção. Primeiro, toda alteração de auditoria entra por processo de mudança com teste em grupo piloto, porque habilitar auditoria em escala sem medir impacto é receita para a TI revogar tudo no primeiro incidente de performance. Segundo, o saneamento é contínuo, e não projeto: imagens novas, filiais novas e reorganizações de GPO reintroduzem defeito permanentemente, e a verificação periódica da matriz de cobertura é o que mantém o dado confiável ao longo do tempo.

O quarto defeito, que anda com o clock skew e merece verificação própria, é o fuso horário e o formato do timestamp. Fontes que registram em hora local, outras em UTC, e plataformas que interpretam a string de tempo de formas diferentes produzem a mesma cronologia quebrada do drift, com a diferença de que o defeito é sistemático e por isso mais difícil de perceber, porque desloca todo mundo na mesma medida. A regra da biblioteca é registrar e armazenar em UTC, converter para hora local apenas na apresentação, e validar a conversão com um evento de horário conhecido, como a execução de uma tarefa agendada de hora marcada:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 3 |
  Select-Object TimeCreated, @{n='UTC'; e={$_.TimeCreated.ToUniversalTime()}}

6. O Negócio da Coleta com a TI

A coleta é pedida à TI, e a qualidade da negociação determina o ritmo do programa mais que qualquer decisão técnica interna. O enquadramento que funciona é o de requisito de projeto com justificativa de risco, e não o de desejo do SOC: a entrega é descrita em termos de objetivo, evento, campo, parque-alvo, volume estimado, impacto esperado e prazo, com a lacuna de caça que o dado fecha explicitada em uma frase. O pedido que diz que, sem o evento 4756, a caça de manipulação de contas é inviável na rede inteira recebe prioridade que o pedido de "mais logs" nunca recebe.

O diálogo melhora quando o SOC chega com o custo mapeado, porque a objeção realista da TI é volume, performance e janela de mudança, nessa ordem. A prática recomendada é estimar ingestão por host e por dia com uma semana de medição em piloto, declarar o impacto de performance medido no piloto e propor o rolamento pelos grupos de mudança que a TI já opera, integrando a coleta ao fluxo existente em vez de criar um fluxo paralelo. Em contrapartida, o SOC assume obrigações que dão segurança à TI: acompanhar o dado por 30 dias após a habilitação, reportar anomalias de volume e revisar a configuração em cada ciclo de auditoria.

Quando o atrito persiste, dois caminhos costumam destravar. O primeiro é o patrocinador: a lacuna de coleta que aparece no relatório executivo da nota 04 do capítulo 11, com o risco que mantém, transforma conversa técnica em decisão de gestão, e isso é legítimo quando a TI nega por capacidade e não por razoabilidade. O segundo é a troca de valor: o SOC oferece à TI o produto de que ela precisa, como o baseline de autenticação que identifica contas de serviço com senha prestes a expirar, e a coleta passa a ser moeda de benefício mútuo, que é a forma mais durável de qualquer negociação interna.

A estrutura que institucionaliza a conversa é o compromisso de coleta entre SOC e TI, formalizado em três cláusulas simples: a TI garante a habilitação e a paridade das fontes acordadas, por processo de mudança normal; o SOC garante o acompanhamento do dado por 30 dias após cada habilitação, com reporte de volume e de anomalias; e as duas partes revisam o compromisso no ritograma mensal, com a matriz de cobertura como pauta. O documento não precisa de formalidade de contrato; precisa de existência, porque compromisso verbal de coleta não sobrevive à primeira troca de gerente de infraestrutura.

7. Exemplo de Plano de Melhoria de Coleta

O backlog abaixo organiza os requisitos derivados da matriz da seção 3 no formato operacional do programa, com prioridade pelo método da seção 4:

O plano vira gestão com três rotinas. A revisão mensal do backlog no ritograma do programa, com prioridade reavaliada pelo perfil de ameaça corrente; a medição de aderência ao critério de aceitação, porque requisito sem verificação vira conversa; e a atualização da matriz de cobertura a cada entrega, que é o momento em que a hipótese antes inviável entra no portfólio de caça. O plano que segue essas três rotinas transforma o desafio do capítulo em melhoria mensurável, que é o padrão de toda a biblioteca.

O dimensionamento do backlog segue a capacidade real de implementação da TI, e não a lista de desejos do SOC: dois a quatro itens ativos por ciclo mensal é o ritmo que a maioria das operações sustenta sem prejudicar o restante da agenda de infraestrutura. Itens novos entram na fila com prioridade provisória e esperam a revisão mensal, e a disciplina de fila única, com tudo registrado e priorizado no mesmo lugar, evita o atalho informal em que o pedido urgente de hoje fura a fila e desmoraliza a priorização construída.

8. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem com regularidade em programas que tratam coleta como pré-condição dada:

• Caçar sobre cobertura parcial e concluir ausência: consulta vazia em parque sem telemetria uniforme não é evidência de nada; declarar a cobertura é parte do resultado da caça.
• Coletar por completude: habilitar tudo o que a plataforma aceita afoga o orçamento de ingestão e enterra o sinal; coleta segue hipótese, e a priorização da seção 4 é o antídoto.
• Ignorar o clock skew: correlações quebradas por minutos de drift são atribuídas a falso negativo da fonte, e o defeito real persiste por anos.
• Alterar auditoria sem piloto: mudança em escala sem medição de impacto gera veto da TI e retrocesso do programa.
• Delegar a coleta e esquecer a verificação: GPO herdada, imagem nova ou migração desfazem a coleta silenciosamente; verificar é obrigação do SOC, não da TI.
• Pedir sem custo estimado: pedido de "mais logs" sem volume, impacto e benefício calculado depende de empatia para avançar, e empatia não escala.

Um ponto final de atenção é a armadilha inversa, o perfeccionismo de coleta que adia a primeira caça indefinidamente. O programa começa com o dado que existe hoje, documenta a lacuna que a primeira caça revelou e usa a lacuna como primeiro item real do backlog; o ciclo de caçar, documentar lacuna, coletar e caçar melhor é o motor de maturidade do capítulo 06, e funciona melhor que qualquer plano de coleta teórico.

9. Integração com o Restante da Biblioteca

A nota é a fundação prática do grupo DAT do capítulo 15: DAT.1 e DAT.2 definem o que coletar por domínio, DAT.4 centraliza no SIEM, DAT.5 trata qualidade e retenção, e esta nota fornece o método de diagnóstico, priorização e negociação que faz esses controles acontecerem em ambiente real. A matriz técnica x dados é a visão operacional da salvaguarda TH.1, e o backlog de coleta alimenta diretamente o grupo MAP, porque cada entrega fecha células de cobertura que o heatmap cobra.

Para frente, a nota 02 deste capítulo trata do problema simétrico: quando o dado existe em excesso e o alerta, e não a lacuna, é o obstáculo. O exercício de fechamento é construir a matriz da seção 3 para cinco técnicas prioritárias do próprio ambiente, marcar estados com evidência de coleta real, ou seja, consultando o SIEM, e não com declaração da TI, e transformar as duas células mais críticas em requisitos COL com critério de aceitação. O artefato final, matriz com evidência e backlog com critério, é o documento que converte a conversa sobre falta de dado em agenda de entrega, e é o padrão que o resto do capítulo assume como ponto de partida.