Splunk Enterprise Security raises dozens of separate low-severity notable events for one user each day, such as an odd login time, a new device and a rare process. Analysts dismiss them individually. Which approach surfaces the user only when combined activity becomes significant?
Select an answer to reveal the explanation.
Short Explanation
One odd thing is noise; five odd things on the same person in a day is a story. Risk-based alerting keeps a running score per user and only taps you on the shoulder when the score adds up. Turning the searches off is the trap, because you lose the very clues that add up.
Full Explanation
Risk-based alerting in Splunk Enterprise Security changes how detections contribute to alerts. Instead of every detection creating its own notable event, detection searches add risk scores, annotated with context such as MITRE ATT&CK techniques, to risk objects such as users or systems. Risk incident rules then evaluate the accumulated risk and the diversity of contributing behaviors over a time window and create a single notable event only when the total for an entity crosses a threshold. Analysts see one alert describing the full set of behaviors for the user instead of many individually dismissible ones. Disabling the low-severity searches removes the signals that would combine into a meaningful picture. Forwarding notables to a management email list moves the volume problem to different people without adding context. Inflating every notable to critical destroys prioritization and increases fatigue, since everything becomes urgent. Exam caveat: risk scores need tuning per detection and entity so routine activity by administrators or service accounts does not dominate, and newer ES releases may label notables as findings. Operational check: review the risk analysis for the user, confirm the contributing detections and scores, and verify a single risk notable fires when the threshold is exceeded.