The CIO asks why a utilities clerk now has a risk notable. What must the civic RBA stack provide so the analyst can explain the notable without guessing?
Select an answer to reveal the explanation.
Short Explanation
A good risk notable is a story, not a mystery novel. Contributing events are the chapters: rare VPN, mailbox rule, off-hours admin. If the analyst cannot walk the CIO through those chips, the stack is not finished.
Full Explanation
In Splunk Enterprise Security for a municipal SOC, a healthy RBA stack uses many risk rules writing contributing events and only one or a few risk notables when aggregated score on a risk object crosses threshold. Those contributing events are what let an analyst explain why a utilities clerk now has a risk notable—reconstructing which civic signals fired, in what order, and how they map to ATT&CK—without guessing for the CIO. A single notable-only search with no contributing events fails by concept because one opaque page is easier to open but impossible to explain as a scored story. A custom KV store dump of every civic syslog line from the past year fails by concept because a raw dump is not a risk narrative and overwhelms leadership with unprioritized noise. An Enterprise Security admin XML backup of the correlation-search stanza fails by concept because configuration backups are for restore and change control, not analyst storytelling of a clerk’s risk. Exam caveat: SPLK-5001 expects the analyst to require explainability—many risk rules feeding few risk notables with inspectable contributing events—not notable-only opacity or admin artifacts. Operational check: open the utilities clerk’s risk notable, list contributing risk events and annotations, walk the CIO through the scored story in chronological order, and flag any risk rules that lack annotations or clear civic descriptions before the next briefing.