In a first-seen detection, what does 'first seen' actually assert about the value it fired on?
answer
- a claim about your history
- the lookback window is the rule
- retention and collection gaps manufacture novelty
- an empty baseline makes everything first seen
- novel is not the same as malicious
basics
~10 sOnly that this value never appeared in the rule's lookback window for that entity. It is a claim about your recorded history, not evidence that the value is malicious or even genuinely new.
solid answer
~50 sA first-seen rule holds a baseline of values it has already observed for some entity, and fires when a record carries a value that is not in that set. So the alert asserts one narrow thing: within the lookback window, over the data that actually reached the platform, this pairing has no precedent. Everything else is inference. The lookback length *is* the rule: a 7-day baseline makes monthly behaviour look novel. Retention truncates it, and a collector outage can make a familiar value look new because the evidence of it was never stored. A brand-new entity, or a whole estate on a new platform, has an empty baseline, so everything is first seen. And novelty is not malice, so the correct next move is to establish whether the novelty has a legitimate cause, not to treat the firing as a confirmed intrusion.
go deeper
Be ready to state the claim in one sentence: no precedent for this entity within the rule's lookback, over the data that was actually collected. Then name why a new user or a collector outage produces novelty with no change in behaviour.
Expect to explain the mechanics: how the baseline is keyed, how retention silently shortens the window, and how a normalisation or field-name change can generate a wave of novelty that is really a parser change.
Show the operating judgment — that novelty is a combining signal rather than a page, that a legitimate new behaviour is a benign true positive, and that a baseline built over a window containing the intrusion permanently hides it.
Own the position that a detection's silence is not evidence, and that novelty-based logic needs a periodic proof it still fires when the behaviour is deliberately performed, because its false-negative rate cannot be read from its output.
## What the rule computes A first-seen (or novelty) detection is built from two pieces: a **baseline** and a **lookback window**. The baseline is the set of value pairs the platform has already observed — typically keyed by an entity and a field, such as *(user, destination tenant)*, *(user, client application)*, *(host, parent-child process pair)* or *(service account, source country)*. The lookback window is the period of history the baseline was built from. The rule evaluates each new record, asks whether its pair already exists in the baseline, and fires when it does not. That is the whole mechanism, and it is why the claim the alert makes is so narrow. Written out precisely, a first-seen alert says: *within the last N days, over the records that were successfully collected, normalised and retained, this entity has not been seen with this value before.* It does not say the value is new to the world, that it is rare across the industry, that it is dangerous, or that anything bad happened. ## The four ways the claim gets weaker than it sounds **Lookback length.** A 7-day baseline over an activity that happens monthly will call the monthly occurrence novel twelve times a year. The window must be at least as long as the longest legitimate cycle you want treated as normal, or every cycle becomes an alert. **Retention and ingestion.** The baseline can only contain what was stored. If the source's retention is 30 days, a 90-day first-seen rule is silently a 30-day rule. If a connector stopped shipping for a week, the values that only occur in that week vanish from history and reappear later as "first seen". Novelty in your baseline can be an artefact of your own pipeline rather than a change in the estate. **Normalisation.** First-seen matching is string comparison in disguise. A change in case handling, a vendor renaming a field, a new client version reporting itself differently, or a domain suffix appearing where it did not before can all produce a wave of novelty that reflects a parser change and nothing else. **Cold start.** A new user, a new device, a newly onboarded application or a migrated tenant has no history, so *every* observation is a first observation. This is the single most common cause of a first-seen rule flooding: the baseline is empty by construction, not because behaviour changed. A mature rule therefore usually carries a learning period — it declines to fire for an entity until that entity has some minimum number of days or observations behind it. ## Novelty is not maliciousness Most novel things in a real estate are benign: someone installs a tool for the first time, a team adopts a new SaaS integration, an engineer works from a country they have never worked from. A first-seen hit that turns out to be a legitimate new behaviour is not a false positive — the rule correctly detected exactly what it was written to detect. It is a **benign true positive**, and calling it a false positive leads people to "fix" the logic when what actually needs fixing is the enrichment, the learning period or the expectation. Because of the base rate, first-seen logic is weak on its own and strong as a *combining* signal. "First time this account has used this client" is a shrug. "First time this account has used this client, and it authenticated from an address it has never used, and it then read at a volume it has never read at" is a lead. The practical pattern is to use novelty as one term inside a rule, or as an enrichment shown to the analyst working some other alert, rather than as a standalone page. ## What silence proves Nothing. A first-seen rule that has not fired in a month is compatible with a quiet estate, with a broken query, with a source that stopped ingesting, and with a baseline that was built over a window containing the adversary's activity — in which case the adversary's behaviour is *in* the baseline and can never be novel again. Absence of output from a detection is not evidence of absence of the behaviour, and it is why baseline-driven rules need an independent check that they still fire when the behaviour is deliberately performed. ## What to say in an interview State the claim in one sentence — no precedent for this entity, in this window, over this data — and then name the three things that can manufacture novelty without any change in behaviour: a short window, a gap in collection, and an empty baseline. That answer shows you understand the rule is a statement about your history rather than about the world.
- A first-seen rule fires on a value the user has demonstrably used for two years. What are the likely explanations?Almost always a baseline problem rather than a behaviour change: the lookback is shorter than you think or is capped by source retention; the baseline was rebuilt or reset; a collector gap removed the evidence; or normalisation changed so the value now renders differently — a case change, a renamed field, a new client string. Check the pipeline before you investigate the user.
- Your first-seen rules have produced no alerts in six weeks. Is that good news?It is not evidence of anything on its own. It is equally consistent with a quiet estate, a query that silently returns nothing, a source that stopped ingesting, and a baseline built over a window that already contains the intruder's behaviour, which makes that behaviour permanently unremarkable. Confirm the rule still fires by performing the behaviour deliberately, not by trusting the silence.
- Would you page an analyst on a bare first-seen hit?Rarely. On its own the base rate is terrible — real estates generate novelty constantly. It is far more useful as one term inside a wider rule, or as enrichment displayed on an alert that fired for another reason: 'first time this account has used this client' means little alone and a lot next to unusual volume from an unfamiliar address.
It is the difference between "I have never met this person" and "this person is a stranger to everyone". The first is a fact about your memory; only the second would be a fact about them.
saying these in an interview costs you the question
- Says first seen means the value is new in the world, not just in your data
- Treats a first-seen hit as confirmation that something malicious happened
- Forgets that lookback length and log retention define the claim
- Calls every legitimate novel behaviour a false positive instead of a benign true positive
- Reads a quiet first-seen rule as proof the estate is clean