The municipal VPN detection for a logon from a rare city is too cheap to page the on-call by itself. How should that hit become part of a later risk notable?
Select an answer to reveal the explanation.
Short Explanation
Don't pull the fire alarm for one odd VPN—stamp a chip on the account instead. Risk-analysis AR writes that cheap hit to the risk object so it can add up later. That is how a rare-city logon becomes a contributing event, not a 2 a.m. page.
Full Explanation
When a municipal VPN rare-city logon is too cheap to page on-call alone, the risk-analysis Adaptive Response writes to the risk index against the risk object so the hit becomes a contributing event toward a later risk notable. That is how weak signals participate in Risk-Based Alerting without standalone pages for every traveler. Emailing the CIO for every rare-city VPN logon fails by concept because executive mail is not risk aggregation, creates alert fatigue, and bypasses Analyst Queue workflow. Expecting Security Posture to automatically page on every CIM field fails by concept because Posture is an overview dashboard of notables by domain and urgency, not a per-field pager, and CIM fields are schema—not pages. Expecting Protocol Intelligence to convert every VPN logon into a standalone notable fails by concept because Protocol Intelligence depends on protocol/Stream telemetry and is not the RBA writer for VPN identity risk. Exam caveat: SPLK-5001 links cheap civic indicators to risk-analysis AR rather than per-hit notables or executive email storms. Operational check: configure the VPN correlation search with risk-analysis AR and appropriate object type and score, verify contributing events appear on the user risk object, and reserve notable or page actions for aggregated or high-fidelity findings.