In an alert case note, why record what you ruled out and the exact query that ruled it out?
answer
- a conclusion is not evidence
- zero results need a stated scope
- no records is not no activity
- blind spot versus clean host
- the next analyst will not redo it
basics
~20 sBecause a conclusion is not evidence. A zero-result search only means something if the note records what was searched, over what window and which sources - otherwise a later reader cannot tell a clean host from a blind spot.
solid answer
~50 sRuling something out is the expensive half of triage and the half that decays fastest. `No lateral movement from FS-07` is an assertion; the query, its data sources, its time window and its known coverage gaps are what let someone else evaluate it. The distinction that matters is that **absence of records is not absence of activity**: the host may have had no agent, the forwarder may have been down, the retention window may be shorter than the period you searched, the field may not be collected (native Windows 4688 carries the command line only if audit policy was configured for it), or the Security log may have been cleared - which itself shows up as event 1102. If the note records only the conclusion, the next analyst inherits your confidence without your caveats, and either repeats the work or, worse, does not.
code
text · 13 lines[weak]
Ruled out: no lateral movement from FS-07.
[usable]
Ruled out: outbound interactive/remote logons FROM FS-07,
window 2026-03-11T00:00Z - 2026-03-12T08:00Z (starts 26h before first alert)
- Sysmon Event ID 1 (process create) on FS-07, image in (psexec*, wmic.exe, ...)
-> 0 results
- Windows Security 4624 logon type 3, IpAddress = 10.4.7.31 (FS-07),
across all DCs + member servers
-> 3 results, all svc_backup at ~02:00Z, matches prior 30 days
Coverage gap: 4 of 61 member servers have no log forwarder (see asset list);
the 4624 search does not cover them.go deeper
Know that a case note records what was ruled out as well as what was found, and that a search returning nothing still gets written down with the query that produced it.
Explain why an empty result is uninterpretable without scope - sensor coverage, retention, missing fields, a cleared log - and be able to write a ruled-out entry that a stranger could re-run.
Demonstrate judgment about coverage: knowing which parts of your estate are blind before you search, and stating that gap in the note rather than discovering it after the case reopens.
Frame it as evidence quality across the whole SOC: what the organisation can defend about a closed case, and whether known telemetry gaps are documented once centrally or rediscovered by every analyst.
## Negative findings are the fragile part of a case Most of triage is elimination. You start with a firing rule and a set of possible explanations, and you spend the hour narrowing them. What you actually produce is a list of things that are *not* happening - and negative findings are exactly the claims that a reader cannot re-derive without knowing how you got them. A positive finding carries its own evidence: here is the process, here is the command line, here is the connection. A negative finding carries nothing. `I found no lateral movement` is indistinguishable, on the page, from `I looked in the wrong place`, `I searched a window that ended before the activity started`, and `the hosts I searched do not send logs`. ## What a usable ruled-out entry contains Four things, and each of them is load-bearing: 1. **The hypothesis being eliminated**, stated as a behaviour rather than a label - `interactive logons from FS-07 to other servers` rather than `lateral movement`. 2. **The query, verbatim**, with the data source or index named. 3. **The time window, in UTC**, including why that window (it should normally extend before the first observed activity, not start at the alert). 4. **The scope and its gaps** - which assets were in scope, and which of them do not actually report. The fourth is the one that gets left out and the one that later turns out to matter. ## Why absence of records is not absence of activity The reasons a search comes back empty on a compromised estate are ordinary and numerous: - **No sensor.** The endpoint agent was never deployed, or was deployed and is unhealthy. Coverage is rarely 100 percent and is almost never 100 percent on the servers nobody wants to reboot. - **No transport.** The forwarder was down, the collector queue dropped, the network segment does not route to the collector. - **No field.** The record exists but not the attribute you searched. Windows Security event 4688 records a process creation, but its command line is only present when command-line auditing was enabled; a Sysmon Event ID 1 record carries the command line, parent image and hashes as a matter of course. Searching a command-line pattern across a fleet where half the hosts emit only bare 4688 quietly halves your coverage. - **No retention.** The window you searched is longer than the data you hold. - **No log.** Windows Security event 1102 records that the audit log was cleared - and its presence is itself a finding, while its consequence is that the period before it cannot be reasoned about from that source. - **No match by construction.** An index filter, an account filter or a case-sensitivity quirk excluded the very data you meant to search. A note that pastes the query lets the next reader spot any of these. A note that says `ruled out` lets none of them be spotted. ## What this buys the next reader **Non-repetition.** The next analyst does not re-run the same hour of work - and, when the case reopens because the host alerts again, can go straight to the ground that was never covered. **Correct confidence.** Reasoning inherits caveats only if the caveats were written down. A note that records `0 results, but 4 of 61 member servers have no forwarder` produces a different next step from one that records `0 results`. **Falsifiability.** The point of exposing the inference chain is that a reader can attack a specific step. If someone disagrees with your verdict, you want the disagreement to land on `your window started too late` rather than on `I do not trust your conclusion` - the first is fixable in ten minutes, the second is an argument. **Defensibility much later.** When a case closed as benign is revisited after the same host turns out to have been compromised, the question is not whether you were right. It is whether the decision was reasonable on the evidence available. The recorded scope is what answers that; a bare conclusion cannot. ## The habit Write the ruled-out entries as you go, not at close. At close you will compress them into their conclusions, because by then you know the answer and the intermediate steps feel like noise. They are the note.
- Name the ways a zero-result search can be meaningless.No agent or forwarder on the hosts in scope; the field not collected at all, as with native 4688 without command-line auditing; retention shorter than the searched window; the Security log cleared, which event 1102 records; or a filter, index or account scope that silently excluded the data. Any of these turns an empty result into no information rather than a negative finding.
- A colleague reads your note and disagrees with a ruled-out conclusion. Why is that a good outcome?Because the note did its job. Exposing the query, window and scope means the disagreement lands on a specific step - the window started too late, the scope missed a subnet - which is checkable in minutes. A note that records only the verdict produces a dispute about judgment instead, which nobody can resolve with evidence.
saying these in an interview costs you the question
- Writes ruled out with no query or scope
- Treats zero results as proof the host is clean
- Assumes every host in scope reports to the SIEM
- Paraphrases the search instead of pasting it
- Records only evidence that supported the verdict
- Starts the search window at the alert timestamp