UEBA: Risk Scoring Users and Entities Instead of Alerting on Events

Traditional detection asks whether an event matches a known-bad pattern. Behaviour analytics asks whether an event is unusual for this particular user or system, and accumulates that judgement into a risk score. It catches things no signature describes — an insider using legitimate access improperly, or an attacker operating entirely with valid credentials.

A single signal from this family is covered under impossible travel; this is the wider model it belongs to.

Baselines, per entity

The foundation, and where most of the work is. The system observes normal behaviour over weeks and builds a profile: when this person works, from where, on which devices, which applications and systems they touch, how much data they typically move, and which of their peers behave similarly.

Entities other than users get the same treatment — servers, service accounts, and endpoints all have characteristic behaviour, and a service account is in some ways the better subject, because its behaviour is machine-driven and therefore far more regular than a person's.

Two baselining errors recur. Too short a learning window captures an atypical period. And baselining against the whole population rather than against a peer group produces a "normal" that fits nobody, since a developer and a receptionist have nothing in common.

The signals that carry weight

Authentication anomalies — a new location, a new device, an unusual hour, a sudden change in the volume of failures, or the geographic impossibility of two sessions.

Access anomalies — reaching systems or data this account has never touched, or that nobody in its peer group touches. Peer comparison is the strong version: one accountant querying an engineering repository is more interesting than an absolute rule could express.

Volume anomalies — downloading far more than usual, or reading a large number of records where the role implies handling a few at a time. This is the classic insider exfiltration signature.

Privilege anomalies — using administrative rights that are held but rarely exercised, or a sudden broadening of what an account does.

Timing and sequence — activity outside established hours, or actions in an order that does not match how the work is actually done.

Scoring instead of alerting

The design choice that makes it usable. Each anomaly contributes to a score rather than firing an alert, because any one of them alone is usually innocent — people travel, buy laptops and work late.

Several together are a different matter. A login from a new country, on a new device, outside working hours, followed by access to a system the account has never used and a large download, is a sequence with a plausible innocent explanation and a much more plausible malicious one. The score crosses a threshold and an analyst looks.

This also produces the behaviour worth knowing for the exam: risk-based conditional access, where a rising score triggers additional authentication or blocks the session automatically rather than waiting for a human — with the constraints on automated action described under automation guardrails.

Where it fails

Be honest about these, because they are the difference between a useful deployment and shelfware.

Change breaks baselines. A reorganisation, a new application rollout, or a shift to remote working invalidates months of learning at once and produces a flood of anomalies. The system needs time to relearn, and during that period it is noise.

Slow attackers blend in. An attacker who operates gradually and within the account's normal patterns is establishing a new baseline rather than deviating from one. Behaviour analytics is better at sudden change than at patient change.

Shared and service accounts used by several people or several processes have no coherent baseline, and they are frequently the accounts that matter most — which is another argument for the individual, managed identities described under service account security.

Explainability. An analyst handed a score of 87 with no reasoning cannot act on it. A system that shows which signals contributed is usable; one that does not gets ignored, and that is a procurement criterion rather than a technical detail.

Privacy and proportionality. This is employee monitoring, with notification requirements in many jurisdictions, consultation obligations in some, and a genuine cultural cost if it is deployed without transparency.

Making it work

Feed it identity, endpoint, network and application data, since the value is in correlation across sources rather than in any one. Keep the asset and identity context current, because a score computed against a stale picture of who owns what is confidently wrong.

Tune with feedback: every investigated anomaly closed as benign should improve the model, and a system whose dispositions go nowhere never gets better. And integrate the output into the same queue as everything else rather than a separate console, which is the same argument made throughout for consolidating into the SIEM.

Exam angles

Know UEBA as establishing per-entity behavioural baselines and scoring deviations rather than matching signatures, applied to users, service accounts and devices. Name authentication, access, volume, privilege and timing anomalies as the signal categories, and peer group comparison as stronger than absolute thresholds. Recognize accumulation into a risk score as what avoids alerting on individually innocent events, and organisational change, gradual attacker behaviour and shared accounts as the known weaknesses.