TH.2 - Estabelecimento de Baselines

Nota do grupo HNT, Preparação para Threat Hunting, derivada do Capítulo 11 do
Framework CTH. O controle TH.2 transforma telemetria agregada em referências
estatísticas de normalidade, matéria-prima das hipóteses de desvio que
sustentam a caça comportamental e a detecção de IOBs.

1. Contexto e Posicionamento no Framework CTH

As baselines comportamentais são o alicerce da caça orientada a anomalias e dos Indicadores de
Comportamento, os IOBs. Sem referência de normalidade, cada hunt é puramente exploratório e o
hunter não tem como distinguir comportamento malicioso de ruído operacional legítimo. Com
baselines documentadas, hipóteses vagas do tipo "algo estranho nos logons" se convertem em
testes objetivos, do tipo "logon de perfil funcional X fora da janela que concentra 99% dos
acessos do grupo".

O Framework CTH exige baselines de rede, endpoint e comportamento de usuário calculadas sobre
períodos estáveis de pelo menos 30 dias e revisadas mensalmente. Esse requisito não é
burocracia: janelas curtas capturam sazonalidade parcial, como ciclos de fechamento financeiro
ou picos de negócio, e produzem falsos desvios. A revisão mensal garante que mudanças legítimas
do ambiente, como um novo aplicativo de alta frequência, não virem fonte permanente de alarmes
irreprodutíveis.

2. Relação com INS.5: Consumir e Estender as Baselines de Ativos

O controle INS.5 define baselines de normalidade no nível de ativos: serviços esperados, portas
abertas, processos típicos por papel de sistema e configuração padrão. TH.2 consome essa camada
como base e a estende em duas direções. Primeiro, amplia o escopo para perfis funcionais de
usuários e segmentos inteiros de rede, dimensões que o inventário de ativos não cobre
isoladamente. Segundo, adiciona a dimensão temporal, transformando listas de estado em séries
estatísticas com mediana, percentis e desvio padrão.

A divisão de trabalho funciona assim: INS.5 responde "o que deveria existir e como deveria
estar configurado", enquanto TH.2 responde "como isso se comporta ao longo do tempo". Um
servidor web cuja lista de processos casa com a baseline do INS.5 ainda pode apresentar desvio
temporal relevante, como um pico de conexões DNS às três da manhã que nenhuma lista estática
capturaria. A caça comportamental precisa das duas camadas juntas, e o catálogo do TH.1 garante
que as fontes usadas por ambas estejam catalogadas e saudáveis.

3. Dimensões a Baselinizar para Hunting

Nem toda telemetria merece baseline no primeiro ciclo, e a ordem de implementação deve seguir o
retorno por esforço. As dimensões a seguir formam a lista inicial recomendada, alinhada às
salvaguardas do controle e às técnicas prioritárias da matriz de visibilidade do TH.1.

A priorização entre dimensões deve considerar as técnicas prioritárias do programa. Uma
organização com PIRs voltados a exfiltração deriva mais valor de baselines de DNS e de volumes
por segmento. Uma organização exposta a ransomware beneficia-se primeiro de baselines de
processos e de autenticações entre sistemas, onde o comportamento da ameaça aparece antes da
criptografia.

4. Construção Prática: Segmentação, Estatística e Versionamento

A primeira decisão prática é a segmentação, porque agregar demais esconde desvios e segregar
demais produz baselines sem amostra suficiente. Segmentar por perfil funcional de usuário, tipo
de host e segmento de rede costuma equilibrar as duas forças. Uma baseline genérica de
"usuários" é inútil quando o time de desenvolvimento e o financeiro têm padrões opostos, e uma
baseline por indivíduo quebra a cada rotatividade de equipe.

A segunda decisão é a estatística aplicada. Médias simples escondem caudas e induzem limiares
errados, então a prática recomendada usa mediana, percentis tipicamente P95 e P99, e desvio
padrão para definir faixas de normalidade e limiares de alerta. Outliers identificados durante
a construção devem ser investigados e não descartados, porque um outlier pode ser um job
legítimo não documentado, um episódio de teste esquecido ou, eventualmente, um comprometimento
real que a construção da baseline acabou de revelar.

A terceira decisão é o versionamento. Cada baseline deve carregar versão, janela de cálculo,
filtros aplicados e data de geração, permitindo que um hunt executado seis meses depois saiba
exatamente com qual referência comparou. O versionamento também permite regressão: quando um
limiar gera excesso de falso positivo, a comparação entre versões mostra qual mudança de
comportamento legítimo causou o efeito.

Um exemplo concreto ajuda a fixar o formato. O segmento de servidores web apresenta média de
2.500 conexões TCP por hora, com P95 de 3.100, sendo 80% HTTPS e o balanceador de carga como
top talker com 35% do tráfego. Esses números, versionados e armazenados, transformam a pergunta
"o servidor está estranho?" em teste objetivo contra faixas conhecidas.

5. Armazenamento e Acesso para o Hunter

Baseline que não é consultável não é baseline, é arquivo morto. As referências devem ser
materializadas em tabelas agregadas na própria plataforma de análise, em dashboards sobrepostos
às consultas de caça e em exports periódicos para notebooks. O hunter precisa comparar o evento
observado com a referência dentro da mesma ferramenta, sem depender de planilhas manuais que
ficam desatualizadas.

// Construção mensal da baseline de logons por perfil funcional e hora
SigninLogs
| where TimeGenerated > ago(30d)
| extend Hora = hourofday(TimeGenerated)
| extend DiaSemana = dayofweek(TimeGenerated)
| summarize Logons = count(), Origens = dcount(IPAddress)
  by PerfilFuncional, DiaSemana, Hora

A tabela resultante deve ser persistida com nome versionado, por exemplo BaselineLogons_v06, e
atualizada por job mensal. Dashboards exibem o evento observado contra a faixa do P95, e
exports para notebooks permitem análises estatísticas mais profundas quando a caça exige
modelagem adicional.

6. Uso em Hipóteses de Desvio

Baselines existem para gerar e testar hipóteses de desvio, o tipo de hipótese mais
característico da caça comportamental. Uma hipótese bem formulada cita a dimensão, o desvio
esperado e o limiar estatístico que caracteriza o achado. Exemplos válidos: contas de serviço
que se autenticam interativamente fora do padrão registrado, host que inicia sessões RDP para
servidores que nunca receberam RDP do seu papel e volume de DNS por host acima do P99 por três
horas consecutivas.

O exemplo a seguir testa logons do perfil financeiro em janela noturna de fim de semana,
período que a baseline indica como de atividade praticamente nula.

// Desvio: logons do financeiro em janela sem registro na baseline
let b = BaselineLogons_v06
| where PerfilFuncional == "financeiro"
| summarize LogonsMax = max(Logons) by DiaSemana, Hora;
SigninLogs
| where TimeGenerated > ago(24h)
| extend Hora = hourofday(TimeGenerated)
| extend DiaSemana = dayofweek(TimeGenerated)
| where PerfilFuncional == "financeiro"
  and DiaSemana in (time(0d), time(6d))
  and Hora between (0 .. 5)
| join kind=leftanti b on DiaSemana, Hora
| project TimeGenerated, UserPrincipalName, IPAddress

Como a tabela de baseline só contém combinações de dia e hora com atividade observada, o anti
join devolve exatamente os logons que ocorreram em janela nunca registrada. Quando a baseline
registra zero logons na janela, qualquer hit é desvio e vira achado, que deve alimentar o
registro do hunt no formato do TH.4 com evidência, limiar violado e decisão tomada.

7. Ciclo de Atualização e Risco de Baseline Contaminada

Baselines precisam de ciclo de atualização explícito, com recálculo mensal e revisão semestral
dos filtros e da segmentação. O recálculo absorve mudanças legítimas lentas, como crescimento
orgânico de tráfego, e a revisão semestral confronta a estrutura da baseline com mudanças
estruturais, como novo aplicativo, reorganização de segmentos ou migração para nuvem. Sem ciclo
definido, as baselines velhas geram falso positivo em cascata até que a equipe deixe de confiar
nelas.

O risco mais traiçoeiro é a baseline contaminada, calculada sobre um período que já continha
atividade maliciosa. Um beaconing ativo durante os 30 dias de cálculo entra como normalidade, e
a caça passa a buscar desvios do próprio comportamento do adversário. As mitigações práticas
são revisar outliers durante a construção antes de consolidar, confrontar a baseline com
inteligência tática sobre infraestrutura de C2 conhecida, validar o período de cálculo contra
incidentes e alertas do mesmo intervalo e recalcular após qualquer incidente confirmado
relevante.

8. Salvaguardas por Nível

9. Erros Comuns e Pontos de Atenção

• Construir baseline única e global, sem segmentação, que dissolve o desvio real na média do
  conjunto. A segmentação por perfil funcional, tipo de host e segmento de rede é obrigatória
  desde o primeiro ciclo.
• Usar média simples e limiares fixos, ignorando caudas de distribuição. Percentis e desvio
  padrão evitam o alarme constante sobre grupos legítimos de comportamento atípico.
• Descartar outliers sem investigação durante a construção, perdendo a única chance de capturar
  atividade maliciosa que acabou de entrar na amostra.
• Deixar de versionar janela, filtros e limiares, o que torna os hunts irreprodutíveis e impede
  auditoria de por que um desvio foi classificado como normal naquela época.
• Aceitar baseline contaminada por atividade maliciosa, principalmente em períodos posteriores
  a incidentes. Validação contra incidentes e recálculo são obrigações, não melhorias
  opcionais.
• Tratar alerta de desvio como veredito, encerrando a investigação no próprio alarme. O desvio
  abre um hunt, que só se encerra com as regras do TH.4.

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

TH.2 depende do TH.1, pois só é possível baselinizar fontes catalogadas, com retenção e
qualidade conhecidas, e consome o INS.5 como camada base de estado por ativo. As hipóteses de
desvio geradas alimentam a fila do TH.5, que as pontua junto às hipóteses derivadas de
inteligência, e a execução segue o processo do TH.4, com template, cadência e peer review.
Alertas calibrados sobre desvios podem ser convertidos em regras automatizadas pelo grupo
AUT.x, elevando hunts maduros a detecção permanente.

Nas interfaces externas, as baselines apoiam o PRT.x na calibração de regras de detecção que
dependem de normalidade, e fornecem referência objetiva para o IR.x durante a resposta, quando
é preciso decidir rapidamente o que é desvio no host comprometido. As métricas do grupo MET.x
devem acompanhar taxa de falso positivo por baseline, tempo médio entre versões e número de
hipóteses de desvio executadas por ciclo, fechando o laço entre estatística, operação e
governança do programa de hunting.