Identity & user behaviour anomaly detection (UEBA)

Most breaches involve a valid account: stolen credentials, hijacked sessions, abused service accounts or a malicious insider. Signature rules cannot tell a legitimate login from a stolen one. UEBA builds statistical and ML baselines per user, device and peer group and raises alerts on deviations (new country, unusual data volume, first-time privileged action). Used well it shortens detection of account takeover; used carelessly it becomes workplace surveillance — in the EU the works-council and GDPR design matters as much as the model.

Problem & value

• Today: identity attacks are detected by static rules (impossible travel, failed-login thresholds) that generate many false positives and miss slow, "low-and-slow" misuse. Insider cases are usually found after the fact, by audit or a tip-off.
• AI value: per-entity and peer-group baselines, detection of first-seen and rare behaviour, sequence and graph analysis (lateral movement across accounts), risk scores that aggregate weak signals, and LLM-written explanations so Tier-1 analysts can decide quickly.
• Evidence: vendors publish detection counts, but independent, comparable false-positive figures are scarce; measure on your own data. The CMU CERT insider-threat dataset remains the common research benchmark, though it is synthetic [5].

Variants

• SMB: identity-protection features of the existing suite (Microsoft Entra ID Protection / Defender, Google Workspace, Okta) or a managed detection service; no separate UEBA product.
• Enterprise SOC: UEBA inside SIEM/XDR (Sentinel, Splunk, Elastic, Exabeam, Securonix) with peer-group modelling and watchlists (privileged users, leavers).
• Cloud / non-human identities: service accounts, API keys and AI agents — baseline their API call patterns (links to SEC-013, SEC-020).
• Public sector / regulated: pseudonymised analytics with a small, audited re-identification group and strict purpose limitation.
• Customer-facing account takeover: same techniques on customer logins → see ANOM-001, ANOM-014.

How it works

1. log sources (IdP, cloud audit, VPN, endpoint, SaaS)
2. normalisation & entity resolution (user, host, IP, app, service account)
3. feature building (hourly counts, geo/ASN, device, resources touched, time-of-day)
4. baselines (per entity, per peer group, seasonal) + models (isolation forest, autoencoder, sequence/graph models, Bayesian rarity scores)
5. risk aggregation over a sliding window (e.g. 7–30 days)
6. alert with explanation + context (role, leaver flag, recent changes)
7. analyst review
8. response (step-up MFA, session revoke, ticket)
9. feedback to the model

• Models: mostly classical unsupervised ML (isolation forest, clustering, PCA, time-series forecasts); deep sequence models and graph embeddings add lateral-movement detection. Labels are rare, so supervised models are used only where incident history exists.
• LLM layer: summarises a risk timeline, maps anomalies to MITRE ATT&CK techniques, and answers analyst questions ("what did this account do in the 24h before the alert?") — see SEC-001. LLMs do not decide; scores come from the statistical layer.
• Human-in-the-loop: analysts confirm; disabling an account or accessing an individual employee's detailed activity needs a documented approval (four-eyes, works-council agreement).

Data preparation

UEBA needs identity and activity logs: Entra ID/Active Directory sign-ins, VPN, proxy, cloud audit logs, SaaS and endpoint events, plus HR context (role, department, leavers). In an SMB these live in the identity provider, firewall appliances and mail/cloud admin portals; often retention is only 30 to 90 days and nobody has ever exported them.

Typical gaps: short log retention, inconsistent timestamps and user names across systems, shared and service accounts without owner, stale accounts of former employees, no peer-group definition, and missing HR feed for joiners, movers and leavers.

Preparation steps: 1. Inventory log sources and enable the audit logs you already pay for (see PREP-005, PREP-001). 2. Centralise logs with a common schema (Wazuh, OpenSearch, Sentinel) and extend retention to at least 6 to 12 months so baselines can form. 3. Clean the identity base: owners for service accounts, remove stale accounts, map user IDs across systems. 4. Define peer groups and pseudonymise user IDs for analysts where possible (PREP-022). 5. Clarify purpose and legal basis (PREP-025).

Expect roughly 50 to 60 percent of the total effort to go into log onboarding and identity hygiene, not into the model itself. A readiness check is described in GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A. Managed identity protection (e.g. Entra ID Protection, Okta ThreatInsight) or an MDR service delivers baselines without an own SOC; the process is standard.
• Enterprise: Path C. Behavioural profiles of employees are highly sensitive and the SIEM/data-lake platform is shared with other security use cases, so an own open-source or in-house stack keeps control.
• Developer: Path C. Open-source tooling (Wazuh, OpenSearch anomaly detection, scikit-learn) on HW1 lets you build and tune detections without vendor lock-in.
• Public: Path C. Staff-council and sovereignty requirements favour a self-operated or sovereign-cloud deployment with transparent logic.

Path A — Buy (recommended for most)

• Suite-integrated: Microsoft Sentinel UEBA and Entra ID Protection (baselines users, hosts, IPs and apps; tables such as BehaviorAnalytics, recent behaviours layer and anomalies on behaviours) [1][2]; Google Security Operations; CrowdStrike Falcon Identity Protection; Okta Identity Threat Protection.
• Dedicated UEBA / next-gen SIEM: Exabeam, Securonix, Splunk (UBA / Enterprise Security), Darktrace, Rapid7 InsightIDR, Varonis (data-centric), Stellar Cyber.
• EU vendors / EU-hosted: Sekoia.io (FR), Wazuh-based managed services, Hornetsecurity, ESET (SK) XDR; check EU data residency.
• Choose A when: you already run a Microsoft/Google/Okta suite or lack ML staff. Check: connector coverage, explainability per alert, peer-group config, pseudonymisation, retention and access controls for analytics data.

Path B — Build on cloud APIs

• Platform ML: Elastic machine-learning anomaly detection jobs on identity logs [3]; Sentinel custom anomalies; OpenSearch anomaly detection; Amazon GuardDuty (CloudTrail behavioural findings), Google SCC.
• LLM for investigation: an EU-region LLM (Mistral, Azure OpenAI EU, Claude via EU endpoints) to explain risk timelines — pass pseudonymised IDs only.
• Choose B when: a SIEM exists and you want custom detections for niche systems (ERP, PACS).

Path C — Self-host (open source)

• Stack: Wazuh or Security Onion for collection, OpenSearch/Elastic for storage and anomaly jobs, PyOD [4], scikit-learn, River (streaming), PyTorch Geometric for graphs; Sigma rules as a rule baseline; an open-weight LLM (Qwen, Llama, Mistral) via vLLM/Ollama for explanations.
• Hardware: HW1 (CPU) for statistical models and a few thousand entities; HW2 only if you host the explanation LLM. Main effort is data engineering and tuning, not compute.

Path D — Custom training

Worth it for large organisations with unusual systems or high-value insider-risk programmes: train sequence/graph models on 6–12 months of normalised logs, with red-team or purple-team injected scenarios as evaluation labels. Needs a data-science plus detection-engineering team and a labelled feedback loop from closed cases.

State of the art (2026)

• Behaviour layers on top of raw logs: SIEMs now summarise high-volume logs into readable "behaviours" and detect first-seen or unusually frequent behaviours, with generative AI used for the descriptions [1][2].
• Identity-first detection: UEBA is merged with ITDR (identity threat detection & response): token theft, MFA fatigue, OAuth consent abuse and service-principal abuse are now core cases.
• Agentic triage on top of UEBA alerts (SEC-001) reduces review time, but verdicts still rest on baselines.
• Limits: cold start (new users and role changes have no baseline), noisy peer groups, seasonal events (audits, month-end, holidays) causing false positives, concept drift after re-organisations, and adversaries who stay within normal behaviour. Anomalous is not malicious; expect to tune for weeks and to suppress by context (travel, projects).
• Explainability matters: alerts that cannot say why (which feature, which baseline) are hard to defend to staff representatives and in labour disputes.

Shared resources & combinations

• Same stack (anomaly-detection + time-series + streaming): SEC-006 network intrusion detection, SEC-015 OT monitoring, ANOM-005 industrial anomalies, ANOM-001 fraud scoring.
• Combines with: SEC-001 (triage of UEBA alerts), SEC-020 (access reviews fed by anomalous-privilege findings), SEC-008 (threat intelligence), SEC-011 (deepfake-based social engineering often precedes account takeover), SEC-017 (data-exfiltration context).
• Shared data pipeline: one normalised log lake (OCSF or ECS schema) serves all SEC.DETECT cases.

Effort, cost & KPIs

• Path A: weeks to enable; cost is licence plus log-ingestion volume (often the dominant item).
• Path B: 2–4 months for a tuned set of detections on top of an existing SIEM.
• Path C: 3–6 months incl. data engineering; low licence cost, higher staff cost.
• Path D: 6+ months, specialised team.
• KPIs: mean time to detect/contain account compromise, alert precision (share of true positives after triage), analyst minutes per alert, coverage of identity sources, purple-team detection rate, number of works-council complaints or data-subject requests (should be zero-trending).

People & change

UEBA evaluates the behaviour of individual employees, so involve people early, before the pilot, not after the contract.

• Works council: yes. The system is objectively suited to monitor behaviour and performance, so §87(1) no. 6 BetrVG co-determination applies (BAG); §90(1) no. 3 requires timely information. Aim for a works agreement that fixes purpose (security only), pseudonymised first-level analysis, retention, and a ban on performance evaluation. The works council may engage an AI expert (§80(3)). In public bodies the Personalrat has the same role.
• DPO and DPIA: a DPIA (Art. 35 GDPR) is very likely because of systematic evaluation of behaviour; conclude an AVV with every provider (Art. 28 GDPR).
• IT security, IT and HR define data sources, alert handling and the leaver process; management owns the decision and budget.
• AI literacy: support analysts and administrators with training on false positives and score interpretation (Art. 4 AI Act).
• Communication and pilot: announce purpose and limits openly, start with the IT/admin accounts as pilot group.
• Typical concern: "surveillance". Address it with transparency, a documented purpose limit and the rule that an alert is a hint, never an automatic sanction; humans decide on every consequence.

See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: typically minimal when used purely for cybersecurity of IT systems. It becomes high-risk (Annex III, employment — monitoring and evaluating performance/behaviour of workers) if scores feed HR decisions, discipline or performance assessment. Art. 5 prohibition: inferring emotions of employees from biometric or behavioural data in the workplace is banned — do not add mood or stress inference to UEBA [6]. Keep the system security-only and technically separate from HR analytics.
• GDPR: user logs are personal data; legal basis usually Art. 6(1)(f) legitimate interest (network and information security, Recital 49) with a documented balancing test; DPIA (Art. 35) is normally required for systematic employee monitoring; transparency (Art. 13/14), purpose limitation, data minimisation, role-based access to raw activity, short retention; Art. 22 applies if decisions with legal effect are fully automated [7].
• Employee co-determination: in Germany §87(1) no. 6 BetrVG gives works councils co-determination over technical systems that can monitor behaviour — a works agreement (Betriebsvereinbarung) is effectively a prerequisite; similar information and consultation duties exist elsewhere in the EU. Public bodies: staff-council equivalents.
• Sector rules: NIS2 (Art. 21 risk-management measures) and DORA for finance push towards detection capability, which supports the legitimate-interest case [8].
• Mitigations: pseudonymise identities in analytics, break-glass re-identification with logging, exclude special-category and private-use data, define watchlist criteria in writing, review models for bias across roles/locations, document in the records of processing.

Getting started

1. Inventory identity and cloud log sources; enable audit logging and ship it to one SIEM/lake.
2. Involve DPO and works council first; draft the works agreement, purpose, retention, access rules.
3. Turn on the built-in identity-protection/UEBA features of your current suite in monitor-only mode.
4. Run 4–6 weeks to build baselines; review the top-50 alerts weekly, record true/false labels.
5. Add context (leavers, privileged groups, travel calendar) and wire approved responses (step-up MFA, session revoke); test with a purple-team exercise.

Sources

1. Microsoft Learn — Advanced threat detection with UEBA in Microsoft Sentinel — https://learn.microsoft.com/en-us/azure/sentinel/identify-threats-with-entity-behavior-analytics
2. Microsoft Learn — Investigate anomalies on UEBA behaviors in Microsoft Sentinel — https://learn.microsoft.com/en-us/azure/sentinel/ueba-anomalies-on-behaviors
3. Elastic — Machine learning anomaly detection overview — https://www.elastic.co/guide/en/machine-learning/current/ml-ad-overview.html
4. PyOD — Python outlier detection toolkit — https://github.com/yzhao062/pyod
5. CMU CERT — Insider Threat Test Dataset — https://kilthub.cmu.edu/articles/dataset/Insider_Threat_Test_Dataset/12841247
6. Regulation (EU) 2024/1689 (AI Act), Art. 5 and Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj