Why does a threat-hunting baseline expire, and what should you record alongside one?
answer
- a snapshot of a moving estate
- authorised change, not attacks
- half-life differs by data source
- write down what would invalidate it
- name an owner who tells you
basics
~20 sA baseline is a snapshot of an estate that is under continuous authorised change, so it decays as the estate moves. Record the learning window, the population covered, the assumptions it rests on, and the events that would invalidate it.
solid answer
~50 sNormal is not a constant. Fleets grow, a management agent is rolled out, a patch window moves, clocks shift, a migration lands, a SaaS provider rotates its addresses — none of it adversarial, all of it changing the distribution the baseline learned. So a baseline has a half-life, and the half-life differs by surface: sets of external egress destinations rot fastest, logon-hour distributions rot the moment a schedule or shift pattern changes, and parent-child process norms hold longest until new software ships. That is why a baseline should be stored with metadata rather than as a bare number: the window it was learned over, the host or account population it covers, the assumptions it encodes, the named events that invalidate it, and an owner who will tell you when one happens. An expired baseline is worse than none — it generates deviations that are only change, and a team that gets burned by those learns to wave real deviations through.
go deeper
Be ready to say why normal changes at all — fleets grow, schedules move, new software ships — and that a baseline therefore has an expiry date rather than being a permanent fact about the estate.
Explain the mechanics of decay per data source: destination sets churn fastest, hour-of-day distributions break on a schedule or clock change, process lineages move when software deploys. Say what metadata you store so a future reader can tell whether it still holds.
Show that you have felt both failure modes: the queue full of leads that are only change, and the quiet danger of re-cutting a baseline over a period you had not yet explained. Demonstrate how you get change records in front of the hunt team.
Own the arrangement with the platform and identity teams: who is obliged to tell security a window moved, what the hunt programme commits to in return, and how much baseline maintenance you are willing to fund before you change technique.
## A baseline is a photograph, not a law When you learn what an estate ordinarily does, you are measuring a system that people are actively changing every week for entirely legitimate reasons. The baseline captures the estate as it was during the learning window. From the moment it is cut, reality drifts away from it, and the drift is dominated by authorised change rather than by anything an adversary does. ## What actually moves the distribution - **Population change.** The fleet grows, a business unit is acquired, a thousand machines are re-imaged. Counts scale, and anything expressed as an absolute count rather than a rate breaks immediately. - **Schedule change.** A patch window moves from Sunday night to a weekday small hour; a batch job is re-tuned; a team moves to follow-the-sun working. Hour-of-day distributions per account are the most brittle thing hunters build, and they break cleanly rather than gradually. - **Time semantics.** A daylight-saving transition, a collector changing whether it stamps local or UTC, a source that reports in a different zone. Every account appearing exactly an hour out is almost never an intrusion. - **New software.** A deployment agent, a backup client, an EDR sensor upgrade, a new remote-support tool. Each one introduces process lineages and network destinations that were genuinely never there before. - **Third-party churn.** External destination sets are the fastest-rotting baseline of all, because SaaS platforms and content-delivery networks change addresses and hostnames constantly. A destination "never seen before" is a routine event in an estate of any size, which is precisely why destination novelty on its own is weak evidence. - **Business rhythm.** Quarter-end, an annual audit, a peak trading season. A baseline learned in a quiet month manufactures deviations in a busy one. ## Both directions of failure An expired baseline fails twice over, and the second failure is the dangerous one. In the obvious direction it **manufactures leads**: change looks like deviation, the hunt queue fills with things that are simply the estate having moved, and hours go into re-deriving the same explanation. The corrosive part is not the wasted hours; it is that a team which spends a month closing deviations as "the estate changed" builds a reflex to assume that of the next one. In the quiet direction it **blesses the wrong things**: if you re-cut the baseline over a period, whatever was happening during that period becomes your definition of normal, including activity you had not yet explained. Re-cutting is not a neutral act, which is why you re-cut against an explanation of what changed and not merely against the calendar. ## What to record with the baseline Treat a baseline as a documented artefact, not a number in someone's notebook: | Field | Why it matters | | --- | --- | | Learning window (start, end) | Tells the next reader what cycles it did and did not see | | Population covered | Servers, workstations, one business unit, one account class — normal differs by all of them | | Source and enrichment | Which telemetry, which fields, what was normalised (especially time zone) | | Assumptions | "Patch runs Sunday 22:00"; "no migration in flight"; "38 to 42 hosts in scope" | | Invalidating events | The named changes that mean this baseline is dead: a fleet migration, a schedule move, a new management agent | | Owner to notify you | The platform or identity team who will actually know when one of those happens | The invalidating-events line is the one people skip and the one that pays. Writing "this is void if the patch window moves" turns a future surprise into an expected event, and it converts a vague sense that the baseline feels stale into a testable statement. ## Knowing it expired without re-cutting it You do not have to rebuild a baseline to find out it is dead. Keep two or three cheap summary statistics — distinct hosts in scope, the account's busiest hour, the count of distinct external destinations — and re-measure them on a schedule. A step change in a summary statistic is your signal to go and ask what changed, and asking is usually a five-minute conversation with a platform owner rather than a fresh analysis. Better still, get on the receiving end of change: a feed of change records, deployment announcements and maintenance schedules is the single highest-value non-security data source a hunt team can subscribe to, because it converts most deviations from mysteries into cross-references. ## The honest framing A baseline is a working assumption with an expiry date attached, maintained by people who know the estate changes underneath them. Treated that way it stays useful for years. Treated as a fixed definition of normal, it quietly becomes a machine for producing explanations of last quarter.
- Which baseline in a large enterprise rots fastest, and why?The set of external destinations hosts contact. SaaS platforms and content-delivery networks rotate addresses and hostnames continuously, so genuinely new destinations appear every day without anything adversarial happening. Process-lineage baselines on a controlled image last far longer, because they only move when software ships.
- What is the cheapest way to detect that a baseline has expired without rebuilding it?Track two or three summary statistics from the same data — distinct hosts in scope, the busiest hour for an account, the count of distinct external destinations — and re-measure them weekly. A step change tells you to go and ask what changed, which is usually one conversation with the platform owner rather than a fresh analysis.
- Every account's logon hours have shifted by exactly one hour. What do you check first?Time semantics, not the accounts. A daylight-saving transition, a collector that changed whether it stamps local time or UTC, or a source whose zone handling changed will move an entire population uniformly. An adversary does not shift nine thousand accounts by the same hour on the same night.
A baseline is a photograph of a building site, not a map of a city. It is accurate on the day it was taken and increasingly wrong every week nobody re-takes it.
saying these in an interview costs you the question
- Treats a baseline as a permanent definition of normal
- Re-cuts a baseline on a calendar without asking what changed
- Stores a baseline as a bare threshold with no window or population
- Assumes any deviation from an old baseline is adversarial
- Has no route to hear about planned estate changes