Every anomaly detector in your stack has a threshold. Something happened, a number got computed, and that number got compared against a line. Above the line you got an alert. Below it, nothing.
Three things about that line are worth thinking about, and most products get all three wrong at once.
You didn't choose it. Somebody at a vendor picked a default that had to work for a bank, a marketing agency and a hospital at the same time.
You can't see it. It isn't on the screen. Often it isn't in the documentation either.
Everything underneath it got discarded. Not hidden. Not archived. Never written down.
The first two are annoying. The third is the one that costs you an incident.
Two failures that look identical from the outside
A detector tuned too low fires constantly. Within a month the team has learned to skim it, and within a quarter they've learned to close it. This failure is loud and everybody recognises it. It has a name, alert fatigue, and a whole industry of products claiming to solve it.
A detector tuned too high is silent. Nothing fires. The screen is empty.
Now look at the two screens you actually have in front of you. The detector that's quiet because your tenant is calm, and the detector that's quiet because its threshold sits above anything your tenant could ever produce, render exactly the same. An empty list, in both cases.
You can't tell them apart by looking. You can't tell them apart by waiting. The only thing that distinguishes them is an incident the second one should have caught, and by then the question isn't academic.
This is the real reason so many security teams distrust anomaly detection. Not that it's inaccurate. That it's unfalsifiable.
Why nobody tunes it, even when they can
Some products do expose the threshold. Almost nobody moves it, and the reason is rational rather than lazy.
In a conventional system a threshold applies going forward. Change it today and you find out what that change meant over the following weeks. Lower it and you might have just signed your team up for a thousand alerts a day, which you'll discover on Monday. Raise it and you might have just silenced the one detection that would have mattered, which you'll discover never.
So tuning is a bet on a quarter of your future, placed with no information. The standard mitigation is shadow mode: run the new setting alongside the old one, collect for a few weeks, compare. That works, it costs a quarter, and it has to be repeated every time the tenant changes shape.
Faced with that, the sensible move is to leave the dial alone. Which means the vendor's default, chosen for a hypothetical average customer, quietly becomes your security posture.
The part that is actually irreversible
Thresholds can, in principle, be changed. Data that was never written can't be recovered.
This is the asymmetry that matters and it almost never gets discussed. When a detector decides an event sits below the line, most systems don't store it. There's no record that the deviation was considered and rejected. The evidence isn't sitting somewhere waiting to be re-examined at a better setting. It doesn't exist.
Consider what that costs you during a real investigation.
You have an incident. It's Thursday. You believe something started the previous week. You go back to your detection tooling and ask the obvious question: what did you see around that time?
If everything below the alert line got discarded, the answer is "nothing." And "nothing" here doesn't mean nothing happened. It means nothing cleared a bar somebody else set eighteen months ago. Those two sentences look the same in a report and mean opposite things.
The weak signals around an incident are the cheapest forensic evidence you'll ever own. They cost nothing to keep. They're also, in most tools, the first thing thrown away.
Splitting one decision into two
The way out is to notice that a single hidden decision is doing two different jobs, then separate them.
What is unusual is a measurement. It should get computed and recorded whenever it's meaningful, whether or not anyone wants an alert about it.
What deserves an alert is a policy choice. It's yours, it depends on your industry and your team's capacity, and it should be visible and movable.
Once those two are separate, the interesting property falls out on its own. If everything meaningful was recorded with its score attached, then changing the alert line re-classifies history rather than only changing the future.
Lowering the line doesn't start collecting differently. It re-labels what was already caught. Raising it back doesn't delete anything. Moving the dial becomes an act of reading rather than an act of betting, and the quarter-long tuning cycle disappears, because there's nothing to wait for.
What has to be true underneath
This only works if the measurement itself is trustworthy. Four decisions carry most of the weight and they're worth checking in any product that claims to do this.
Compare against a median, not an average. One freak day in the past should never poison what normal means. A median over a trailing window is robust to exactly that.
Exclude today from its own baseline. If the current spike is included in the history it's judged against, it quietly raises the bar it has to clear. Sustained incidents go invisible in detectors that get this wrong.
Measure spread the same robust way. "How far above normal" has to be expressed in the metric's own day-to-day variability rather than in units someone picked. Median absolute deviation does this without getting dragged around by outliers.
Say nothing until the history means something. A median computed over four days is theatre. Staying silent for the first couple of weeks of any new baseline, and collecting instead, is more honest than inventing alerts out of a week of data.
There's one more, and it's a deliberate asymmetry. Flag spikes, not drops. Activity falls for benign reasons constantly: quiet days, holidays, cleanups, findings that got resolved. A queue containing every dip buries the spike that mattered underneath a hundred Fridays.
What this looks like in practice
Suppose deviations get recorded from two standard deviations upward, each carrying a comparable score, with the alert line sitting somewhere above that by default.
- A regulated organisation, so a bank, a hospital, a law firm, drags the line down. Everything the detector ever considered noteworthy becomes alerted, retroactively, and the audit question "would we have seen it?" gets answered by looking rather than by hoping.
- A thirty-person startup pushes the line the other way. The queue shrinks to the handful of episodes worth a human's attention, and nothing gets deleted. Everything below the line is still there on the day it becomes relevant.
- Both are the same product, the same data and the same detector. The difference is where one dial sits.
And the investigative move this enables is the one that pays for the whole design. We think we missed something last week. Lower the line, filter to that week, and read what was already recorded below your old threshold. Raise it back afterwards. Moving the dial destroys nothing, in either direction.
Episodes, not events
One last design point, because it decides whether the queue is readable.
A spike that lasts three days is one thing that happened, not three. If your detector emits an alert per day, a sustained incident arrives as a drip of near-identical notifications and gets muted like everything else that drips.
Treating an anomaly as an episode fixes this. It opens when the metric breaks the line, tracks its peak while the spike continues, and records when the metric returned to normal. One notification for the episode, not one per day.
Ending has to be a fact about the metric rather than a verdict about the incident. An episode whose spike stopped overnight should still sit in the open queue until a human acknowledged or dismissed it. Otherwise the most common outcome of a one-day spike is that it quietly closes itself before anyone reads it.
How 1Security does it
Every active policy in a tenant learns its own baseline: today's count against the median of the previous thirty days, today excluded, with spread measured by median absolute deviation. Detection stays silent for the first fourteen days of any new history. Only spikes get flagged.
The same machinery runs at two levels: policy-wide, and per-entity for a specific user, application or AI agent measured against its own history.
Everything meaningful gets recorded down to two sigma. At or above your alert line an anomaly is alerted and notifies the policy's recipients. Between two sigma and the line it's kept as info, stored silently and one toggle away. Below two sigma it's ordinary variation and nothing is stored.
The alert sensitivity control sits in the open at the top of the Anomalies screen rather than buried in settings, because it's the setting most tools never let you touch. Move it and classification re-runs at read time against your real history. Release the slider and the alerted and info counts re-answer on the spot, with the queues repopulated to match.
Anomalies are episodes with a lifecycle and a triage state of open, acknowledged or dismissed. Each row leads with the detector that fired, the affected entity underneath, a thirty-day sparkline, the spike itself, the score, and when it ended.
Frequently asked questions
Does keeping sub-threshold data create noise? Only if it gets shown by default. It should live behind its own tier, silent and unnotified, until you go looking for it. The point is that it exists when you need it, not that it demands attention.
Isn't two sigma too low a floor? As an alerting floor, far too low. As a recording floor it's about right. Low enough that genuine early signals get captured, high enough that ordinary variation doesn't get stored forever.
Why only spikes? Drops can be malicious too. They can. A silenced log source is a real attack pattern. But that's better detected as an explicit absence check on a specific signal than by treating every decline in every metric as an anomaly. Mixing them makes the queue unreadable, and an unreadable queue catches nothing.
How is this different from UEBA? Mostly in what it admits. The mechanics are conventional statistics, deliberately simple enough to state in one sentence. What changes is that the threshold is visible, movable and retroactive, and that nothing meaningful gets discarded on the way in.
