A behavioral hunt finds several odd but individually weak actions on a permitting clerk identity. How should those findings feed Enterprise Security?
Select an answer to reveal the explanation.
Short Explanation
Think of each odd click as a pebble, not a siren. Drop those pebbles onto the clerk's risk object and let Risk-Based Alerting add them up. One notable per pebble is how a permit desk becomes an alert landfill.
Full Explanation
Behavioral hunting often yields individually weak signals that matter in combination on a single identity or asset. When a behavioral hunt finds several odd but weak actions on a permitting clerk identity, the correct Enterprise Security feed is to write each odd behavior as a risk event on that identity so Risk-Based Alerting can accumulate score and raise a risk notable instead of firing an alert storm. That pattern preserves contributing-event context and matches how ES is designed to handle multi-signal civic abuse. Creating a separate notable for every odd click floods Incident Review and trains analysts to ignore permitting alerts. Discarding the behaviors until a single hash match appears throws away valid account-abuse evidence that may never involve known malware. Disabling the clerk account automatically from the hunt search jumps to containment without risk scoring, approval, or correlation and can interrupt legitimate permitting work. Exam caveat: hunt-to-RBA means risk events first for weak multi-signal behavior—not one notable per click and not hash-gated silence. Operational check: for each odd permitting-clerk action, write a risk event keyed to the identity with an appropriate risk score and threat object, verify the risk notable assembles contributing events, and only then decide on analyst-driven response rather than auto-disable from the hunt.