What must a hunt query gain before it can run unattended as a detection rule?
answer
- it must run without its author present
- half a hunt query lives in the hunter's head
- breadth is a feature for hunting, a defect for alerting
- threshold, window, owner, triage note
- can you write the benign baseline down?
basics
~20 sIt has to stand without its author: logic narrowed from browse-everything to one defensible claim, an explicit threshold and evaluation window, a named owner who answers when it misfires, and triage notes saying what benign matches look like and what the analyst does next.
solid answer
~50 sA hunt query is run by the person who wrote it, so half of it lives in their head: the hypothesis, the hosts they meant, and the eyeball test they apply to the rows that come back. A rule runs unattended and hands its output to someone who has never met the hunter, so everything implicit has to be written down. Concretely I want the logic narrowed from `show me every WMI subscription` to one claim worth a verdict; an explicit threshold and evaluation window; enough fields carried in the alert that a first responder does not have to re-run the query to understand it; a named owner who takes the call when it misfires; and a triage note listing the known benign producers and the pivot steps. If I cannot write the benign baseline down, the query is not ready to be promoted — it is still a hunt.
go deeper
Be ready to say plainly that a hunt query is read by its author and a rule is read by a stranger, and to list what must be written down for that stranger: threshold, window, owner, benign baseline, next pivot.
An interviewer expects you to explain the mechanics of the narrowing — why a rule needs an explicit evaluation window, what fields the alert must carry so nobody re-runs the query, and how the benign baseline becomes logic rather than folklore.
Show the judgment: you decide what recall to give up in exchange for an output your team can actually work, and you can name the readiness test — if the benign baseline cannot be written down, the query is not ready to be a rule.
Own the handshake itself. Define what a hunt team must hand over before a detection team accepts a rule, and be willing to refuse a promotion when the knowledge is not travelling with the logic.
## The two artefacts are not the same thing A **hunt query** is an instrument for looking. A person forms a hypothesis, writes a search broad enough that the interesting thing cannot hide from it, runs it, and reads the output with everything they know about the estate loaded in their head. Breadth is a feature: forty rows are fine, because a human is going to skim them and only two will be interesting. A **detection rule** is an instrument for asserting. It runs on a schedule nobody watches, and each time its condition is satisfied it produces an alert — a claim that something here is worth a person's time. Breadth is now a defect, because every row becomes a claim, and a claim nobody can dispose of is worse than no claim at all. Promotion is the work of converting the first into the second. It is not scheduling the query on a timer. ## What has to be added **1. A narrowed claim.** The hunt asked *what WMI event subscriptions exist across this estate?* The rule has to ask something smaller and defensible — for example, *a `__FilterToConsumerBinding` was created by an account outside the set that our management tooling uses*. You are trading recall for the ability to work the output. That trade is the promotion decision, and it should be made deliberately rather than discovered when the queue fills. **2. A threshold and a window.** A query has no notion of "too many". A rule needs to state what it evaluates over — a single record, or N occurrences within a window — because the same logic that is interesting once a month is a wall of alerts when a deployment tool re-registers subscriptions on four hundred hosts in twenty minutes. **3. The fields the alert carries.** The hunter had the whole result set on screen and could pivot instantly. The analyst receiving the alert gets whatever the rule chose to include. If the alert says only *WMI binding created on HOST-1421*, the first thing that analyst does is reconstruct the query — which is exactly the work promotion was supposed to remove. Carry the account, the host, the consumer name and the record timestamps. **4. A named owner.** Someone has to answer when the rule misfires, when the estate changes under it, or when an analyst asks what it means. If the hunter is the only person who understands the logic and is not taking that role, the rule is not ready: you have moved work from a hunt backlog into an alert queue without moving the knowledge with it. **5. Triage notes.** This is the part most often skipped and the part that decides whether the rule survives. The note should state the hypothesis in one sentence, the technique it claims to catch, the **known benign producers** of the same records, the pivots to run next, and what a confirmed hit means operationally. WMI event subscriptions are a good illustration: software distribution agents, hardware vendor management stacks, monitoring agents and some antivirus products all create permanent subscriptions legitimately. A hunter knows that. An analyst at 03:00 does not, and without the note their only options are to guess or to close it unread. ## The test for readiness The practical check is: **can you write the benign baseline down?** If you can enumerate what legitimately produces these records in your estate, you can narrow the logic around it and write a triage note that lets someone else dispose of a match. If you cannot — if the answer is genuinely "it depends what the command line says" — then the query has not become a rule yet, and forcing it into one produces a noisy alert plus a coverage claim you cannot defend. ## Common failure modes - **Cron-ing the hunt.** The query is scheduled unchanged, the queue floods, the rule is muted within a fortnight, and the estate now has a detection everyone believes in and nobody reads. - **Keeping breadth for safety.** "Better to see everything" is correct for a hunt and wrong for a rule. A narrow rule that is actually worked beats a broad one that is ignored. - **Promoting without an owner.** The hunter moves on, the estate changes, and the rule slowly becomes an artefact nobody dares touch. - **Losing the hypothesis.** Six months later nobody can say what the rule was for, so nobody can say whether it still does it. Promotion is a handover, not a deployment. What you are really handing over is judgment, and judgment only travels if it is written down.
- What goes in the triage note that the rule's logic cannot express?The hypothesis in one sentence, the technique it claims to cover, the known benign producers in this estate, the pivots to run next, and what a confirmed hit means. Logic can exclude a benign source, but it cannot tell an analyst why that source exists or what to do when a new one appears.
- Should a promoted rule return exactly what the hunt query returned?No. A hunt query is deliberately broad so a person can look; a rule keeps only the subset you can defend as worth a verdict. Recall is traded for workability on purpose. If the narrowed rule no longer covers something the hunt did, that residue is still a hunt, and it should be recorded as one rather than quietly dropped.
- The hunter says they will own the rule but they sit outside the SOC — is that acceptable?It can be, provided the ownership is real: they answer when it misfires, they update it when the estate changes, and analysts know how to reach them. What is not acceptable is nominal ownership with no route to the owner, because the first noisy week then ends in the rule being silenced rather than fixed.
A hunt query is a torch you carry; a detection rule is a light you leave switched on for whoever walks in next. The second one has to point somewhere useful without you standing behind it.
saying these in an interview costs you the question
- Says promotion just means scheduling the hunt query
- Keeps the query broad so the rule does not miss anything
- Leaves the benign baseline in the hunter's head
- Ships a rule with no owner and no triage note
- Treats alert volume as a problem to solve after go-live