You have twelve hunt ideas and one week a month to hunt — how do you rank them and close each out?
answer
- data first, then rank
- missing telemetry is a collection request
- a quiet rule is not evidence of coverage
- what would a hit actually change
- the box ends the hunt, not the query
basics
~20 sGate on telemetry: an idea whose data cannot cover the window becomes a collection request, not a hunt. Then rank by relevance, by sceptically assumed coverage, and by whether a hit is routable. Time-box each one and write it up.
solid answer
~50 sI treat the backlog as a queue with one gate and three ranking dimensions. The gate is data: if the sources needed do not exist or do not retain long enough, the item is a collection requirement, not a hunt, and it leaves the list. Then I rank by relevance — does a named actor class or a recent report put this behaviour near our crown jewels — by coverage, meaning whether a control plausibly already catches it, remembering that a rule's silence is not evidence it works, and by routability: will a hit produce a fix, a baseline or a rule candidate rather than only something interesting. Cheap hunts beat week-long joins. Then I book the cadence, because hunting in slack time never happens, and every hunt is time-boxed and closed with a written record of hypothesis, sources, window, result and what it could not cover.
go deeper
Know that hunts are chosen from a backlog rather than improvised, that each one is time-boxed, and that a hunt which finds nothing still has to be written up with what was searched.
Explain the telemetry gate and why an idea without data becomes a collection requirement instead of a low-ranked hunt. Be able to list the fields a close-out record must carry.
Show real ranking judgment: relevance to your estate, sceptical treatment of assumed coverage, and whether a hit would produce something routable. Defend a fixed cadence over hunting in slack time.
Be ready to justify spending a recurring block of scarce analyst capacity on work that often returns nothing, and to define what the programme owes the rest of the organisation in return.
## Why a backlog needs an explicit ranking at all Hunt ideas arrive faster than they can be worked: from intel reads, from incidents elsewhere in the sector, from an analyst's hunch, from a control you suspect is not doing anything. If the ordering is implicit, the list is worked by recency and enthusiasm, which reliably produces a run of interesting hunts on the same technique family and nothing at all on the estate's dull, important corners. ## The gate, applied before ranking Does the telemetry exist, cover the devices in scope, and retain long enough to answer the question? If not, the item is not a hunt at all. It becomes a collection requirement addressed to whoever owns the source, and it leaves the backlog until that is delivered. Ranking an item you cannot execute wastes the slot when it comes up, and it lets an unanswerable question sit near the top of the list for months looking like work in progress. ## Three ranking dimensions **Relevance.** Is there a reason to believe this behaviour would appear here? A recent report on an actor class targeting your sector, a technique that leads directly to a system you would not survive losing, an estate change that opened a path. Relevance is what stops the backlog becoming a list of everything ever published. **Coverage, treated sceptically.** If a control or a detection would plausibly catch this, the item ranks lower — but only plausibly. A rule that has not fired in six months is not evidence that the behaviour is absent, because a detection's absence of output is equally consistent with a broken pipeline, a source that stopped reporting, or a rule that never worked. So a hunt aimed at testing an assumed coverage claim is itself a legitimate and often high-value backlog item. **Routability.** Ask, before starting, what a positive result would do. Would it yield a configuration fix to hand to an asset owner, a baseline that makes future work cheaper, or a candidate for a standing rule? Ideas whose only outcome is a paragraph of interest rank below ideas whose outcome changes the estate. Cost cuts across all three. Three afternoon hunts that each answer a real question beat one week-long data-engineering exercise, especially early in a programme when the team is still learning which sources are trustworthy. ## Cadence beats intent A fixed slot — one week a month, the same week — is the difference between a hunting programme and an aspiration. Hunting done in slack time is hunting that never happens, because slack time is exactly what a security operations team does not have. The booked week also lets the rest of the organisation know when to expect the tickets a hunt produces. ## Time-boxing, and what to do when the box runs out Each hunt gets a box before it starts, and when the box ends the hunt ends. If the query was still half built, that is not a failure and it is certainly not a negative result — record what was actually searched and covered, and put the remainder back on the backlog as a new item with everything learned attached. The commonest way a hunting week evaporates is one analyst disappearing into a data-quality problem on day one and emerging on Friday with nothing written down. ## What closing out means Every hunt, positive or negative, ends with a short record that names: - the hypothesis and where it came from; - the sources queried, the devices they actually covered, and the exact time window; - the logic used, in enough detail that someone else could repeat it; - the result, including a negative one; - what the hunt could not cover — the non-reporting devices, the missing source, the retention edge; - what was routed onward, and to whom. That last two lines are what make the backlog shrink honestly rather than cycling. And the coverage caveat is what stops a negative result being quoted six months later as proof the estate was clean. ## Re-runs Some hunts deserve a cadence of their own — quarterly, say — not because they are unfinished but because the estate changes: new devices, a new acquisition, a new department with its own tooling. Distinguish those from a hunt that recurs only because the underlying problem was never routed to a fix; the second is a sign you skipped the ticket.
- One idea is a hunt for whether an existing detection is really working. Where does that rank?High, if the control it questions guards something important. A detection that has not fired proves nothing on its own — the same silence is produced by a healthy estate, a stopped log source and a rule that never matched anything. Testing that assumption converts a belief on the coverage map into a fact, and a failure there is worth more than another novel technique hunt.
- How do you stop the same hunt being re-run every quarter forever?Ask whether it recurs because the estate changes or because nothing was fixed. Population drift — new devices, an acquisition, a new team's tooling — justifies a standing cadence. A hunt that keeps finding the same unmanaged installs is telling you the ticket was never raised or never landed, and the fix is a configuration change, not a calendar entry.
- An analyst wants to spend the whole week on one hypothesis. When do you allow it?When the question is high relevance and genuinely needs the depth — a crown-jewel path, or a source nobody has ever queried properly. Otherwise prefer breadth early, because each hunt teaches you which sources are trustworthy. Either way the box is agreed up front and the close-out record is due at the end, whatever the state of the query.
saying these in an interview costs you the question
- Rank by whatever technique is in the news this week
- Hunt whenever the queue is quiet, with no booked slot
- The rule has not fired, so that area is covered
- Extend the time box until the hunt finds something
- A hunt that found nothing needs no write-up