Detecting and Investigating Threats: From Notable to Disposition
Anatomy of a detection
A correlation search runs on a schedule and turns qualifying results into notable events. Its parts matter: the search and time range, schedule, throttling or suppression fields that prevent duplicate notables per key, severity, and adaptive responses. Urgency is not typed by hand - ES derives it from severity combined with the priority of the involved asset or identity, which is why clean asset and identity lookups change what floats to the top of the queue.
Investigating
In Incident Review you take ownership, set status, and expand the notable to see contributing events; the event timeline and drill-downs pivot to raw evidence. Enrichment is the point: is the destination asset critical, is the source IP in a threat intel collection, does the same user appear in several unrelated detections? Correlate across data models rather than trusting one event.
Traps
Throttling suppresses by field value within a time window, not permanently; the search's suppression fields are a different mechanism from disabling the search. Closing a notable without a disposition teaches the SOC nothing. Tune by narrowing logic or adding exception lookups, never by switching a detection off silently.
Worked example: an "Excessive Failed Logins" notable fires. Expand it, count attempts by src, check whether the destination asset is high priority and whether src matches threat intelligence, confirm any subsequent success using the Authentication data model, then set status and disposition and add a confirmed scanner to an exception lookup.