How risk-based alerting works in Splunk Enterprise Security

With risk-based alerting (RBA), analysts receive risk notables from risk incident rules, which surface from multiple risk events. RBA uses the existing Splunk Enterprise Security correlation search framework to collect all risk events into a single risk index. Events collected in the risk index create a single risk notable when they meet a specific criterion, which warrants an investigation.

For example, suppose a single system creates five risk events from several risk rules. Each of these risk events have a low risk score. However, when taken together these risk event surpass the risk score threshold, pertain to specific MITRE ATT&CK techniques, and are associated with unique data sources over multiple time frames. RBA can pick up on this threat even when the system generates only a single risk notable because it performs correlated alerting that tells a high-fidelity security story, which analysts can investigate.

Similarly, RBA effectively helps to detect complex behavior over a "period of time" instead of "point in time" alerting.

For example: an impatient hacker might try various techniques to attack a single server over a period of time. RBA uses a variety of alerting criteria over a varying duration of time to provide insight into your environment, which helps to tune risk incident rules to your environment in addition to threat hunting.

Therefore, you can review the following alerts, which use different factors and time duration to detect threat:

• Score threshold 100 exceeded over 24 hours: This alert uses combined scores of events to trigger an alert.
• Events from multiple sourcetypes over 3 days: This alert uses three unique data sources that generate events from a single machine.
• Multiple MITRE ATT&CK tactics observed over 7 days: This alert uses observations tagged with MITRE ATT&CK tactics and techniques.

The following list illustrates the steps of how RBA works in Splunk Enterprise Security:

• Step 1: Risk rules detect anomalies and assign risk scores to events: A risk rule is a narrowly defined correlation search that runs against raw events and indicate potentially malicious activity. A risk rule contains the following three components:

• Search logic using the Search Processing Language (SPL)
• Risk annotations
• Risk analysis adaptive response action to generate risk events.

All risk events are written to the risk index. Following are some examples of risk rules

• RR - Traffic to Non-standard Port
• RR - Threat Intel Match
• RR - Suspicious Logon Type

The risk rules observe anomalies and log search results or risk events to the risk index. Splunk Enterprise Security uses the Risk Framework to dynamically calculate a risk score for each event using risk modifiers. Splunk Enterprise Security also associates the event with specific assets and identities such as users or systems.

• Step 2: Risk incident rules review the events in the risk index and use an aggregation of events impacting a single risk object to generate risk notables: Risk incident rules review the risk index for anomalous events and threat activities. When the risk incident rules find a risk object associated with several risk events, the risk incident rules create risk notables in Splunk Enterprise Security. When the risk scores associated with the risk notables surpass a specified threshold over a period of time, analysts focus their efforts on connected behaviors associated with the risk notable. The aggregated risk score of an asset or identity is the sum of all the risk scores for risk events in the risk index that apply to the specific asset or identity over a period of time.

For example, a risk notable might be created when the risk incident rule detects a single machine that generates 5 risk events from various risk rules. These events can be combined to cross a threshold of the following factors:

• Risk score
• MITRE ATT&CK techniques,
• Unique data sources over various time frames

• Step 3: Risk factors trigger risk events in the risk index: Analysts can also define risk factors that add or multiply risk scores associated with assets and identities such as users or systems when suspicious behavior occurs. For example, an analyst might want to multiply risk scores by 1.5 for a privileged user, who is also an administrator. Instead of triggering a notable that populates the Incident Review page, risk factors trigger a risk event in the risk index.

• Step 4: Context rich risk notables help to triage and neutralize threat: Analysts can also add relevant context to risk attributions by mapping them against a relevant cybersecurity framework or applying a risk score to the notable. You can associate risk notables with conditions such as MITRE ATT&CK tactics or techniques. MITRE ATT&CK tactics are categories of activities such as Privilege Escalation or Command and Control, while MITRE ATT&CK techniques are specific activities such as Kerberoasting or Protocol Tunneling. Using Splunk Security Essentials or Enterprise Security Content Updates, you can identify the techniques covered by your data sources and build a breadth of detections across every tactic. Splunk Enterprise Security also supports NIST, CIS, Critical Security Controls, and the Lockheed Martin Cyber Kill Chain frameworks. When an asset or identity's risk score or behavioral pattern meets a predetermined threshold, it triggers a notable event or alert, which provides analysts with valuable context at the onset of their investigation process and expedite the neutralization of threats.

Use the following diagram to identify the high-level steps to configure RBA. You might have to customize RBA based on the specific requirements of your security operations center (SOC):

How risk-based alerting differs in Splunk Enterprise Security version 6.4.x and higher

Prior to version 6.4.x, many SOC analysts used correlation searches to create custom macros and generated risk events that helped them streamline investigations. However, creating these macros required an extensive knowledge of SPL.

With Splunk Enterprise Security version 6.4.x and higher, you can configure RBA to use the default risk incident rules with mapped, customizable security frameworks without using complex SPL. RBA automatically enriches data through content updates and highlights the relationships between multiple threat objects and risk objects to offer a unified view of the SOC. Additionally, analysts can identify threats from raw data using investigative dashboards.

See also

For more information about how best to use RBA in your security environment, see the product documentation.

How urgency is assigned to notable events in Splunk Enterprise Security

Asset/Identity Categories.

Managing risk using risk based alerting in Splunk Enterprise Security

Create risk notables in Splunk Enterprise Security

Create risk factors in Splunk Enterprise Security