Skip to main content
Lantern Home
 
 
Splunk Lantern

Prescriptive Adoption Motion - Risk-based alerting

  1. Last updated
  2. Save as PDF

 

Risk-based alerting (RBA) provides teams with a unique opportunity to pivot resources from traditionally reactive functions to proactive functions in the SOC. As alert fidelity and true positive rates increase, analysts’ resources can be shifted to higher-impact tasks like threat hunting or adversary simulation, empowering SOCs to build up the skill sets of their analysts and prepare them for any threats they might encounter.

The RBA methodology is very similar to what you are likely already doing in Splunk Enterprise Security.  It uses nearly all of the existing frameworks within Splunk Enterprise Security but includes a few optimizations that dramatically increase efficiencies and general security maturity within the SOC.

The benefits of RBA include:

  • A dramatic reduction in overall alert volume (alert fatigue)
  • Improved detections
  • Alignment with popular frameworks such as MITRE ATT&CK
  • More detections and data sources without scaling up SOC operational costs
  • Increased detection time ranges 
  • A more streamlined deployment process

Aim and strategy

Splunk customers who implement RBA typically see a dramatic reduction in overall alert volume. This relieves pressure on security operations teams while also providing better insight into real threats. It reduces the low priority alerts often associated with false positives and noise.

Common use cases

  • Reducing overall alert volume
  • Increasing alert fidelity
  • Increasing coverage of MITRE ATT&CK and other frameworks
  • Reducing alert noise or low-level alerts
  • Maturing your proactive approach to security

User roles

Role Responsibilities
Lead Security Analyst Defining security use cases and analyst workflows, content development strategy
Splunk Admin / Splunk Enterprise Security Admin Configuration changes, app installs, index creation, permissions changes
Information Security Management Approving changes and providing project sponsorship

Preparation

1. Prerequisites

1.1 Comprehensive asset & identity information

Having a comprehensive set of asset and identity information for all your user and device objects is a key component for RBA success. When that information is available, you can use risk factors based on contextual asset or identity data. Splunk Enterprise Security uses correlation searches to connect machine data with asset and identity data; RBA takes it to the next level by using those risk factors and customized risk scores to produce higher-fidelity alerts. For more information, see Add asset and identity data to Splunk Enterprise Security.

1.2 CIM-compliant data

Splunk organizes your data into a relevant schema through the Splunk Common Information Model (CIM). Then, it defines a data model to take relevant data from multiple sources - such as Windows, Cloud, and VPN logs for the Authentication data model - and makes sure that they all use the same fields, such as src, user, and action, when looking at events.

1.3 Leadership buy-in

It is highly recommended you develop buy-in at multiple levels before you begin your RBA implementation. It may take some effort to convince leadership that the time invested into building RBA enables them to meet or surpass many of their key security or resilience goals, but having them on board will make all the difference.

1.4 Documented goals and outcomes

Select one or two goals at first and focus on those, along with creating metrics or means to measure success. For each goal you set, plan the actions or detailed steps needed to get the work done, measure progress, and assign owners to each action. After you kick off the project plan, make sure you track progress, give regular status updates to stakeholders, and work through any roadblocks you may hit.

2. Recommended training

4. Considerations

4.1 Initial increase in alert volume

When you first implement RBA, it can actually increase the number of alerts you receive. This is temporary while you begin to tune your alerts and improve.

4.2 Time commitment

It is important to commit the time necessary to tune your alerts in order to realize success in RBA. Some of the most successful RBA implementations are run as an internal project with a formal project plan and buy-in from leadership. If you commit to the long-term goal of continuous work and tuning, the results will pay off.

Implementation guide

1. Step-by-step guidance

Splunk has developed a powerful methodology to kickstart your RBA implementation. From first moves to production, these four levels take you step-by-step through the process of successfully getting RBA up and running.

The essential guide to Risk-Based Alerting is a comprehensive step-by-step guide that will walk you through implementing RBA from start to finish.

rba-levels.png

  • Level 1 is all about getting familiar with how RBA works in your environment. It uses the defaults in Splunk Enterprise Security to start with, and then monitors and tunes those rules to produce higher-fidelity alerts. 
  • Level 2 is the classic development phase of any software-based project. You’ll take what you learned in Level 1 to monitor and modify your existing rules to produce higher-fidelity risk notables. 
  • Level 3 prepares your RBA implementation for production by setting up useful dashboards and modifying your existing case management processes to be more effective with RBA. In short, this level is all about getting RBA polished for real-world use. 
  • Level 4 is the top of the mountain, time to go-live. Your team puts RBA into production and carefully monitors activity and results, fine-tuning rules and processes as needed.

2. Adding automation with Splunk SOAR

Watch Augmented case management with risk based analytics and Splunk SOAR to hear Phil Royer and Kelby Shelton explain the risk notable SOAR content pack and how to deliver enrichment to risk notables. Then, read Get started with the risk notable playbook pack for Splunk SOAR.

Success measurement

Typically, RBA users see anywhere from a 50% to 90% reduction in alerts, with the remaining alerts being higher fidelity and easier to investigate. When implementing this guidance, you should see improvements in the following:

  • Percent of enabled searches using MITRE ATT&CK annotations
  • Percent of enabled searches using other framework annotations
  • Percent of searches that are risk rules
  • Risk factors enabled
  • Risk factor usage
  • Risk index usage
  • Risk notables being created
  • Risk notable count
  • Reduction in notables by using the attribution based approach
  • Reduction in traditional notables versus risk notables