Análise Comportamental (UEBA)
Análise comportamental com Machine Learning não supervisionado, pontuação de risco por usuário/entidade e mitigações automáticas configuráveis dentro do módulo Audit do DataDike PAM.
O módulo de Análise Comportamental e Mitigação de Riscos (UEBA — User and Entity Behavior Analytics) do DataDike PAM observa continuamente o comportamento de usuários e entidades privilegiadas, estabelece padrões de normalidade (baseline), atribui uma pontuação de risco dinâmica e aciona mitigações automáticas quando detecta desvios. Diferentemente de regras estáticas, o motor utiliza Machine Learning não supervisionado para aprender o que é "normal" em cada ambiente sem necessidade de rotulagem prévia, reduzindo falsos positivos e revelando ameaças internas, contas comprometidas e abuso de privilégio que passariam despercebidas por filtros convencionais.
Navegação: Audit > Análise Comportamental (UEBA).
O UEBA consome os eventos já coletados pelo cofre, pelos gateways, pela gravação de sessões e pelo command filter. Não requer agentes adicionais nos alvos: a telemetria que alimenta os modelos é a mesma trilha de auditoria gerada pelo PAM.
Visão geral do funcionamento
O ciclo de análise é contínuo e composto por quatro estágios encadeados:
Coleta — ingestão de eventos de autenticação, abertura/encerramento de sessão, comandos executados, acessos ao cofre, elevação de privilégio e metadados de origem (IP, horário, gateway, recurso-alvo).
Aprendizado de baseline — modelos não supervisionados constroem o perfil de comportamento de cada usuário e entidade ao longo de uma janela móvel.
Pontuação de risco — cada evento e cada entidade recebem um risk score normalizado de 0 a 100, recalculado em tempo real.
Mitigação — ao cruzar limiares configurados, o sistema dispara respostas automáticas (alerta, reautenticação, bloqueio de comando, encerramento ou quarentena de sessão) e, quando aplicável, encaminha o evento ao SIEM.
Modelos e casos de uso prontos
O motor é entregue com um conjunto de modelos estatísticos e casos de uso pré-construídos e calibrados, prontos para operar desde o primeiro dia, sem exigir ciência de dados interna. Os modelos não supervisionados detectam anomalias por afastamento estatístico do baseline, dispensando assinaturas ou listas de regras manuais.
Casos de uso incluídos por padrão:
Acesso em horário/dia incomum — login ou sessão fora da faixa habitual do usuário (ex.: madrugada, fim de semana) para aquele recurso.
Frequência excessiva de acessos — volume de aberturas de sessão ou requisições de credencial acima do padrão histórico em uma janela curta.
Comando ou ação suspeita — execução de comandos raros, perigosos ou inéditos para o perfil do operador.
Acesso a recurso atípico — conexão a um alvo que o usuário nunca ou raramente utiliza.
Origem geográfica/de rede anômala — autenticação a partir de IP ou sub-rede fora do conjunto esperado.
Escalada de privilégio anômala — elevação a contas administrativas divergente do comportamento típico.
Os modelos são autocalibrantes: à medida que o comportamento legítimo evolui, o baseline se ajusta automaticamente. O administrador pode ajustar a sensibilidade global e por caso de uso em Audit > UEBA > Modelos e Sensibilidade.
Período de aprendizado e baseline
Em Audit > UEBA > Baseline, define-se a janela de aprendizado:
Janela de baseline
Período histórico usado para calcular o padrão normal de cada entidade.
30 dias
Período de maturação
Tempo mínimo de observação antes de uma entidade passar a gerar score confiável.
7 dias
Modo de aprendizado
Contínuo (recalibração permanente) ou Congelado (baseline fixo após maturação).
Contínuo
Reset de baseline
Reinicia o aprendizado de uma entidade após mudança de função/responsabilidade.
Manual
Durante a maturação, eventos são pontuados em modo observação, registrando o score sem disparar mitigações, para evitar bloqueios indevidos enquanto o modelo aprende.
Pontuação de risco e relatório Users rating
Cada usuário e entidade possui um risk score consolidado, derivado da combinação ponderada dos eventos anômalos recentes, da gravidade de cada desvio e da reincidência. O score decai naturalmente ao longo do tempo quando o comportamento volta ao normal.
O relatório Users rating (em Audit > UEBA > Users rating) lista as entidades ordenadas do maior para o menor risco, permitindo que a equipe de segurança priorize investigação e resposta. Para cada entidade exibem-se:
Score atual e tendência (subindo/estável/caindo).
Principais fatores de risco que compõem o score (ex.: 3 acessos noturnos, 1 comando suspeito).
Última atividade e recurso acessado.
Histórico de score em linha do tempo.
O relatório pode ser filtrado por grupo de RBAC/ABAC, por gateway, por faixa de score e por período, e exportado para análise externa.
Use o Users rating como painel diário de threat hunting: as entidades no topo concentram a maior probabilidade de risco e merecem revisão prioritária.
Análise de solicitações de autenticação
Toda solicitação de autenticação é avaliada contra o padrão histórico do usuário antes de ser concluída. O motor compara horário, origem, recurso-alvo, frequência e método de autenticação com o baseline e atribui um score à tentativa.
Quando o desvio ultrapassa o limiar definido, aplicam-se políticas de bloqueio configuráveis:
Permitir e alertar — autenticação prossegue, mas um alerta é gerado e o score da entidade sobe.
Exigir reautenticação/MFA reforçado — solicita-se um segundo fator adicional antes de liberar.
Bloquear — a autenticação é negada e registrada como evento crítico.
A política é configurada em Audit > UEBA > Políticas de Autenticação, podendo ser segmentada por grupo de usuários, por classe de recurso ou por gateway. Cada disparo gera alerta na console e, opcionalmente, no SIEM.
Mitigações automáticas
As mitigações são acionadas por limiares de score ou por regras de caso de uso e configuradas em Audit > UEBA > Mitigações. É possível definir múltiplas faixas com respostas escalonadas.
Resposta por limiar de score
0 – 39
Baixo
Apenas registro em trilha de auditoria.
40 – 69
Médio
Alerta + reautenticação/MFA reforçado.
70 – 89
Alto
Bloqueio de comandos auditados + alerta prioritário.
90 – 100
Crítico
Encerramento ou quarentena imediata da sessão.
Tipos de mitigação disponíveis
Solicitar reautenticação — ao atingir um limiar de score durante a sessão, o usuário é desafiado a reautenticar (senha, MFA ou aprovação) para continuar; falha encerra a sessão.
Bloquear comandos auditados — comandos classificados como sensíveis pelo command filter são impedidos quando o score está elevado, mesmo que normalmente permitidos.
Encerrar sessão — a sessão privilegiada é finalizada imediatamente e a credencial pode ser rotacionada.
Detecção de horário/dia incomum — aciona mitigação ao identificar acesso fora da janela habitual.
Detecção de frequência excessiva — aciona mitigação quando o ritmo de acessos foge do padrão.
Ação sobre comando/ação suspeita — execução de comando perigoso ou inédito dispara bloqueio e/ou encerramento automático da sessão.
Cada mitigação pode ser configurada em modo automático (executa sem intervenção) ou assistido (aguarda confirmação de um administrador, com janela de tempo definida).
Mitigações de encerramento e quarentena interrompem o trabalho do operador. Recomenda-se validar os limiares em modo observação por um período antes de habilitá-las em produção, evitando impacto operacional.
Classificação de eventos e quarentena de sessão
Todo evento é classificado por nível de risco (Baixo, Médio, Alto, Crítico) com base em seu score, alimentando as respostas automáticas. A resposta pode ser suspensão, encerramento ou quarentena de sessão.
A quarentena de sessão isola a sessão em estado retido: a gravação e os metadados são preservados intactos, o acesso ativo é congelado e a sessão só é liberada mediante ação manual do administrador, com registro de termo/justificativa obrigatório. Isso permite conter um incidente sem destruir evidências e formalizar a decisão de liberação ou descarte.
Fluxo de quarentena (Audit > UEBA > Sessões em Quarentena):
Evento crítico coloca a sessão em quarentena automaticamente.
A sessão aparece na fila com score, fatores de risco e gravação associada.
O administrador revisa as evidências.
Liberar (com termo/justificativa) ou Encerrar definitivamente — ambas as decisões ficam registradas na trilha de auditoria com autor, data/hora e justificativa.
Eventos críticos configuráveis
Em Audit > UEBA > Eventos Críticos, definem-se as condições que devem ser reportadas automaticamente como crítico, independentemente do baseline. Cada regra associa um nível de risco/score e uma medida automática (alerta, bloqueio, encerramento, quarentena).
Critérios de detecção suportados:
Comandos Linux — lista de comandos (e argumentos) que caracterizam evento crítico ao serem executados em sessões SSH/terminal.
Aplicações/processos Windows por elevação — identificação de processos que solicitam elevação, classificados por:
Hash do arquivo — correspondência pelo hash criptográfico do executável (resistente a renomeação).
Caminho do arquivo — correspondência pelo caminho completo do executável no sistema-alvo.
Expressões regulares sobre comandos — regex aplicada ao texto dos comandos auditados, permitindo capturar padrões variáveis (ex.: tentativas de exfiltração, alteração de contas, desligamento de serviços de segurança).
Eventos manuais — o administrador cadastra um evento próprio definindo nível/score e medidas automáticas, útil para refletir políticas internas específicas da organização.
Comando Linux
Sessões Unix/Linux
Nome/argumentos do comando
Aplicação/processo Windows
Sessões Windows
Hash ou caminho do arquivo
Expressão regular
Qualquer comando auditado
Padrão regex
Evento manual
Definido pelo administrador
Regra customizada + nível/score
A identificação por hash é mais robusta contra evasão (cópia do binário com outro nome), enquanto a identificação por caminho é útil para bloquear ferramentas instaladas em locais padronizados. As duas podem coexistir na mesma regra.
Proteção de Controladores de Domínio (Active Directory)
O UEBA integra-se à proteção de Controladores de Domínio do Active Directory mediada pelo PAM. Todo acesso administrativo a um DC passa pelos controles do produto:
MFA obrigatório na abertura de sessão.
Aprovação prévia (fluxo de workflow) antes da concessão de acesso.
Políticas de comando restringindo operações sensíveis no DC.
Gravação completa de sessão (vídeo/teclado/comandos) preservada para auditoria.
Sobre esses acessos, o motor comportamental aplica integralmente baseline, pontuação de risco e mitigações, tratando o DC como ativo de máxima criticidade.
Integração com SIEM corporativo
Os eventos e metadados gerados — incluindo os de proteção do AD — são encaminhados em tempo real ao SIEM corporativo via Syslog no formato CEF (Common Event Format). Configuração em Sysadmin > Integrações > SIEM (Syslog/CEF):
Servidor de destino (host/porta) e protocolo de transporte (UDP/TCP/TLS).
Formato: CEF padronizado, com campos de usuário, entidade, recurso, score, nível de risco, ação de mitigação e identificadores de sessão.
Filtro de severidade: escolha de quais níveis de risco são enviados.
Entrega em tempo real, garantindo correlação no SIEM no momento do evento.
O envio CEF permite que o SOC correlacione o risk score do DataDike PAM com outras fontes de telemetria corporativa, ampliando a detecção de ameaças além do perímetro do acesso privilegiado.
Boas práticas de implantação
Inicie com a janela de baseline padrão e mantenha as mitigações em modo observação durante a maturação.
Revise o Users rating diariamente nas primeiras semanas para calibrar a sensibilidade.
Habilite primeiro mitigações não disruptivas (alerta, reautenticação) e só então as disruptivas (encerramento, quarentena).
Cadastre os eventos críticos alinhados às políticas internas (comandos proibidos, ferramentas administrativas por hash) antes da virada para produção.
Confirme a entrega ao SIEM com eventos de teste antes de depender da integração para resposta a incidentes.
Atualizado
Isto foi útil?