Your Roadmap to Success with Risk-Based Alerting

In our last RBA blog post, we introduced the Splunk RBA journey and how to plan for a successful implementation. In this post, we dive deeper into the four levels of this journey.

One of the things I've discovered in working with Splunk customers is that there is a big difference between an initial trial of RBA and using it effectively in a production environment. If we smoothly and steadily build out RBA and are able to show the value, it’s easier to get people onboard to help with developing and operationalizing an RBA implementation that best fits your production environment.

Something I like to make clear is that there is a decreasing amount of RBA-specific work as you progress through the different levels. It depends on how many resources you can dedicate to its development and the scope of your implementation makes a huge difference. Once the initial structure is in place with phase one, your engineers are confident with developing, tuning, and tweaking in phase two, then you’ve got process and response worked out in phase three, phase four becomes this open-ended maturation process which you can take any way you like!

Level 1: Quick Start

The first level of the RBA methodology eases you into using RBA with out-of-the-box Splunk Enterprise Security features. This level has two goals that set your team up for success: getting started with RBA using standard Splunk ES features, including the default Risk Incident Rules, and becoming familiar with how to monitor Risk Rules and Risk Incident Rules.

I've developed four sure-fire steps to help you through this level. First, you'll decide on your initial content strategy using a framework like MITRE ATT&CK, underleveraged security data sources, and low fidelity rules firing in your environment today. Next, you'll dive into actual RBA rule management by activating those two default rules in QA mode so that you can test them out and adjust them without affecting your production environment. As part of those adjustments, you'll learn how to enable risk factors to make Risk Rule scores even more valuable. And finally, you'll be monitoring the results and then tweaking everything to fit your unique security needs.

Level 2: RBA Development

As you dive into RBA development, it’s helpful to keep a mindset of try, learn, change, and move on. Not everything you try will show value right away, so be prepared to observe and study your Risk Index to learn about what is making a difference in your alert quality as you continue development.

At this point, you'll be taking the time to become familiar with the Risk Index and how to identify and remove noise, an important step that increases the fidelity of alerts. You'll also be applying variable risk, and working with Risk Notables to make them more useful. And because you're in development, you'll be doing all this in QA mode. 

Pro tip: If you can get analysts or other SOC team members involved at this level to start reviewing how you respond to alerts, you’ll be even better prepared for Level 3. 

Level 3: Operationalize RBA

This level is all about getting RBA ready to move into your production environment. There are three things to focus on in your preparation: testing and getting feedback from stakeholders, creating dashboards, and updating your response processes. If Level 2 is all about technical setups and modifications, Level 3 is all about the people and processes that will support RBA in production. 

I've found there are three major areas to focus on before you move out of development and get to that all-important Go Live day. First, you need to figure out a continuous testing and feedback process that involves everyone who will be affected by RBA once it moves into production. Second, this is the time to optimize investigation dashboards and response processes, looking at how to become more efficient given how much RBA can transform your detection and response actions. 

Different teams have different needs, so whatever metrics you can provide to help them reach their goals will ensure that RBA makes a positive impact in your organization. Additionally, giving operational teams the opportunity to test-drive what you’re building means you can implement changes from their feedback before they’re forced to utilize a new process which may not have had their ideal workflow in mind. 

You are also a customer of your own RBA development, so having dashboards with relevant metrics to guide your testing and implement your own feedback is just as important. You can definitely use the standard Risk Analysis dashboard, but Splunk also offers amazing customization capabilities, offering you the opportunity to make each step of the process – content development, analysis, and reporting – uniquely streamlined for your needs.

Level 4: On to Production!

Once you’ve operationalized RBA, you’re ready to move into your production environment. It’s now time for RBA to shine in the real world! And, even more exciting is how you will see the transformational power of RBA ripple through your security organization. 

Of course, moving RBA from development to production is not a decision made by a single person. You’ll need agreement from all of your stakeholders that RBA is truly ready for prime time: your SOC team, security analysts, red/blue teams, and so on. It may require more than a few meetings with the whole team to ensure everyone is on the same page and ready for rollout, but solid preparation will save everyone from a lot of frustration when RBA does move into production. 

Want to Know More?

Obviously every environment is different so what you’re trying to do with RBA is always unique to your situation. I've found that a lot of folks get stuck at some point in their RBA project and feel like it isn’t working as advertised. This is my worst nightmare, which is why I wrote The Essential Guide to Risk-Based Alerting to help you get started with RBA!

For a one-two punch with art of the possible and the steps you'll take to get there, watch Ted Skinner's and my RBA webinars.