INS.5 - Definição de Baselines de Normalidade

Nota do grupo INS (Inventário e Superfície de Ataque) do Framework CTH, derivada do Capítulo 5 do PDF de referência. Este controle fecha o grupo INS ao descrever o comportamento esperado dos ativos e usuários inventariados.
Papel no programa: definir o que é normal por classe de ativo e por usuário, criando o padrão de referência que sustenta IOBs, detecção de anomalias e hipóteses de caça fundamentadas.

1. Contexto e Posicionamento no Framework CTH

As baselines de normalidade são a fundação sobre a qual toda a detecção baseada em comportamento e a análise de anomalias são construídas. É impossível identificar o que é anômalo sem conhecer previamente o que é normal para o ambiente. Sem baselines sólidas, as capacidades de UEBA (User and Entity Behavior Analytics), a detecção de comportamentos suspeitos e a identificação de desvios operacionais ficam severamente comprometidas, e os Indicadores de Comportamento (IOBs) descritos no Capítulo 3 do PDF de referência perdem seu referencial de comparação.

Para o Threat Hunter, a baseline é o que transforma intuição em hipótese testável. A afirmação de que um processo é raro, de que um destino de rede é inédito ou de que um horário de acesso é atípico só tem valor se existir um padrão mensurável contra o qual o desvio seja calculado. A diferenciação entre atividade legítima atípica e atividade genuinamente maliciosa, problema central da análise comportamental, é diretamente proporcional à qualidade da baseline disponível.

Dentro do Framework CTH, o INS.5 fecha o grupo INS ao descrever o comportamento esperado dos ativos inventariados pelo INS.1 e do software inventariado pelo INS.2. Suas baselines alimentam o grupo DET na detecção automatizada e o grupo HNT na formulação de hipóteses, com destaque para as caças baseadas em anomalia conduzidas a partir do TH.2, que assumem explicitamente a existência de um padrão de referência.

2. Conceito: Anomalia Só Existe em Relação a um Padrão

Uma baseline de normalidade é a descrição quantitativa e datada do comportamento esperado de um sistema, usuário ou segmento de rede, expressa de forma que um desvio possa ser calculado. Não é uma lista de permissões nem uma política; é uma medição. A baseline responde perguntas com números: quantas execuções do processo X por dia no tipo de host Y, quais destinos o servidor Z contata por semana, em que horários a conta A autentica habitualmente.

Três propriedades distinguem uma baseline utilizável de uma coleta de estatísticas solta. Representatividade, porque a baseline precisa descrever o funcionamento real, e não o funcionamento desejado. Estabilidade, porque uma baseline que muda todos os dias não permite medir desvio. Segmentação, porque o normal é sempre relativo a uma classe de ativo e a um contexto: o padrão de um servidor de banco de dados não se aplica a uma estação de design, e tratar todos como um só produz referência que não descreve ninguém.

Uma consequência prática frequentemente esquecida é que a baseline também protege o ambiente de si mesmo. Mudanças operacionais não autorizadas, como um serviço novo habilitado em produção ou uma rotina de backup apontando para destino inesperado, aparecem como desvios da mesma forma que atividade adversária, e a revisão desses desvios cria um mecanismo informal de controle de mudança que cobre justamente as alterações que escapam do processo formal. Essa dupla função, detecção e conformidade, explica por que o INS.5 pertence a um grupo de inventário, e não a um grupo de detecção.

3. Dimensões a Baselinizar

O PDF de referência organiza as coletas em três dimensões principais, rede, endpoint e comportamento de usuário, que se detalham nas seguintes linhas de análise:

A segmentação por função do ativo é obrigatória desde a primeira coleta. Agrupar servidores com estações produz baselines médias que não descrevem nenhum dos dois, e a consequência prática é a dupla falha: alerta para o que é normal no grupo atípico e silêncio para o que é anômalo no grupo típico. A segmentação inicial pode seguir o inventário do INS.1 por categoria de ativo, ambiente e criticidade, e ser refinada por função, como servidor web, servidor de banco de dados e jump host.

A referência de consultas DNS exemplifica a simplicidade da primeira coleta. Uma consulta por domínio, com contagem e número de clientes distintos, já sustenta a distinção entre o domínio rotineiro e o domínio consultado por um único host:

DnsEvents
| where TimeGenerated > ago(30d)
| summarize Consultas = count(), Clientes = dcount(ClientIP) by Name
| top 20 by Consultas desc

4. Construção Prática das Baselines

O período mínimo de coleta inicial é de 30 dias de operação normal, conforme o PDF de referência, e é essencial que a janela contenha as sazonalidades relevantes do ambiente, como fechamento mensal, ciclo de folha de pagamento e picos de negócio. Para ambientes com forte variação mensal, a coleta deve cobrir ao menos um ciclo completo da variação, ainda que ultrapasse os 30 dias. Coletar apenas uma semana de um mês com fechamento trimestral, por exemplo, produz referência que falha justamente no dia em que mais importa.

A estatística inicial não precisa ser sofisticada para ser útil. Percentis e desvios padrão por segmento resolvem a maior parte dos casos: definir como normal o intervalo entre o percentil 5 e o percentil 95, e tratar como desvio o que ultrapassar três desvios padrão da média ou um múltiplo do percentil 95, conforme a distribuição. Distribuições assimétricas, comuns em volumes de tráfego, pedem percentis em vez de média, porque a média é arrastada pelos extremos:

index=edr earliest=-30d
| stats count as execucoes by host, process_name
| eventstats perc95(execucoes) as p95, avg(execucoes) as media, stdev(execucoes) as desvio by process_name
| where execucoes > media + (3 * desvio)

A revisão de outliers antes de congelar a baseline é a etapa que separa referência de lixo estatístico. Cada outlier identificado precisa de decisão explícita: é atividade legítima rara, que entra na baseline com anotação; é atividade suspeita, que abre investigação antes de a baseline ser congelada; ou é ruído de coleta, que se elimina na origem. Congelar sem revisar incorpora qualquer comprometimento silencioso existente na janela de aprendizado.

5. Armazenamento e Versionamento

Baselines são artefatos de produção e devem ser tratados como código e dados versionados. Cada baseline precisa registrar o período de coleta, as fontes de dados, os filtros aplicados, a segmentação adotada, as estatísticas resultantes e os parâmetros de desvio vigentes. O versionamento com histórico de alterações permite auditar por que um desvio passou a alertar ou deixou de alertar, e é a base do processo de revisão periódica exigido pela salvaguarda INS.5.4.

baseline: processos_servidor_web
segmento: funcao=servidor_web; ambiente=producao
janela_coleta: 30 dias de operacao normal
fontes: [DeviceProcessEvents]
metrica: execucoes_por_dia_por_processo
normal:
  p5: 2
  p95: 40
desvio: execucoes_por_dia > p95 * 3
excecoes_anotadas: [backup_noturno, agente_monitoracao]
revisao: trimestral

A atualização periódica mínima é trimestral, para acomodar mudanças operacionais legítimas como novas equipes, novos sistemas, mudanças de horário de trabalho e novas aplicações. Baselines desatualizadas geram falsos positivos excessivos, e falsos positivos em massa provocam o desligamento das detecções por fadiga, que é a pior saída possível. Em ambientes dinâmicos, a salvaguarda INS.5.5 descreve o alvo de maturidade: aprendizado automatizado com estatística e machine learning que distinguem sazonalidade de anomalia genuína sem intervenção manual, mantendo a referência viva sem abrir mão da estabilidade.

As baselines também impõem requisitos de retenção ao grupo DAT: a janela de aprendizado de 30 dias e as comparações históricas exigem que as fontes originais permaneçam disponíveis por período suficiente, e a política de retenção precisa prever a recomputação de baselines antigas quando um incidente revelar que a coleta da época estava comprometida. O checklist mínimo da revisão trimestral inclui:

• Comparar a janela de coleta com eventos operacionais do período, como implantações, reorganizações e mudanças de escala.
• Revisar as exceções anotadas, verificando se ainda são legítimas e se algum outlier anotado deixou de existir.
• Validar a segmentação contra o inventário corrente do INS.1, incorporando classes de ativo novas ou extintas.
• Reprocessar as estatísticas e comparar os parâmetros vigentes com os anteriores, explicando cada diferença relevante.
• Publicar a nova versão com changelog e reprocessar as detecções dependentes, evitando referências a versões antigas.

6. Uso em Hunting: Desvio da Baseline como Gatilho de Hipótese

No fluxo de caça, a baseline opera em dois papéis. Como gatilho, o desvio medido contra a baseline é a fonte de hipóteses do tipo descritivo: processos executados por poucos hosts no ambiente, contas autenticando fora do horário habitual, servidores falando com destinos que nenhuma outra máquina da mesma função contata. Como delimitador, a baseline fornece o contraste que confirma ou refuta a hipótese durante a investigação, respondendo se aquele comportamento é novidade ou rotina disfarçada.

// Processos raros no ambiente: executados por poucos hosts em 30 dias
DeviceProcessEvents
| where Timestamp > ago(30d)
| summarize Execucoes = count(), Hosts = dcount(DeviceId) by FileName
| where Hosts <= 3
| sort by Execucoes desc

Um exemplo concreto de hipótese derivada de baseline: a referência de autenticação mostra que contas de serviço do ambiente autenticam em média 400 vezes por dia a partir de duas sub-redes conhecidas; a caça procura contas de serviço autenticando de segmentos de workstation ou com elevação de privilégio no dia, porque o desvio nesse padrão é um dos sinais mais confiáveis de movimento lateral com credenciais válidas. O mesmo raciocínio se aplica a DNS: a baseline de domínios consultados torna imediatamente visível um domínio recém-registrado consultado por apenas um host, combinação que merece investigação quase sempre.

A tabela a seguir resume hipóteses típicas que nascem diretamente de baselines, com a referência usada e a evidência que a caça deve coletar:

Na operação diária, o elo entre baseline e caça aparece em detalhes pequenos: o Threat Hunter que abre uma caça pelo TH.2 anota a versão da baseline usada como referência, e o resultado da caça realimenta a revisão trimestral com novos outliers anotados. Esse ciclo curto entre referência, caça e revisão é o que mantém as baselines alinhadas ao ambiente real, e não ao ambiente de seis meses atrás.

7. Baseline Contaminada e Mitigação

O risco mais perigoso do modelo é a baseline contaminada por comprometimento prévio. Se a janela de aprendizado contém atividade adversária, essa atividade vira padrão, e o ambiente aprende a considerar o adversário normal. O caso extremo é o beaconing de C2 de baixo volume que, coletado durante a aprendizagem, se torna parte do normal e neutraliza a detecção comportamental exatamente na comunicação que mais interessa detectar. Baselines construídas após incidentes, sem revisão crítica do período, carregam o mesmo risco.

A mitigação combina medidas preventivas e corretivas. Na prevenção, revisar outliers antes de congelar, como descrito na construção, e cruzar a janela de aprendizado com IOCs e relatórios de incidentes do período, invalidando coletas que coincidam com incidentes conhecidos. Na correção, reprocessar a baseline após cada incidente confirmado no segmento afetado e manter o histórico de versões para comparar o antes e o depois da remediação. A dúvida sistemática sobre o período de aprendizado é uma postura saudável: baseline não é verdade, é hipótese de referência sujeita a revisão.

Um sinal prático de contaminação é o ambiente que não gera alertas comportamentais há meses, enquanto outros controles registram incidentes. Nesse cenário, a revisão da baseline deve preceder qualquer ajuste de regra, porque o problema provavelmente está na referência, e não na lógica de desvio.

8. Salvaguardas do Controle por Nível

A implantação começa pelas baselines de rede e de endpoint, que dependem apenas de sensores de tráfego e da plataforma de análise de logs já presentes no ambiente. As salvaguardas intermediárias adicionam o comportamento de usuário e o processo formal de revisão, e a avançada automatiza a adaptação da referência. O erro típico de implantação é iniciar pela ferramenta de comportamento sem ter as baselines básicas, o que produz perfis genéricos alimentados por dados mal segmentados.

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

O INS.5 é a pré-condição direta dos IOBs descritos no Capítulo 3 e da detecção comportamental do grupo DET: sem as baselines deste controle, o grupo DET opera com perfis genéricos que geram falsos positivos em massa. Para o grupo HNT, a integração é dupla, pois as baselines geram hipóteses e sustentam o contraste das investigações, com destaque para as caças baseadas em anomalia do TH.2. Para o grupo UEBA aplicado em plataforma, as mesmas baselines servem de insumo e de validação dos modelos de máquina.

A construção das baselines consome os produtos do restante do grupo INS: o inventário do INS.1 define a segmentação por classe de ativo, e o inventário de software do INS.2 explica mudanças de comportamento causadas por novas aplicações. O grupo DAT garante a retenção necessária às janelas de aprendizado, e o grupo MET acompanha a idade das baselines e a taxa de revisão como indicadores de saúde. O efeito final é institucional: a organização passa a discutir desvios com números e histórico, e não com impressões, elevando o nível de toda conversa sobre detecção e caça.