Telemetria Interna (Logs, Netflow, EDR, DNS)

Nota 04 do capítulo 02 (Fontes de Dados e Coleta), tratando a coleta dentro do perímetro da própria organização.
Mapeia a telemetria interna por camada, discute custos de ingestão e prioriza fontes para CTI e threat hunting.
Dialoga com a nota 01 (OSINT), a nota 07 (avaliação de fontes) e com os capítulos 03 (Indicadores) e 06 (Fundamentos de Threat Hunting).

1. Contexto e Posicionamento na Biblioteca

As fontes externas das notas anteriores dizem o que o adversário faz no mundo; a telemetria interna diz o que ele fez na sua casa. Sem telemetria interna bem escolhida, IOC não aciona, hipótese de hunting não tem onde ser testada e relatório de inteligência não vira decisão. Esta nota trata a organização como fonte de coleta: logs de endpoint e de identidade, telemetria de rede, fluxos, DNS, e os serviços de cloud que hoje fazem parte do perímetro efetivo.

O posicionamento na biblioteca é o de contraponto e destino de todo o capítulo. As fontes abertas, comerciais e compartilhadas alimentam watchlists; a telemetria interna é onde essas watchlists são testadas. Ao mesmo tempo, a telemetria interna é a fonte mais cara de todas, porque cada gigabyte ingerido custa licença, infraestrutura e atenção de analista, o que torna a priorização por requisito, e não por disponibilidade, o tema central da nota.

2. Valor Relativo das Fontes Internas

O valor de uma fonte interna não é absoluto, é relativo ao objetivo de inteligência que ela atende. Uma pergunta simples orienta a análise: para responder aos PIRs atuais, esta fonte é necessária, útil ou dispensável? A mesma fonte muda de valor conforme o cenário, porque logs de autenticação são decisivos para ameaça de conta comprometida e quase irrelevantes para phishing de dispositivo pessoal, enquanto telemetria de EDR faz o inverso. A tabela abaixo relaciona objetivos comuns de inteligência às fontes que melhor os atendem.

A leitura da tabela produz uma consequência prática imediata: nenhuma pergunta real de CTI é respondida por uma única fonte, e o desenho de coleta deve cobrir pares, não itens isolados. Autenticação sem NetFlow diz quem entrou, mas não o que fez; proxy sem identidade diz o que saiu, mas não por qual usuário. O padrão de desenho recomendado é escolher o objetivo, mapear a cadeia mínima de fontes que responde à pergunta de ponta a ponta e aceitar a lacuna documentada onde a fonte não existe.

A direção do fluxo também importa e costuma ser esquecida. Telemetria interna não é apenas destino de IOC externo; ela é a fonte primária do CTI de saída, aquele que transforma observação própria em inteligência compartilhável, como tratam as notas 01 e 03 deste capítulo. Um beacon confirmado internamente, com domínio de C2 extraído da própria telemetria, vale mais para a comunidade do que dezenas de itens de feed copiados, porque traz a prova de que o indicador é real e está em uso. O programa que só consome externo e nunca produz a partir de interno deixou de completar o ciclo de inteligência.

3. Cobertura por Camada

A cobertura por camada é o inventário mental que todo programa de coleta precisa manter atualizado. Cada camada tem fontes de referência, custo de ingestão típico e armadilhas conhecidas, e a tabela abaixo consolida o essencial de cada uma. O detalhe técnico de configuração de cada fonte pertence aos controles DAT do capítulo 15; aqui, o foco é o valor para CTI e hunting.

Três destaques de camada merecem aprofundamento porque costumam definir a diferença entre SOC que caça e SOC que tria alertas. No endpoint, o Sysmon com configuração refinada entrega o material de hunting mais rico por gigabyte, porque process trees, hashes de binário, chaves de registro e carga de driver sustentam hipóteses que o log de segurança padrão não sustenta. Na rede, o Zeek transforma tráfego em logs estruturados e o NetFlow cobre escala; a combinação de ambos em pontos-chave é a cobertura de rede pragmática da maioria dos ambientes. Na identidade, os logs de IdP moderno contam a história de acesso que o adversário moderno realmente usa, e quase todo incidente grave contemporâneo tem capítulo que só se lê em log de autenticação.

O exemplo abaixo mostra como a mesma telemetria de identidade responde a uma pergunta de hunting completa, com janela, agregação e exclusões explícitas de contas de serviço conhecidas. Consultas desse tipo são o estoque acumulado do capítulo 07, e cada uma indica também qual fonte precisa estar coberta para que a consulta funcione.

// Hunting: autenticação de usuário em país diferente do habitual nas últimas 24h
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where not(AccountUpn has_any ("svc-", "backup-"))
| summarize Países = dcount(Location), Primeiro = min(TimeGenerated),
            Último = max(TimeGenerated) by AccountUpn, IPAddress
| where Países >= 2
| extend Observacao = strcat(Países, " países em 24h; janela ", Primeiro, " a ", Último)

4. Custos de Ingestão e Priorização

Custo de ingestão tem quatro componentes que precisam entrar na conta antes de ligar qualquer fonte. O custo de licença do SIEM, cobrado por volume ou por nó; o custo de infraestrutura, que cresce com retenção e com paralelismo de busca; o custo de operação, que inclui tuning, normalização e manutenção de parsers; e o custo de atenção, o mais esquecido, porque cada volume adicional dilui a atenção do analista que precisa triar o que aciona. Uma fonte barata de licença pode ser cara de atenção se acionar mil alertas por semana, e a métrica correta nunca é volume de log, é valor por alerta acionável.

A prática de mercado para segurar custo é a arquitetura em camadas de temperatura, aliada a filtros de descarte documentados. Dados quente, morno e frio com retenções diferentes permitem que hunting pesado rode sobre a janela quente e que baselines históricos vivam no frio barato. Filtros de descarte, como registros de saúde de agente e debug verboso, cortam volume sem perder valor, e cada descarte é documentado com justificativa e revisão semestral, porque descarte esquecido vira lacuna de coleta ninguém lembra por quê.

A tabela abaixo resume o padrão de camadas com os critérios de classificação que evitam discussões ad hoc a cada fonte nova. O critério dominante de classificação não é a origem do dado, é a pergunta que precisa ser respondida com ele e o prazo máximo aceitável de resposta.

# Exemplo de política de fonte: prioridade, custo e retenção por camada
fonte: dns_resolver_interno
prioridade: 1          # 1 essencial, 2 valioso, 3 conveniente, 4 adiar
objetivos: [C2_dns, exfiltracao, movimento_lateral]
volume_estimado_gib_dia: 4.2
camada: quente
retencao_dias: 90
descartes: [healthcheck, respostas_cache_estaticas]
notas: "Hosts críticos resolvem via resolver; monitorar bypass direto na borda"

A priorização propriamente dita funciona como fila com critérios explícitos, avaliada por trimestre. Uma fonte entra na frente quando atende PIR ativo sem substituto; fica para trás quando duplica valor de outra fonte mais barata ou quando não existe capacidade de responder ao que ela vai acionar. O antipadrão é o inverso, ligar tudo o que o agente suporta entregar e decidir depois o que analisar, porque isso consome o orçamento inteiro com ruído e deixa as lacunas exatamente onde o adversário passa.

No ambiente de cloud, a armadilha de custo tem forma própria e merece atenção separada. Plataformas cobram por volume por provedor, chaves de serviço verbosas multiplicam o custo de audit logs, e regiões ou contas de teste esquecidas continuam emitindo log que ninguém consome. O controle pragmático é orçamento por conta e por serviço, com alerta de desvio de volume semana a semana, porque o desvio inesperado é ao mesmo tempo risco financeiro e possível indicador de abuso da própria plataforma.

5. Priorização para CTI e Threat Hunting

CTI e hunting têm demandas diferentes sobre a mesma telemetria, e o desenho de coleta precisa atender às duas. O CTI precisa de fontes que permitam testar watchlist de IOC e TTP com latência baixa, o que privilegia endpoint, DNS e proxy; o hunting precisa de profundidade histórica e de campos ricos, o que privilegia Sysmon, Zeek e logs de autenticação com retenção longa. A matriz abaixo cruza a pergunta típica de cada disciplina com a fonte que responde, e serve de checklist de cobertura no inventário de dados disponíveis.

O exercício de tradução da matriz em detecção mostra por que a coleta correta é pré-requisito. A regra Sigma abaixo usa exatamente os campos que a telemetria de endpoint deve garantir; se o campo ParentImage não está ingerido, a regra não roda, e a lacuna aparece como detecção impossível, não como dado faltante.

title: Tarefa Agendada Criada por Binário Fora do Padrão
id: b0e1c2d3-0000-4000-8000-5f6a7b8c9d0e
status: experimental
description: Criação de tarefa agendada por processo com caminho incomum
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        Image|endswith: '\\schtasks.exe'
    filter_process_tree:
        ParentImage|startswith:
            - 'C:\\Windows\\'
    condition: selection and not filter_process_tree
falsepositives:
    - Ferramentas de gerenciamento legítimas
level: medium

Dois critérios finais fecham a priorização para hunting. O primeiro é a taxa de resposta a consulta, porque fonte que leva minutos para responder pergunta binária de Hunting não sustenta processo iterativo, e isso puxa arquitetura de busca dedicada para os dados quentes. O segundo é a estabilidade de esquema, porque hunting depende de consultas reutilizáveis e esquema que muda sem controle quebra o catálogo de hunts acumulado; a normalização em modelo comum, tratada nos controles DAT, é pré-requisito para a biblioteca de hunts do capítulo 07.

6. Ciclo de Validação da Coleta

Coleta que nunca é validada degrada em silêncio, e o ciclo de validação é o que distingue inventário real de inventário documental. O padrão mínimo tem três verificações recorrentes. A primeira é técnica e automatizada, com monitoramento de volume e de latência por fonte, porque queda de 90 por cento no volume de Sysmon durante um fim de semana é sintoma de agente parado que ninguém percebe. A segunda é de cobertura, com consultas de presença por camada que confirmam que cada host crítico está reportando. A terceira é de exercício, com ataques sintéticos ou purple teaming que executam técnicas conhecidas e confirmam que a telemetria captura o que deveria capturar.

O teste de cobertura por técnica é o elo que liga esta nota ao capítulo 15 e ao 19. Executar uma técnica como criação de serviço remoto (T1021) ou tarefa agendada (T1053) em ambiente controlado e verificar se os eventos esperados, 7045 e 4698 entre outros, chegam ao SIEM com todos os campos é a única prova honesta de que a hipótese de hunting daquela técnica é testável. As lacunas encontradas alimentam a matriz de priorização da seção anterior e viram item de backlog com custo estimado, o que fecha o ciclo entre validação e priorização.

7. Erros Comuns e Pontos de Atenção

• Medir programa de coleta por gigabytes ingeridos; efeito: incentivo a volume barato e ruidoso; correção: medir por PIR coberto e por alerta acionável produzido.
• Ingerir tudo e nunca descartar; efeito: orçamento de SIEM consumido por debug e healthcheck; correção: filtros de descarte documentados com revisão semestral.
• Confiar no EDR como única fonte de endpoint; efeito: cegueira quando agente é desligado ou no host não gerenciado; correção: par EDR com Sysmon ou logs nativos nos ativos críticos.
• Aceitar NetFlow amostrado para hunting fino; efeito: beacon de baixo volume desaparece na amostragem; correção: fluxo completo ou sFlow no segmento que interessa.
• Ignorar a camada de identidade; efeito: incidente de conta comprometida invisível ao SOC; correção: IdP e autenticação como prioridade 1 na matriz.
• Não documentar lacunas de cobertura; efeito: hipótese não testada parece hipótese refutada; correção: registro de lacuna por objetivo, com plano de fechamento.
• Coletar DNS apenas na borda; efeito: resolução direta por workload contorna o registro; correção: logging no resolver interno e alerta de bypass direto.

8. Integração com o Restante da Biblioteca

A telemetria interna é o destino obrigatório do ciclo do capítulo 02: os IOC das notas 01 a 03 são testados aqui, e o resultado do teste alimenta de volta a avaliação de fonte da nota 07. É também a base material do capítulo 03, que transforma observação interna em indicadores classificados, e do capítulo 06, onde o inventário de dados disponíveis é passo fundacional da metodologia de hunting. As métricas de cobertura deste capítulo conectam-se ao capítulo 11, e o detalhe de implantação de cada fonte tem aprofundamento nos controles DAT do capítulo 15.

A fronteira com o próximo capítulo é nítida e serve de síntese operacional: até aqui, a coleta reuniu observáveis de todas as origens, abertas, pagas, compartilhadas e internas. O capítulo 03 começa exatamente onde esta nota termina, no momento em que o observável bruto recebe classificação, validade, proveniência e formato de indicador, para que possa circular entre detecção, hunting e compartilhamento sem perder a informação que faz dele inteligência e não apenas dado.