Isolate threats using risk-based alerting

Buttercup Games, a fictitious company, runs an e-commerce site to sell its products. Kay, the manager of the security operations center (SOC) at Buttercup Games, receives numerous notables during the course of a morning indicating various suspicious behaviors over a specific time period that might be a risk to their organization.

Without risk-based alerting

Prior to using risk-based alerting (RBA), Kay requested Ram, a security analyst on their team, to use Splunk Enterprise Security to run correlation searches on all assets and identities to generate security events and create notables or risk alerts. As is typical of other security information and event management (SIEM) environments, the correlation searches generated an excessive amount of notables, over 10,000 alerts each day. The sheer volume of alerts caused Ram to overlook mission critical alerts because manually parsing through thousands of notables to identify patterns caused exhaustion and burnout.

Additionally, Ram was not able to see notables in context because separate alerts got assigned to other security analysts at different points in time. Each analyst saw only a single event in a string of activities and dismissed the notable. None of the analysts had the full context of the notable and were receiving too many low-level alerts, which caused them to miss the bigger picture. This method of threat detection was neither efficient nor effective for Buttercup Games because high-fidelity notables were often suppressed or abandoned and were not incorporated into the investigative story, which created visibility gaps.

With risk-based alerting

Now, Kay asks Ram to use the risk alerting framework in Splunk Enterprise Security to dynamically adjust risk scores for assets and identities based on specific conditions. With RBA, threat detection focuses on multiple parameters such as security metadata or alert source, ATT&CK technique, and risk score. Risk scores are dynamically modified based on the attributes of the risk object, such as a privileged user, or an external server. Ram receives alerts only after reaching a certain risk threshold that correlates to the same object.

Dynamically adjusting risk scores allows Ram to automatically raise the risk scores associated with specific assets and identities by assigning these conditions as risk factors. Assigning risk factors helps to expose notables for investigation. Therefore, Ram can prioritize suspicious behavior and mitigate risk by taking quick action on the risk event.

The risk alerting framework in Splunk Enterprise Security allows Kay and Ram to conduct higher value investigations through more streamlined and effective threat isolation. Ram leverages the risk alerting framework to explore the high volume and noisy endpoint data that Kay asked him to investigate.

The following figure shows an example of how a single risk notable created by a risk incident rule uses multiple events, which do not trigger individual alerts.

This scenario describes how Kay, a SOC manager, and Ram, a security analyst, use risk scores and risk factoring to classify the notables based on risk level and map out the risk in their security environment by taking these steps.

1. Assign risk scores to assets and identities
2. Generate notables using correlation searches
3. Add annotations to enrich correlation search results
4. Classify risk objects based on annotations
5. Add a risk message and a risk score to a notable
6. Adjust risk scores for specific objects

See also

For more information on how risk-based alerting works in Splunk Enterprise Security, see the product documentation:

How risk-based alerting works in Splunk Enterprise Security