What a Baseline Actually Models

A baseline is a statistical summary of an entity's behaviour over some past window. Everything downstream — the scores, the alerts, the risk timeline — is a comparison against it. Yet the training period is typically configured once at deployment, never inspected, and never revisited.

What is actually stored

For each entity and each feature, a baseline holds some summary of the distribution. Implementations vary:

Simple statistics. Mean and standard deviation per feature. Cheap, interpretable, and wrong for anything that is not roughly normally distributed — which is most security telemetry.

Quantiles. The 50th, 90th and 99th percentile of a feature. More robust to skew, which matters because behavioural data is heavily skewed: most days are quiet, a few are enormous.

Categorical sets. The set of hosts this user has logged into, the set of countries they have connected from, the set of applications touched. Deviation here is set membership rather than magnitude, and it is frequently the most useful form.

Frequency distributions. How often each value occurs, which supports asking "how rare is this" rather than "how far from average is this".

Learned representations. Embeddings or density estimates over feature combinations. More expressive and considerably harder to explain to an analyst, which matters when a finding has to be defended.

Most products use several in combination. The important question during evaluation is not which, but whether you can see what the baseline contains for a given entity — because when a score is disputed, that is the first thing you will need.

The training window

Too short and normal variation is not represented. A two-week window on a monthly reporting cycle will treat month-end as an anomaly every month.

Too long and genuine change is absorbed. A twelve-month window means someone who changed role six months ago is still being compared against their old job.

Common practice is thirty to ninety days with a rolling update. Ninety days captures most weekly and monthly cycles without carrying stale behaviour indefinitely.

The quarterly problem. Behaviour with a quarterly cycle — financial close, audit periods, contract renewals — is not represented in a ninety-day window with any reliability. Either extend for the entities affected, or accept that those periods will produce noise and suppress them explicitly.

The assumption nobody states

A baseline assumes the training period was clean.

If an attacker was present during baselining, their activity is now part of normal. The model has learned that this account reaches those systems at that hour, and it will never flag the behaviour again.

This is not hypothetical. Dwell times in real intrusions are frequently measured in months, and a UEBA deployment that begins after an intrusion started will silently normalise it.

Practical mitigations:

Run a threat hunt before or alongside baselining, so the training period has been examined by someone.

Compare each entity's baseline against its peer group. An entity whose "normal" is substantially different from every comparable entity is worth a look, and this comparison costs nothing.

Retain the ability to rebaseline from a chosen window, so that if compromise is later established you can exclude the affected period rather than living with a poisoned model.

Treat the first months of output as investigative rather than operational.

Rolling, static and hybrid

Static baselines are computed once and held. Predictable, and they decay as the environment changes.

Rolling baselines update continuously. They adapt to legitimate change and they adapt to attacker behaviour too — a slow, patient adversary can move the baseline underneath the detection. Rolling windows with short memory are particularly vulnerable to this.

Hybrid approaches keep a long-term reference alongside a short-term one and compare the two. Divergence between them is itself a signal, and it is one of the few defences against baseline poisoning that does not depend on catching the initial intrusion.

When to rebaseline

Deliberately, on these events:

Role change. The person's job is different; the old baseline is not just stale, it is misleading.

Reorganisation. Peer groups change, and peer comparison silently breaks.

Major system migration. New tools mean new behaviour organisation-wide.

Return from extended leave. A three-month absence leaves a gap that some implementations handle badly.

Confirmed compromise. Obviously, and the ability to do it selectively should be tested before it is needed.

Inspecting a baseline

The single most useful exercise available during deployment, and one almost nobody runs.

Pick twenty entities across different roles. For each, look at what the model holds as normal: the feature values, the ranges, the sets of hosts and applications.

Ask whether it matches the job. A finance analyst whose baseline shows no access to the finance system indicates a coverage gap. A developer whose baseline includes hundreds of hosts suggests either a shared account or a resolution failure.

Check the variance. A baseline with an enormous range for every feature will never flag anything. A baseline with almost no variance either belongs to a service account or has been built on too little data.

Compare against peers. An entity whose baseline is unlike every comparable entity is worth understanding before it generates alerts for a year.

Twenty entities take an afternoon and routinely surface data problems that would otherwise be discovered through months of unexplained output.

Common false positives

Baseline-related noise has recognisable causes:

Baseline built during an atypical period — a project, a migration, a quiet holiday month. Everything afterwards deviates.

Insufficient training data. Entities with sparse history produce baselines that flag ordinary variation.

Bimodal behaviour averaged into one baseline that fits neither mode.

Absorbed cycles. A monthly pattern averaged into the baseline widens it enough to hide genuine deviation for the rest of the month.

Stale baselines after a role change nobody signalled to the system.

Blind spots and assumptions

That behaviour is stationary. Statistical baselines assume the underlying distribution is stable. For many roles it is not, and the model degrades continuously rather than failing visibly.

That every entity has enough history. New entities have none. Cold start has its own entry on this site.

That the entity is one thing. Shared accounts and repurposed service accounts produce baselines that fit nothing.

That the analyst can see it. If a product cannot show you what an entity's baseline contains, you cannot explain a finding, and you cannot defend it in a disciplinary or legal process.