TH.1 - Inventário de Dados Disponíveis para Hunting

Nota do grupo HNT, Preparação para Threat Hunting, derivada do Capítulo 11 do
Framework CTH. O controle TH.1 transforma telemetria coletada pelo grupo DAT em
capacidade de caça mensurável, catalogando fontes, campos, retenção e qualidade
contra as técnicas do MITRE ATT&CK que o programa precisa testar.

1. Contexto e Posicionamento no Framework CTH

O Threat Hunting só pode investigar o que o ambiente consegue enxergar, e o Framework CTH
posiciona TH.1 como o primeiro controle de preparação justamente para eliminar pontos cegos
antes de qualquer caça. Um programa mal informado sobre os próprios dados produz investigações
inconclusivas, desperdiça horas de analistas seniores e gera falsa sensação de segurança,
porque a ausência de achados reflete ausência de telemetria e não ambiente limpo. O inventário
de dados para hunting é o mapa operacional que responde, para cada hipótese candidata, quais
fontes suportam o teste, com quais campos, dentro de qual janela de retenção e com qual grau de
confiabilidade.

Existe uma diferença fundamental entre ter telemetria e saber o que se pode caçar com ela. O
grupo DAT garante a coleta e a centralização de logs, mas a coleta não declara, por si só,
quais perguntas analíticas estão respondíveis. Sem o inventário, o hunter descobre as
limitações no meio da investigação: o campo necessário não é coletado, o log expirou há semanas
ou a latência de ingestão impede a análise do episódio recente. Cada descoberta tardia desse
tipo converte uma hipótese promissora em tempo perdido e mina a credibilidade do programa.

2. Da Telemetria Coletada à Capacidade de Caça

A conversão de telemetria em capacidade de caça exige responder três perguntas por fonte. A
primeira define quais campos estão disponíveis para consulta e se são preenchidos de forma
consistente, porque campos nulos ou imprevisíveis invalidam consultas inteiras. A segunda
estabelece a janela útil de retenção, já que hipóteses sobre intrusões antigas dependem de
dados mornos ou frios. A terceira mede a latência de ingestão, pois caças sobre atividade
recente precisam de dados disponíveis em minutos ou horas, e não em dias.

Essas três dimensões precisam estar registradas no catálogo com o mesmo rigor de um schema de
banco de dados. Para cada fonte, o inventário documenta o formato dos eventos, os campos
consultáveis, o índice ou tabela onde residem, as ferramentas com direito de consulta e o
responsável pela manutenção da fonte. Essa documentação permite que qualquer hunter monte uma
consulta correta na primeira tentativa, sem depender de conhecimento tribal de quem implementou
a coleta.

3. Mapeamento de Fontes por Técnica ATT&CK

O núcleo técnico do TH.1 é o data source mapping, o cruzamento sistemático entre técnicas do
MITRE ATT&CK e as fontes capazes de evidenciá-las. Para cada técnica prioritária, o inventário
registra qual telemetria seria necessária, se ela é coletada no ambiente e qual a qualidade
observada. O resultado é uma matriz de visibilidade que separa hipóteses testáveis de hipóteses
bloqueadas por lacuna de dados, e serve de insumo direto para a priorização do TH.5.

A tabela a seguir ilustra o formato recomendado para essa matriz, com exemplos típicos de um
ambiente corporativo Windows.

A coluna de qualidade merece atenção especial, porque o status "coletada" não garante
telemetria utilizável. Um evento gravado sem os campos relevantes, com relógio dessincronizado ou com
amostragem agressiva induz o hunter a erro mesmo quando existe dado no índice. A qualidade deve
ser avaliada por amostragem periódica, comparando eventos reais com o schema documentado, e
qualquer degradação deve entrar como problema rastreável no inventário.

4. Lacunas de Visibilidade e Seu Custo

Cada célula da matriz sem cobertura representa uma lacuna de visibilidade com custo concreto e
mensurável. Sem o log de criação de processos (evento 4688 ou Sysmon 1), não existe hipótese
testável de execução de ferramentas nativas; a pergunta sobre qual binário um servidor executou
fica literalmente sem resposta nos dados. Sem logs DNS, desaparecem as hipóteses de exfiltração
por túnel e de resolução de domínios de C2. Sem telemetria de autenticação entre sistemas, o
mapeamento de movimentação lateral depende de conjectura em vez de evidência.

O custo dessas lacunas aparece em três frentes distintas. Na operação, o hunter monta consultas
sobre fontes inadequadas e encerra hunts com veredito não conclusivo, consumindo horas caras de
especialista. Na governança, a organização não consegue afirmar se foi comprometida por uma
técnica específica, o que degrada a qualidade das declarações feitas após incidentes e perante
auditorias. Na estratégia, hipóteses sobre técnicas de adversários relevantes ao setor ficam
permanentemente fora da fila do TH.5 por impossibilidade técnica, e pior, sem que ninguém tenha
decidido conscientemente por isso.

5. Documentação Viva do Inventário de Dados

O inventário só tem valor enquanto reflete a realidade da plataforma de coleta, e por isso deve
ser tratado como documento vivo e não como projeto entregue uma única vez. Planilhas estáticas
envelhecem rápido: mudanças de retenção, migrações de SIEM, substituição de EDR e novos
segmentos de rede alteram o inventário em semanas. A prática recomendada é mantê-lo em um
repositório versionado acessível à equipe de hunting, com histórico de alterações e data da
última revisão por fonte.

Campos mínimos recomendados para cada entrada do catálogo:

• Identificador e nome da fonte, com tipo de telemetria (endpoint, rede, nuvem, aplicação) e
  dono técnico responsável pela coleta.
• Local físico e lógico dos dados: índice do SIEM, tabela, repositório de objetos ou console
  dedicado, com as ferramentas autorizadas a consultá-los.
• Schema e campos consultáveis, incluindo observações sobre campos preenchidos de forma
  inconsistente ou ausentes em versões antigas do agente.
• Retenção efetiva nas camadas quente, morna e fria, e latência média de ingestão medida, e não
  a prometida pelo fornecedor.
• Técnicas ATT&CK suportadas, com referência à matriz de visibilidade, e hipóteses atualmente
  bloqueadas por limitação da fonte.

A revisão completa da matriz de visibilidade deve ocorrer trimestralmente, conforme a
salvaguarda intermediária do controle. Revisões pontuais devem ser disparadas sempre que a
infraestrutura de coleta mudar, o que mantém o catálogo sincronizado com a realidade sem
esperar o ciclo trimestral.

6. Priorização de Novas Fontes e Ciclo de Revisão

Novas fontes não devem entrar no ambiente por curiosidade técnica, mas para fechar lacunas da
matriz em técnicas prioritárias. O fluxo recomendado parte da matriz de visibilidade,
identifica a técnica prioritária sem cobertura, propõe a fonte candidata com estimativa de
volume, custo de licenciamento e impacto de privacidade, e só então aciona o grupo DAT para
implementar a coleta. Um exemplo clássico é a técnica T1003.001 sem cobertura, resolvida pela
ativação do Sysmon 10 com filtragem cuidadosa, ou a ausência de logs de nuvem, resolvida pela
ingestão de CloudTrail e de logs de assinatura do provedor.

Toda introdução de fonte ou mudança de cobertura deve disparar atualização do inventário e
reclassificação das hipóteses bloqueadas. Uma fonte nova converte hipóteses inviáveis em
testáveis, e esse efeito deve ser registrado para que a fila do TH.5 reflita a capacidade real
do ambiente. O inventário também deve ser reexaminado em mudanças estruturais de plataforma,
como migrações de SIEM, pois retenção, nomes de campos e janelas de busca raramente sobrevivem
intactos a migrações.

7. Implementação Prática e Salvaguardas por Nível

A validação periódica das fontes é exigência da salvaguarda intermediária e se materializa em
consultas programadas que verificam presença, volumetria e cobertura de campos. O exemplo a
seguir verifica diariamente se o log de criação de processos está chegando da quantidade
esperada de hosts.

// Validação diária da fonte de criação de processos (evento 4688)
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4688
| summarize Hosts = dcount(Computer), Eventos = count()
| extend Saude = iff(Hosts < 500, "Revisar coleta", "OK")

Alertas automáticos de ausência ou degradação completam o ciclo, pois uma fonte que para de
enviar dados é uma lacuna silenciosa até a próxima caça. O dashboard avançado do controle
consolida essas verificações em visão única de saúde da capacidade de caça.

8. Erros Comuns e Pontos de Atenção

• Tratar o inventário como projeto com data de entrega e não como documento vivo, resultando em
  catálogo desatualizado que engana os hunters. O inventário precisa de dono, histórico de
  alterações e revisão trimestral obrigatória.
• Confundir coleta com qualidade, assumindo que a presença do evento no índice garante dados
  utilizáveis. A amostragem periódica de eventos reais contra o schema documentado é a única
  verificação honesta.
• Ignorar fontes de nuvem e SaaS no levantamento, deixando fora logs de plano de controle,
  assinatura e gateway de e-mail, justamente onde boa parte dos adversários modernos opera.
• Documentar a retenção contratada em vez da retenção efetiva por camada, criando expectativas
  falsas sobre caças em dados antigos.
• Formular hipóteses sem consultar a matriz de visibilidade, o que produz hunts condenados à
  inconclusão antes da primeira consulta. A checagem no catálogo deve fazer parte da fase de
  preparação do TH.4.
• Deixar a matriz de lacunas sem consequência, sem transformá-la em pedidos concretos de coleta
  para o grupo DAT. Lacuna documentada que não vira trabalho é burocracia disfarçada de
  maturidade.

9. Integração com Outros Controles do Framework CTH

TH.1 consome diretamente os controles DAT.1 a DAT.5, que descrevem o que é coletado, como é
centralizado e qual qualidade e retenção foram pactuadas, e devolve a esses controles a visão
de quais lacunas impedem caças reais. A relação com MAP.4, análise de lacunas, é bidirecional:
a matriz de visibilidade do TH.1 é a entrada primária para o mapeamento de lacunas de
cobertura, e os resultados do MAP.4 reabrem a discussão sobre fontes a serem priorizadas. O
INS.1 fornece o inventário de ativos que permite julgar a criticidade da cobertura de cada
fonte, pois telemetria de ativo crítico vale mais que telemetria de ativo irrelevante.

Para dentro do grupo HNT, o catálogo alimenta o TH.2, cujas baselines só podem ser construídas
sobre fontes catalogadas e saudáveis, e o TH.5, cuja pontuação de viabilidade depende
diretamente do status de coleta de cada hipótese. O TH.4 usa o catálogo na fase de preparação
de cada hunt, e o TH.3 recebe dele as definições de quais dados devem existir em réplica no
ambiente isolado. Fechando o ciclo de governança, as métricas de cobertura e saúde de fontes
devem ser derivadas das validações automatizadas implementadas por este controle, garantindo
que a gestão enxergue a capacidade de caça como número mensurável, e não como impressão.