Anomaly detection is impossible without a definition of normal, and most environments never write one down. A baseline is that written definition: the set of behaviors, configurations, and rhythms a system shows when nothing is wrong. Without it, every unusual login, new process, or open port looks equally alarming, because there is no reference to measure against. With it, the same events sort themselves into three piles — expected, drifted, and genuinely anomalous — and only the last pile earns urgency.
The catch is that “normal” is not a single number but a shape. A file server that is quiet at 3 a.m. on weekdays may be legitimately busy at 3 a.m. on the night the backups run. An account that never touches the finance folder may do so once a quarter at close. A useful baseline captures these rhythms and their exceptions, so that when a defender sees activity outside the shape, they can ask a precise question instead of guessing.
Why “normal” has to be written down
An undocumented baseline lives only in the heads of whoever happens to be on call, and it evaporates when they leave, forget, or disagree. Writing it down turns tribal memory into something a newcomer can check and a tool can enforce. It also forces a useful admission: that some “normal” is not actually known — that no one is sure whether a particular service account is supposed to reach the internet, or whether a scheduled task belongs. Those unknowns are not gaps to paper over; they are the most valuable entries in the baseline, because they mark exactly where an intruder could hide in plain sight. A configuration baseline built from published benchmarks gives you a defensible starting definition of a known-good system state, and pairing it with the ownership discipline in Asset Inventory Drift keeps that definition tied to real assets rather than wishful memory.
Drift versus anomaly
Not everything that departs from the baseline is an attack. Drift is the slow, mostly benign accumulation of change — a new SaaS app here, a widened firewall rule there, a permission granted for a project and never revoked. An anomaly is a sharper, often faster deviation that fits no authorized change. The two call for different responses: drift is managed through review and cleanup, while an anomaly is investigated. Confusing them is costly in both directions. Treating ordinary drift as an incident burns out responders and dulls their attention; treating a real anomaly as “just more drift” is exactly how slow intrusions stay invisible. The distinction is one of context, not of the raw signal, which is why a baseline that records who approved a change and when is worth far more than one that only records the current state.
Toy example
Return to the fictional Marigold Studio. Its baseline notes that the shared-drive service account, marigold-sync, signs in only from one automation host, moves files during business hours, and never authenticates interactively. One week a defender notices marigold-sync authenticating interactively at 21:40 from a laptop. Against a blank slate this might be shrugged off; against the written baseline it is immediately a precise question, because interactive login falls outside this account’s defined behavior. The investigation that follows is narrow — did someone repurpose the account for a manual fix, was that change approved, and is the automation host still the only other place the account appears. All names, hosts, and times are invented, and nothing real is probed. The exercise is the comparison against a written normal, not the target.
What evidence matters?
A baseline is only as good as the evidence it is built from and compared against. Four kinds matter: the original signal being judged, the documented normal it is measured against, the state of the relevant control, and the record of who decided a deviation was acceptable or not. The strongest baselines are built from durable, timestamped sources — authentication logs, configuration exports, inventory records — rather than from memory or a single screenshot. Coverage matters too: a baseline that only sees one system cannot tell you whether an anomaly is isolated or environment-wide. When comparing a signal to the baseline, corroboration raises confidence, and a lone deviation is a lead rather than a conclusion. The evidence discipline here is the same one used in Evidence-First Triage and Security Alerts Without Panic : write the smallest checkable claim, separate what is observed from what is assumed, and record confidence as a level rather than a certainty.
Building and maintaining a baseline
A baseline is a living document, not a one-time snapshot, because the environment it describes changes constantly. The practical rhythm is to establish a defensible starting point — configurations measured against a published benchmark, expected accounts against an inventory, normal traffic against a period of quiet observation — and then to update it deliberately whenever an authorized change lands, so that legitimate drift is absorbed rather than mistaken for anomaly. The maintenance is what keeps the baseline trustworthy; a definition of normal that no one has revisited in a year has quietly become a definition of last year. Tying baseline updates to the same change records and approvals that govern the environment keeps the reference honest, and reviewing anomalies through the lens of Detection Tuning and Signal Noise keeps the alerts built on top of the baseline from drowning the real deviations in noise.
Common mistakes and false positives
The first mistake is building a baseline once and treating it as permanent, so that every legitimate change registers as an anomaly and the team learns to ignore the resulting noise. The second is baselining the wrong layer — capturing which processes run but not which parent spawned them, or which ports are open but not which hosts they talk to — so that the definition is too coarse to catch a meaningful deviation. A third is mistaking the absence of a baseline for the absence of a problem: “we’ve never seen this before” can mean either a novel threat or simply a gap in what was ever recorded.
False positives against a baseline are expected and useful. When a deviation turns out to be an approved but undocumented change, the fix is not to close the ticket and move on but to add the change to the baseline so the same event does not fire again. Every well-handled false positive should leave behind a slightly more complete definition of normal. Panic and dismissal remain the twin errors: panic treats all drift as intrusion, dismissal treats all anomaly as drift, and a maintained baseline is what lets a defender tell them apart with a written reason.
What to do next
Match the response to where the signal sits. A deviation the baseline can explain needs only a note. Unmanaged drift needs a review-and-cleanup pass, not an incident bridge. A genuine anomaly touching sensitive data, privileged access, or business continuity belongs in the formal response process. In every case, choose the smallest step that improves confidence without destroying evidence, and record who decided what and why.
If you are learning, build a toy baseline for an invented system — list its expected accounts, rhythms, and configurations, then invent a single deviation and practice sorting it into expected, drifted, or anomalous with a written reason. Keep every name, host, and dataset fictional. For a real environment in an active incident, do not experiment: preserve evidence, follow the plan, and involve qualified responders. When you are ready to turn a confirmed anomaly into a prioritized decision, Risk Scores, Severity, and Confidence is the next step.
How this guide was made
This page is defensive education built from public frameworks and published configuration guidance, illustrated with invented systems and toy data. It makes no claim to certification, legal advice, or incident-response authority, and it avoids exploit detail so it remains useful for safe learning. The official references below are orientation points, not a standard you are being measured against.
Official references
For anchoring a baseline program in recognized practice, the NIST Cybersecurity Framework 2.0 describes the identify-and-detect functions that give baselines their purpose, the CIS Critical Security Controls v8 supply configuration benchmarks that define known-good system states, and the MITRE ATT&CK Enterprise Matrix provides a technique catalog for judging whether a given drift resembles adversary behavior.
Related guidebooks
A baseline is most useful when paired with calm alert reading in Security Alerts Without Panic and honest prioritization in Risk Scores, Severity, and Confidence ; to keep the underlying inventory trustworthy, Asset Inventory Drift and Evidence-First Triage are the natural companions.
