What UEBA Actually Is

User and entity behaviour analytics is frequently described as detecting threats that rules cannot. That framing is close enough to be useful and wrong in the ways that matter operationally.

What UEBA does is narrower and more specific: it builds a statistical model of what is normal for an entity, compares current activity against that model, and produces a deviation score. Everything else — the risk timeline, the peer comparison, the alert — is presentation on top of that.

The mechanism

A UEBA system needs four things to work.

Entities. Something to model behaviour for. Usually users, but also hosts, service accounts, applications and network segments. The "E" in the acronym exists because modelling only users misses the majority of activity in a modern environment, where service accounts frequently outnumber humans.

Features. Measurable properties of behaviour: volume of data accessed, number of distinct systems touched, hour of day, geographic origin, authentication failures, file operations, command patterns. A feature is anything you can count or categorise per entity per time window.

A baseline. A statistical summary of those features over a training period. This might be as simple as a mean and standard deviation per feature, or as involved as a learned distribution over feature combinations.

A scoring function. Something that turns "how far is today from the baseline" into a number.

That is the whole architecture. Products differ in the sophistication of each part, and in the quality of the data engineering feeding it — which matters far more than the choice of algorithm, a point covered at length elsewhere on this site.

What it detects well

Compromised credentials. The strongest use case by a wide margin. An attacker using stolen credentials behaves differently from the legitimate owner: different hours, different systems, different volumes, different source addresses. The account is authorised; the behaviour is not the account's usual behaviour. This is precisely what deviation scoring is for, and it is a category rule-based correlation handles poorly because no individual event is suspicious.

Gradual privilege accumulation. An account whose access footprint broadens slowly over weeks. No single day looks unusual; the trend does. This is visible to a model tracking a rolling baseline and invisible to a rule evaluating single events.

Service account misuse. Machine accounts have exceptionally stable behaviour — the same operations, the same hosts, the same schedule. That stability makes deviation detection unusually reliable. A service account that suddenly authenticates interactively, or reaches a system it has never touched, is a high-precision signal.

Volume anomalies. Blunt and effective. Someone downloading far more than they ever have.

What it detects poorly

Intent. A score measures unusual, not wrong. Unusual has many innocent explanations: a new project, covering for an absent colleague, a deadline, a role change, a reorganisation. Any product presenting a score as an indication of malice is overstating what the mathematics supports.

Low-and-slow activity within normal parameters. Someone taking a small amount regularly, inside their established patterns, is invisible to a system looking for deviation. This is also how a knowledgeable insider would behave, which limits the value exactly where it is most wanted.

Anything by an entity with no stable baseline. New joiners, contractors, people whose work is genuinely varied. The model has nothing to compare against and either stays silent or flags constantly.

Novel behaviour that is legitimate. A company adopting a new tool produces organisation-wide deviation. The model reports it faithfully; it is not a threat.

How it differs from correlation rules

A correlation rule encodes a known pattern: if this event, then that event, within this window, alert. It requires someone to have anticipated the pattern.

UEBA requires no such anticipation. It asks a different question — is this unusual for this entity — and can therefore surface activity nobody wrote a rule for.

The trade is precision. A rule that fires has matched a specific, described condition, and the analyst knows what it means. A score of 87 means the model found the activity unusual, and the analyst has to work out why before deciding anything.

Neither replaces the other. Rules catch known patterns cheaply and precisely. UEBA surfaces the unanticipated at lower precision. Deployments that treat UEBA as a rule replacement end up with worse detection of known threats and an unreviewable queue of anomalies.

Where the value actually comes from

Two things, in practice, and neither is the algorithm.

Data quality. A mediocre model on well-normalised data with correct entity resolution outperforms a sophisticated one on inconsistent logs. Most disappointing deployments are data engineering failures wearing an analytics label.

Context at the point of review. A deviation score alone is uninterpretable. The same score with the entity's role, their baseline, what changed, and whether anything similar has been seen before takes thirty seconds to triage instead of twenty minutes.

What a realistic deployment looks like

It is worth setting expectations against what actually happens, because the gap between the demonstration and the second year is where most disappointment lives.

Months one to three. Data engineering. Entity resolution, normalisation, coverage verification. No detection value, and skipping this is the most common way deployments fail.

Months three to six. Baselines forming. Output is dominated by first-observed events and organisational change. Running silent through this period is correct; treating the output as detection is not.

Months six to twelve. Tuning. Approved workflows excluded, features corrected, thresholds set from review capacity. The queue becomes reviewable. First genuine findings usually appear here, and they are usually compromised credentials or a service account doing something unexpected.

Year two onward. Maintenance and incremental detection engineering. Sources break and get fixed, baselines reset on role changes, detectors are retired and added.

A programme that expects findings in month two will conclude the technology does not work. A programme that budgets a year to reach a reviewable queue generally gets there.

Common false positives

The recurring categories, worth recognising before they consume a quarter:

New tool rollouts. Everyone starts doing something new simultaneously.

Month-end and quarter-end. Finance and reporting roles spike predictably.

Role changes and internal transfers. The old baseline describes a job the person no longer has.

Incident response. Responders legitimately do everything the model finds alarming.

Support and administrative work. Broad access is the job.

Returning from leave. A gap in history followed by a burst of catching up.

Every one of these is addressable with context that is already available somewhere in the organisation.

Blind spots and assumptions

The mechanism carries assumptions that are easy to forget once a product is deployed:

That the training period contained only normal behaviour. If an attacker was present during baselining, their activity is now normal.

That the entity is one person. Shared accounts break the model completely.

That behaviour is stable enough to model. For many roles it is not.

That the peer group is meaningful. In small teams it is not.

Each of these is addressed elsewhere on this site. None is a reason to avoid UEBA, and all of them are reasons to be precise about what a score means before acting on one.