> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-guide/configuracoes/pam/audit/analise-comportamental-ueba.md).

# Análise Comportamental (UEBA)

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)**.

{% hint style="info" %}
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.
{% endhint %}

## Visão geral do funcionamento

O ciclo de análise é contínuo e composto por quatro estágios encadeados:

1. **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).
2. **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.
3. **Pontuação de risco** — cada evento e cada entidade recebem um *risk score* normalizado de **0 a 100**, recalculado em tempo real.
4. **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.

{% hint style="success" %}
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**.
{% endhint %}

### Período de aprendizado e baseline

Em **Audit > UEBA > Baseline**, define-se a janela de aprendizado:

| Campo                    | Descrição                                                                           | Padrão   |
| ------------------------ | ----------------------------------------------------------------------------------- | -------- |
| **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.

{% hint style="info" %}
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.
{% endhint %}

## 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

| Faixa de score | Nível de risco | Resposta automática sugerida                         |
| -------------- | -------------- | ---------------------------------------------------- |
| 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).

{% hint style="warning" %}
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.
{% endhint %}

## 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**):

1. Evento crítico coloca a sessão em quarentena automaticamente.
2. A sessão aparece na fila com score, fatores de risco e gravação associada.
3. O administrador revisa as evidências.
4. **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.

| Critério                   | Aplica-se a                 | Identificaçã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    |

{% hint style="info" %}
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.
{% endhint %}

## 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.

{% hint style="success" %}
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.
{% endhint %}

## 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.datadike.com/product-guide/configuracoes/pam/audit/analise-comportamental-ueba.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.