TH.15 - UEBA e Detecção Comportamental

Nota do grupo HNT (Threat Hunting) do Framework CTH, seção "15 - Framework CTH - Controles".
Deriva do Capítulo 13, controle TH.15, e trabalha sobre os mesmos dados de identidade e telemetria
de TH.11, TH.12 e TH.14. Papel no programa: estabelecer perfis de comportamento por entidade, peneirar
desvios que abrem hipóteses de caça e detectar contas comprometidas que não disparam nenhuma assinatura.

1. Contexto e Posicionamento no Framework CTH

O controle TH.15 do grupo HNT introduz a análise de comportamento de entidades no framework. UEBA, sigla
de User and Entity Behavior Analytics, é a disciplina de construir perfis de comportamento para usuários,
hosts, contas de serviço, aplicações e outros ativos, e de sinalizar desvios significativos desses
perfis. A premissa é que o insider malicioso e a conta comprometida usam credenciais válidas e seguem
fluxos de trabalho aparentemente legítimos, sem malware para assinatura nenhuma pegar; o que sobra para
detectar é o desvio sutil de padrão, acessos a recursos nunca antes tocados, horários atípicos, volumes
de dados fora da curva.

Dentro da esteira do framework, o TH.15 é o elo entre a coleta de dados (DAT.x), a identidade limpa do
inventário (INS.x) e o processo de hunting (TH.4, TH.6). Ele não substitui o hunter: alimenta o hunter. O
desvio apontado pelo modelo é uma hipótese em estado bruto, que entra na fila priorizada de TH.5 e
precisa ser investigada com o mesmo rigor de qualquer outra caça. Ao mesmo tempo, os achados confirmados
retroalimentam os perfis, e as exceções legítimas viram parte do baseline. Esse papel de peneira de
hipóteses é o que distingue UEBA maduro de promessa de detecção automática sem analista.

2. O que o UEBA Mede

O objeto central do UEBA é a entidade, e não o evento. Cada entidade, usuário, host, conta de serviço,
acumula séries de métricas comportamentais ao longo do tempo, e o sistema compara o comportamento recente
contra o histórico da própria entidade e contra o grupo de pares equivalente. As métricas mais comuns em
plataformas de mercado são as seguintes.

A leitura conjunta dessas categorias é o que dá força ao sinal: um acesso fora de hora sozinho é ruído,
mas acesso fora de hora, a um servidor novo, com volume de leitura três vezes acima do histórico e
seguido de upload externo é padrão multidimensional de comprometimento ou de exfiltração por insider.

3. Perfis por Entidade e por Grupo de Pares

O perfil individual responde à pergunta: como esta entidade se comporta historicamente? O perfil de grupo
de pares responde a outra pergunta: como entidades equivalentes se comportam? O peer group é construído
por função, departamento, senioridade e local, e é essencial porque novos funcionários e funções móveis
não têm histórico suficiente para perfil individual estável. Comparar um analista financeiro com o
restante do departamento financeiro detecta desvio mais rápido e com menos falsos positivos do que
comparar apenas com o próprio passado dele.

O exemplo prático clássico: a conta de um analista do departamento fiscal, que historicamente toca oito
sistemas do domínio fiscal em horário comercial, passa em três dias a acessar quinze servidores que nunca
tocou, a maioria do domínio de pesquisa e desenvolvimento, com atividade iniciada às 03h00. Nenhum evento
individual é alarmante, e nenhum antivírus dispara. O perfil do departamento fiscal, porém, não tem
servidores de pesquisa na lista de recursos tocados por nenhum de seus membros, e o peer group sinaliza o
desvio imediatamente. É essa camada comparativa que faz o UEBA valer mais do que consultas manuais
agregadas.

4. Sinais Comportamentais Típicos

Os sinais que concentram a maior parte dos achados confirmados em programas UEBA são: volume anômalo de
downloads ou cópias para mídia e nuvem pessoal, acessos fora do horário estabelecido do perfil,
movimentação entre sistemas incomum para o peer group, escalações de privilégio sem correspondência com
mudança de função e autenticações geograficamente impossíveis. Cada sinal tem uma família de falsos
positivos conhecida, e a tabela abaixo resume as duas faces.

5. Requisitos de Dados e de Maturidade

O UEBA é um consumidor exigente de dados. Os requisitos mínimos são telemetria consistente por pelo menos
seis meses para perfis com sazonalidade, identidade limpa com contas duplicadas e compartilhadas
resolvidas, mapeamento de entidade entre sistemas (o usuário X é o login Y no ERP e o e-mail Z no cloud)
e qualidade de campos de origem estável ao longo do tempo. Onde o controle DAT.5 mostra telemetria
inconsistente ou identidade suja, o UEBA produz perfis de ruído, e cada desvio sinalizado nasce
desacreditado perante o analista.

A maturidade organizacional pesa tanto quanto a maturidade dos dados. Um time que ainda não executa hunts
de TH.6 a TH.10 com regularidade não tem capacidade de consumir a fila de desvios que um UEBA produz, e o
resultado prático é uma fila de anomalias ignoradas que descredita a plataforma. A recomendação do
framework é escalar UEBA junto com a capacidade de caça, e não antes dela.

6. Falsos Positivos e Tuning

Toda implantação real passa por um ciclo longo de tuning, e a gestão honesta dessa fase é o que separa
programas que sobrevivem dos que são desligados em seis meses. As causas estruturais de falso positivo
são: mudança de função do usuário sem atualização do perfil, sazonalidade de negócio que nenhum modelo
captura no início, feriados e reorganizações, ferramentas de gestão que agem em nome de contas humanas e
contratações em massa com padrão novo de acesso. As táticas de tuning são as seguintes.

• Ajustar limiares por peer group, e não global, porque a variância natural de um departamento técnico não é a mesma de um departamento jurídico.
• Excluir de geração de perfil, e não de coleção, as contas de serviço documentadas, evitando que rotinas automáticas contaminem a média humana.
• Instituir revisão semanal de desvios com registro da decisão, alimentando um catálogo de exceções versionado com justificativa e validade.
• Fechar o ciclo com o feedback do IR.x: todo desvio confirmado como ataque vira caso de calibração, e todo desvio confirmado como benigno vira exceção.
• Medir a taxa de desvios investigados que viram caso, porque a razão de utilidade, e não o volume de alertas, é a métrica que demonstra valor.

7. Implantação em Fases

A implantação recomendada segue fases curtas com valor entregue em cada uma. Na primeira fase, perfis
descritivos por departamento com relatórios mensais de desvio, sem alerta automático, para calibrar
expectativa e levantar exceções. Na segunda fase, alertas para duas ou três categorias de sinal de maior
valor, tipicamente impossível travel e escalação de privilégio, com fila revisada semanalmente pelo
hunter. Na terceira fase, correlação de desvios com inteligência de ameaças, escalando prioridade quando
o desvio coincide com campanha ativa contra o setor ou alerta de ISAC. Na quarta fase, risk score
unificado por entidade combinando rede, autenticação, dados e endpoint, com integração ao SOAR para
enriquecimento automático antes da fila chegar ao analista.

O exemplo abaixo ilustra um job de detecção estatística de desvio de volume de acesso a
compartilhamentos, do tipo que uma plataforma UEBA ou o módulo de ML do SIEM executa continuamente.

job: desvio_volume_arquivos
tipo: analise_estatistica
entidade: usuario
metrica: bytes_lidos_em_compartilhamentos
janela_historica: 90d
janela_deteccao: 24h
limiar: p99_historico_do_peer_group
filtros:
  - excluir: contas_de_servico_catalogadas
  - excluir: backups_e_scans_agendados
saida:
  destino: fila_de_hunting
  severidade: media
  campos: [usuario, peer_group, p99, observado, ratio, top_compartilhamentos]

8. UEBA como Peneira de Hipóteses e Não como Verdade

O princípio operacional deste controle é que o desvio abre a hipótese, e o hunter a fecha. Um risk score
alto não é veredito de comprometimento; é um argumento de priorização, equivalente a um IOC de alta
confiança que precisa de contexto. A investigação do desvio segue o método TH.4: o analista formula a
hipótese em formato SE-ENTÃO, escolhe as fontes que a confirmam ou refutam, executa consultas sobre
telemetria e produz decisão documentada. O caso do perfil fiscal que acessa pesquisa e desenvolvimento
termina de três maneiras possíveis: incidente confirmado e aberto no IR.x, exceção legítima documentada
no catálogo ou sinal inconclusivo que permanece monitorado. As três saídas agregam valor ao programa.

Essa postura evita o dois erros simétricos. Tratar cada desvio como ataque esgota a equipe e criminaliza
o funcionário, inclusive com risco jurídico e trabalhista. Tratar o UEBA como sistema de vigilância
automática que dispensa análise transforma a plataforma em geradora de alertas ignorados, o pior destino
possível para um investimento desse porte. O ponto médio, desvio como hipótese priorizada, é o desenho
que o framework adota.

9. Salvaguardas por Nível de Maturidade

As salvaguardas seguem o padrão de subcontroles do framework, do Básico ao Avançado.

10. Erros Comuns e Pontos de Atenção

O erro estrutural mais comum é implantar UEBA sem governança de identidade. Com contas compartilhadas,
logins genéricos de fornecedor e usuários com múltiplos vínculos, o modelo perfila um agregado de pessoas
como se fosse uma, e cada desvio se torna intrinsecamente ambíguo. Antes de qualquer perfil, o Inventário
precisa responder quem é a pessoa por trás de cada identidade, e o time de identidade precisa ter rotina
de desativação imediata de contas órfãs. O segundo erro é esperar detecção automática sem hunter: a fila
de desvios é uma fila de hipóteses, e hipótese sem analista é ruído envelhecendo.

O terceiro erro é medir sucesso por volume de alertas gerados, incentivo que empurra a plataforma para o
limiar mais sensível e para o descrédito rápido. A métrica correta é a razão entre desvios investigados e
casos gerados, somada ao tempo médio de investigação. O quarto erro é ignorar privacidade: perfis
comportamentais de pessoas são dados pessoais de alta sensibilidade, e o programa precisa de base legal,
transparência com o RH e jurídico, retenção definida e acesso restrito, em linha com o que DAT.5 e a
legislação de proteção de dados exigem. A integração natural deste controle é com TH.14, que dá a trilha
de autenticação que o perfil consome, com CTI.7, que recebe a corroborância comportamental de campanhas
ativas, e com IR.x, que recebe os desvios confirmados como caso.