Frame a Threat Hunting Conversation Around a Testable Hypothesis

Threat hunting starts with a question small enough for people to answer. A broad request to find unknown problems leaves the reviewer with no shared subject, time range, or reason for looking. Begin with one behavior, one asset group, or one business event. Ask the operations leader what concern prompted review and what decision needs support. A bounded question gives the work a purpose before anyone searches a record.

A useful hypothesis names a suspected pattern without presenting suspicion as proof. “We want to review administrator sign ins outside our release hours” identifies an account group and a context. “Look for unusual activity” does not. Each listener supplies a personal meaning for unusual. Ask the customer to describe the behavior in ordinary language. Record their own terms. Then restate the question in one sentence and ask whether your restatement matches their concern.

In a fictional practice situation, Dana leads security operations for a financial software company. Dana says, “Our release managers use elevated access on Tuesday evenings. We want a closer review of access outside those hours.” The consultant asks, “Do you want a first review of administrator sign ins during a defined period, with named release accounts handled separately?” Dana says yes and selects Friday evening through Monday morning. Her answer creates a starting boundary rather than an endless assignment.

Ask why this issue reached the agenda now. A team transition, an access process change, or an internal review might have raised concern. Do not turn a concern into an incident during discovery. Ask, “Which business event made this question important for your team?” Dana explains a new release approval process began last month. The consultant adds this context to the work record. Context helps later reviewers understand why a chosen period and account group matter.

Define the subject with enough care for another person to recognize each account group. “Administrator access” might refer to named human accounts, shared operational accounts, service accounts, or several groups. Ask Dana who belongs in the first review and who stays outside scope. Dana wants named administrator accounts. Release manager accounts form an exception group once she supplies a current list. The plan should say exactly this. A reader should not need to infer which accounts belong in review.

Time boundaries deserve equal attention. Weekend has different meaning across teams and operating locations. Ask for an exact start, an exact end, and the time zone used by the customer. Dana selects Friday at 6:00 p.m. through Monday at 6:00 a.m. in her team’s operating time zone. The consultant asks how an approved release beginning at 5:00 p.m. Friday should appear in review. Dana asks for such events to stay visible with a release note beside them. This choice avoids later disagreement about a borderline event.

Before describing a method, ask where approved evidence lives. The customer might offer identity records, endpoint records, network records, or another source. Do not assume every source has coverage for the selected period. Ask who understands each source, what event type appears there, and whether history exists for the review window. Dana says identity records show sign in events for all named administrator accounts. Endpoint records cover only part of her server estate. Both statements belong in the plan as limits, not as hidden assumptions.

Data ownership matters alongside access. A security operations lead might approve review of one source while an identity team answers questions about another. Record a contact for each source and a contact for gaps. Dana names Jordan from identity operations for sign in records and Mei from server operations for endpoint coverage. The consultant asks each person for a brief statement of what their record does and does not show. A short ownership note prevents a later meeting from becoming a search for the right person.

Choose comparisons only after learning whether the customer has an approved reference. Dana says her team maintains a privileged access roster and a release calendar. The consultant asks who owns each item and how current each item is. Jordan owns the roster. Malik from release operations owns the calendar. If either record lacks an owner or lacks a current version, write an open item. Do not replace a missing roster with a personal estimate or a different record whose purpose does not match the question.

The hypothesis needs a planned reviewer as well as evidence. Without a reviewer, an event list becomes a document with no decision attached. Ask, “Who will explain whether a named event belongs to expected work?” Dana names Jordan and Malik. Their task is interpretation of customer context, not a personal judgment by the consultant. Agree on their availability before work begins. Dana asks for a thirty minute review on the Thursday after the selected weekend. The plan records this appointment beside the question.

Agree on the meaning of a finding before review starts. A finding might be an administrator sign in with no listed release explanation, an event outside the chosen interval, or an event where available records leave a question unresolved. None of these labels proves harmful activity. An unmatched event often needs customer context, a record correction, or a later review. Ask Dana how her team wants unmatched events presented. She asks for the event time, account name, available reference result, and a question for the reviewer.

Connect the question to a customer decision. Dana says an unexplained event would lead her team to review associated access approval records. A series of expected events might lead her team to improve release documentation for future weekends. Those are customer decisions. They do not claim a security outcome. Write this next decision beside the hypothesis so everyone sees why the team is reviewing records rather than collecting a long list of events with no next use.

Use a short written plan to test shared understanding. For Dana, the consultant writes: “Review named administrator sign ins from Friday 6:00 p.m. through Monday 6:00 a.m. for the selected August release period. Compare available identity records with Dana’s approved access roster and Malik’s release calendar. Present unmatched events to Jordan and Malik for context review.” Dana reads the sentence and asks for service accounts to stay outside the first review. The consultant adds this exclusion before work starts.

Some customers begin with a much larger concern. A fictional operations director says, “We worry about privileged access across every system.” Do not dismiss the concern or accept an unlimited assignment. Ask which system group, period, or recent change deserves first review. The director selects finance production systems after a team transition. Then ask who owns the roster and who would use a review result. A smaller first review gives people time to resolve definitions before expanding scope.

Other customers offer a technical signal with no decision attached. A manager asks for a search related to remote access records. Ask, “If available records show a pattern needing review, who needs an answer and what choice sits before them?” The response might point to an internal documentation discussion, a review of account ownership, or a future process decision. This question stops activity for its own sake. If no decision exists, record the request and agree on what information would make a first review worthwhile.

Expect disagreement about scope. Jordan wants all privileged accounts in view. Malik wants only human accounts because release accounts have their own calendar. Put both views in the call record. Ask which group best serves the first review and which group stays outside its boundary. Dana selects named human administrators for the first review and asks Malik to prepare a separate release account question after the weekend review. The choice belongs to Dana, with both specialists able to see why.

Do not hide unknowns. If source history begins halfway through the selected period, write the gap. If the privileged roster has no current owner, ask Dana to name one. If a planned reviewer will be absent, select another review date. An explicit unknown gives the customer a real choice: narrow the period, wait for an input, or proceed with a stated limit. Hidden uncertainty creates a false sense of precision.

Finish the planning call with one specific action. In Dana’s practice situation, Malik has not yet accepted the calendar review. The consultant sends Dana and Malik the one paragraph hypothesis, asks Malik to confirm calendar availability by Wednesday at noon, and holds the record review until his answer arrives. Once Malik replies, Dana opens one sample sign in beside the roster and calendar entry, records how Jordan and Malik classify the sample event, and uses their exact rule for the remaining events.