What do you put in front of an incident lead when handing over a live hunt finding with no enrichment?
answer
- you hand over a hypothesis, not a verdict
- name the missing enrichment yourself
- say what would disprove you
- live now, or historical?
- subtract your own footprints
basics
~20 sA one-line claim, the raw records with time range and timezone, the hypothesis and what would disprove it, your confidence and its basis, what is still live, what you already touched, and the specific decision you are asking for.
solid answer
~50 sI hand over a hypothesis, not a conclusion, and I say so in the first sentence. The package is: the claim in one line; the matched records themselves with time range and timezone; the hypothesis and, explicitly, the evidence that would disconfirm it; my confidence and what it rests on; what is happening *right now* versus what is historical; the named gaps — no rule fired, no vendor verdict, no intel match, so none of the usual corroboration exists; a note of every query I ran and any access I made to the runner, so my footprints can be subtracted from the timeline; who owns the asset and the fact that security has read-only access to the build platform. Finally the ask: the specific decisions I need someone with authority to make, which I am not making myself.
go deeper
Know that a hunt finding is handed over as a hypothesis with its evidence attached, and that you say up front which normal corroboration, such as a rule name or vendor verdict, is absent.
Explain the contents of a handover package and why each element exists, especially the live-versus-historical statement and the record of your own actions on the investigated system.
Demonstrate calibration: a narrow evidenced claim, an explicit disconfirmer, confidence tied to specific observations, and a clean separation between what you observed and what you infer.
Own the credibility economics of a hunting programme whose findings arrive without enrichment, and the norms that keep such findings from being routinely discounted by the incident process.
## What makes this handover different A normal escalation moves a case that already has scaffolding: a rule name that states an intent, a severity, a triage note, prior dispositions, often a vendor verdict. A hunt hit arrives naked. The incident lead's first instinct will be to look for the usual handles and find none, and the risk is that the finding is discounted for lacking things it was never going to have. The handover has to supply the scaffolding in human form. It is also different because you are transferring an **open investigation with a live hypothesis**, not closing a ticket. The person receiving it will act on your framing for the next hour. Any confidence you imply and cannot support gets amplified. ## The package, item by item **One-line claim.** "Interactive commands not present in the pipeline definition ran on self-hosted runner build-07 during a release job at 02:16 UTC on 11 June, archiving the workspace and the runner's registry credentials." A claim, scoped, timestamped, falsifiable. Not "possible compromise of the build system". **The records.** The matched events themselves, exported, with source, event time, collection time, and the time range and timezone you searched. The lead should be able to read the evidence rather than your paraphrase of it. **The hypothesis, and its disconfirmation.** State what you think happened and — this is the part people skip — what would show you are wrong. "If a change record or an on-call ticket covers a manual intervention on this runner in that window, my hypothesis collapses." Offering the exit tells a lead you are calibrated, and it converts the next twenty minutes into a checkable step instead of an argument. **Confidence and its basis.** Not a number on its own. "Moderate, resting on the commands being absent from the repository's pipeline definition and on the archive path being outside the workspace. It would become high if no engineer claims the session." **Live versus historical.** Say plainly whether the behaviour is still occurring, when it was last seen, and whether the asset is still able to reach whatever it was reaching. A lead's options are completely different for an ongoing action versus a three-week-old trace, and this single sentence drives everything they do next. **The named gaps.** No rule fired, no vendor verdict, no intel match, no prior disposition to compare against — and the reason: nothing in the estate reads pipeline step output. Naming the gaps yourself is far stronger than having them discovered; it also stops the absence of an alert from being read as evidence of benignness. **Your own footprints.** Every query you ran, every page you opened, and above all any interactive access to the runner. Your commands land in the same history you are asking someone to treat as evidence. Hand over the subtraction list. **Ownership and authority.** Who owns the build platform, that security has read access and no authority to stop a pipeline, and who the engineering-side contact is. The lead needs to know which levers exist and whose hand is on them before they consider pulling any. **The ask.** End with the decisions you need, stated as decisions: does this get declared, who talks to the release engineering manager, does anyone go near the runner. You are not making those calls; do not smuggle them in as assumptions. ## Register: uncertainty is not weakness Hunters routinely damage their own findings in one of two directions. They oversell — "we've found an intrusion in the build system" — and lose credibility when it turns out an engineer was debugging. Or they hedge into meaninglessness — "some unusual activity, might be nothing" — and get deprioritised behind the alert queue. The way through is a firm, narrow, evidenced claim plus an explicit statement of what is unknown. Confidence about the *observation* and honesty about the *interpretation* are different axes, and a good handover is high on the first and precise on the second. ## Where your responsibility stops The evidence bar for declaring an intrusion, and who may declare it out of hours, is the incident lead's domain, not yours. So is the decision to isolate the runner or watch it longer, and who authorises that. Your job is to make sure that whoever holds those decisions holds them with an accurate picture — including an accurate picture of what you do not know.
- Why volunteer the evidence that would disprove your own hypothesis?Because it makes the finding checkable and it protects your credibility across findings, not just this one. A named disconfirmer turns a debate about plausibility into a concrete next step someone can go and run. It also signals calibration, which is the currency a hunter spends every time they escalate something with no rule behind it.
- The lead reads it and does not act. What do you do?Find out which part failed: was the claim not credible, not urgent, or not theirs to own? Fix that specific thing rather than repeating the case louder. Record the decision and the reasoning in the case, keep the evidence preserved regardless, and if the disagreement is about risk rather than facts, escalate it as a risk decision with a named owner.
saying these in an interview costs you the question
- Presents a hypothesis as a confirmed intrusion
- Hedges so heavily the lead cannot act on anything
- Omits that no rule, vendor verdict or intel match exists
- Never states whether the activity is still ongoing
- Leaves out their own logins and queries on the investigated host