Behaviour baselines for your users

Some detections cannot be written as a fixed rule because the interesting thing is unusual for this person, not unusual. A sign-in at three in the morning is routine for one colleague and worth a look for another. So the platform builds a small behavioural baseline per user and makes the comparison available to every detection rule as four ordinary fields.

The console calls this User behavior analytics and describes it in one sentence: Per-user baselines of normal hours, geographies, and daily volume feed the rule engine. That is the whole scope, and being clear about how small it is matters more than making it sound larger.

What is measured, and for whom

Users only. The baseline is keyed on your organisation and a user identifier. There is no baseline for a host, an address or a service — the industry term for this is user and entity behaviour analytics, and the entity half is not built. Three things are measured per user.

Normal hours

A histogram of twenty-four UTC hour slots. An hour in which the user has never been seen acting over the window is an off-hours slot for them.

Dominant country

The most frequent non-empty country recorded on their events over the window, with a deterministic tie-break so the value does not flap between two equally common countries.

Daily volume

The mean and the sample standard deviation of their event count per day, plus how many days they were active and how many events in total.

The window is fourteen days by default, and the reasoning is recorded: long enough that a fortnight's working pattern is represented including both weekends, short enough that a role change stops looking anomalous within a sprint. An operator can set it anywhere from 2 to 90 days. Baselines are recomputed every six hours by default.

Baselines that stop being refreshed are deleted after three times the window — forty-two days on the defaults. That is a data-minimisation obligation and it is also operationally correct: without it, a departed employee's old mean would go on deciding whether activity under their name is normal.

The four fields it stamps on an event

Verdicts are written into event metadata as strings, so any detection rule can read them the way it reads any other field. All four are declared available in the field contract, so a rule using them is not a shadow rule.

metadata.ueba_off_hours        "true" when the event hour is one the user
                               has never been active in
metadata.ueba_unusual_geo      "true" when the event country differs from
                               the user's dominant country (both non-empty)
metadata.ueba_volume_spike     "true" when today's running count is more
                               than three standard deviations above their mean
metadata.ueba_deviation_sigma  the sigma figure itself, to two decimals

A shipped rule already uses the first of these — one of the brute-force detections requires metadata.ueba_off_hours to be true — so this is not a facility waiting for somebody to adopt it.

Note the deliberate absence: there is no single composite anomaly score. Three independent booleans and one sigma figure is more legible than a number between 0 and 100 whose derivation nobody can reconstruct, and it means a rule can require off hours specifically rather than anomalous somehow.

How long before it is useful

Three separate gates, and the answer is different for the three verdicts.

1. 1

   Ten events for anything at all

   Below ten observed events for a user, the scorer returns an empty verdict — no anomaly, no reason, sigma zero. It does not guess from three events, and it does not report unknown as suspicious.

2. 2

   Off-hours and unusual-country verdicts work as soon as that gate passes

   These are computed in the running process from what it has already seen, and need no background job to have run.

3. 3

   Volume spikes need the job to have run, and two active days

   A standard deviation from one sample is not a standard deviation, so a user with a single active day in the window never produces a spike verdict — the platform forces the deviation to zero in that state whatever the stored row says.

The practical timing for a first volume baseline: the background job does not run at start-up — it waits one full interval, so at least six hours — and the detection pipeline then picks up the result within ten minutes. So expect roughly six hours plus two active days of history for the user in question. Off-hours and country verdicts are available much sooner.

Why the line is at three sigma, and what it costs

A volume spike is declared when today's count exceeds the mean by more than three sample standard deviations. Strictly greater, so exactly three does not fire.

Three sigma is a conventional and defensible line, and it is worth naming its two costs rather than presenting it as a solved problem. It is loose for a user with very steady behaviour: a small standard deviation makes a modest increase cross the line. It is tight for a user whose volume swings wildly week to week: a large standard deviation can absorb a genuinely large jump without comment. There is no per-user tuning of this figure today.

One implementation detail with a real consequence: today's running count includes the event being scored, and it is deliberately not folded into the baseline it is being tested against. The order is score first, then observe. The code says why: observing first would let a single event become its own normal, which is how an off-hours baseline silently self-defeats.

What this does not do

• It does not raise alerts on its own. It stamps fields. An alert happens only if a detection rule reads one of those fields and its own threshold is met. If you want off-hours activity to alert, that is a rule, not a setting here.
• It has no entity baselines. No host, no address, no service account as an entity in its own right. A service account with a user_id is baselined as a user, which is often exactly right and is worth knowing when you read a verdict about one.
• It does not baseline what a user does, only when, where and how much. A person accessing a system they have never touched before is not something these three metrics can see.
• Country comes from the event. If your log source does not populate a country, the unusual-country verdict can never fire for events from that source. See How your logs are normalised for which sources carry what.

One more absence, stated because a reasonable person would assume otherwise: a baseline is not evidence you can show an auditor. There is no export, no history of how a baseline changed, and no record attached to an alert saying what the baseline was at the time. What an alert carries is the four stamped fields, which is the verdict rather than the reasoning behind it.

One thing that was wrong, and is now right

Worth recording because it affects how you should read old data. An observation arriving with an empty organisation or an empty user identifier is now dropped rather than filed under a shared key. Before that fix, two different organisations' admin accounts shared one baseline — a genuine cross-tenant leak, in which one customer's activity pattern decided what looked normal for another's.

The consequence for you is small and real: verdicts computed before that fix, for generically-named accounts, were drawn from a baseline that was not purely yours. Baselines refresh every six hours and expire after forty-two days, so nothing from that period survives today. It is written down here because an unexplained anomaly verdict from that window has an explanation.

What to read next

1. How your logs are normalised — the full metadata vocabulary these four fields join, and which sources populate a country.
2. The detection library — how a rule reads a metadata field, and which shipped rules already do.
3. Tuning a detection rule — changing a threshold on a rule that uses one of these verdicts.