Rare Is Not Anomalous

Anomaly detection finds things that occur infrequently. Security wants things that are wrong. These overlap far less than the marketing implies, and the gap is where the alert queue drowns.

Why rarity dominates

Human behaviour has a long tail. On any given day, a large fraction of people do something they have not done before: use a new application, connect from a new location, access a system for the first time because a colleague asked.

In an organisation of five thousand people, "first time" events number in the thousands daily. Every one is rare. Almost none is interesting.

A model scoring rarity will surface these faithfully, in volume, forever.

The distinctions worth encoding

Rare for the entity, common for the peer group. Someone accesses the expense system for the first time. Rare for them, and everyone in their department does it monthly. Peer comparison resolves this and it is the single highest-value correction available.

Rare in absolute terms, expected in context. First login after returning from leave. First access after a role change. First use of a newly deployed tool. Each is rare and each has a known cause available in reference data.

Rare and consequential versus rare and trivial. A first-time access to the customer database and a first-time access to the cafeteria menu score identically on rarity. Weighting by the sensitivity of what was touched separates them, and this requires the data inventory that most deployments skip.

Rare individually, unremarkable together. Someone using a new tool generates first-time events for the tool, its authentication method, its network destination and its file paths. That is one fact producing five anomalies unless correlated.

What actually distinguishes interesting

Rarity is a weak signal. What raises it:

Rare plus sensitivity. The resource touched matters.

Rare plus deviation from peers. Nobody comparable does this.

Rare plus concealment. Activity outside hours with no corresponding business reason, deletion of logs, use of encryption where none is normal.

Rare plus sequence. Several rare things in a coherent order — enumeration, then access, then transfer.

Rare plus employment context. The same first-time access is different during a notice period.

Rare plus persistence. Once is noise. The same rare thing daily for a week is a change in behaviour.

Any one of these alone produces noise. Two or three together produce something worth an analyst's time, and this is the practical argument for combining signals rather than alerting on individual detectors.

The first-time problem specifically

"First observed" detectors are popular because they are trivial to implement and they generate enormous volume.

They fire hardest at deployment, when everything is first-observed. The first weeks of any deployment are dominated by this and it is frequently mistaken for a detection problem.

They fire on every change the organisation makes.

They never fire on an established attacker whose behaviour was learned during baselining.

Making them useful: require a warm-up period before the detector is live, scope them to sensitive resources rather than everything, and combine them with at least one other condition.

Frequency, not binary

A better formulation than "has this happened before" is "how often does this happen, for this entity and for comparable entities".

That produces a graded measure rather than a binary one, degrades gracefully for entities with short histories, and supports the natural question an analyst asks: is this the sort of thing that happens around here?

Building a rarity feature properly

The difference between a rarity detector that works and one that floods the queue is a few design decisions.

Use frequency, not a binary. "Seen twice in ninety days" is more useful than "not seen before", and it degrades gracefully for entities with short histories.

Compute rarity at two levels. For the entity and for the peer group. The interesting case is rare at both; rare for the entity and common for peers is ordinary.

Require a warm-up. No rarity alerting until the entity has a meaningful history, or every new joiner generates dozens of alerts in their first week.

Weight by consequence. Rarity against a sensitive system and rarity against a canteen menu should not produce the same score.

Correlate within a session. One new tool produces many first-observed events; they should surface as one item.

Decay old observations. Something seen once a year ago is effectively unseen, and treating it as familiar hides genuine change.

Common false positives

The recurring benign causes of rare events, which together account for most of the volume:

New tool adoption, organisation-wide or individual.

Project work that legitimately requires systems the person never touches otherwise.

Covering for a colleague during leave.

Onboarding, where everything is new by definition.

Annual processes — audit, budgeting, compliance attestation — that recur outside the baseline window and therefore look novel every year.

Vendor and consultant activity on accounts with no established pattern.

Blind spots and assumptions

That rarity is stable. As the environment changes, what is rare changes. Detectors calibrated at deployment drift.

That common means safe. An attacker deliberately operating within normal parameters produces nothing rare. Rarity-based detection is blind to patience by construction.

That the analyst can tell the difference. Under queue pressure, everything rare looks equally like a candidate. The separation has to be in the pipeline, not in the reviewer's judgement.

That suppressing rarity loses detection. Suppressing unqualified rarity loses noise. The detections that mattered were rare and something else, and they survive the filter.