Take Your Breath Away with Splunk Risk-Based Alerting (RBA)

[WhitneySink]

The Splunk Guide to Risk-Based Alerting is here to empower your SOC like never before. Join Haylee Mills, Security Strategist at Splunk, as she walks through the new and improved Splunk Guide to RBA!

Join this Tech Talk to learn the power of RBA, such as how to:

• Reduce the number of overall alerts while increasing the fidelity of alerts that arise
• Define and produce internal threat intelligence to identify normal or anomalous behavior
• Create high-value detections from traditionally noisy data sources, which align to popular cybersecurity frameworks
• Develop a valuable risk library of metadata-enriched objects and behaviors for manual analysis or machine learning

Watch full Tech Talk here:

[WhitneySink]

We wanted to provide you with the link to Haylee's demo:

Risk Based Alerting: The New Frontier for SIEM

[WhitneySink]

As you continue on your journey, please find other valuable resources here:

Risk Based Alerting Feature Brief

The Essential Guide to Risk Based Alerting

2024 Gartner® Magic Quadrant™ for SIEM

Introducing the SIEM of the Future

[WhitneySink]

Please find the Questions and Answers from our session below:

Q: What are the steps I would take to implement RBA?

A: This is all clearly laid out in the Splunk Guide for RBA!

---

Q: Any advice on best approach in implementing a multi-tenant RBA framework?

A: 

Multi-tenancy is always complex, and I'm not sure what aspects of it your particular organization is dealing with because sometimes the solution is a bit different.

1) If you don't have to worry about separating out the data in the risk index for individual tenants so they can't see another tenant's data, FANTASTIC. This is just a matter of planning to keep data separate with something simple like a tag or even just | eval tenant="tenant_a" on the searches for that tenant, | eval tenant="tenant_b" for others and so on. Then if you add that to your risk DM, you can just tell your relevant RIRs for that tenant to look for that field.

2) If you only have to worry about *masking* the data, this is a bit easier than the final method. One thing I've seen a customer do is basically eval risk_object=md5(risk_object) so it's converted to a hash when stored in the risk DM that everyone needs access to. That way things will still be aggregated to the correct object, and then each tenant can keep a hash translation in an index only they have access to, and then they can correctly search their own data for drilldowns and so on.

3) If you do have to separate access to information, then you'll likely be able to leverage the macro-based version of RBA that a lot of used to use in the day. This basically leverages the | collect command to bring events into the risk index, but in your case you will be collecting to different indexes with their own RBAC. You can see the various evals basically doing the equivalent of risk factors, but if you craft your own macro properly and include all the fields that are generally expected when utilizing the risk ARA, it will work fine when plugged into the risk DM. For example, this will generate the MITRE annotations based on a MITRE technique field that has each technique in a newline (it gets made into MV, then split out, then JSON'd):

| rex mode=sed field=mitre_technique "s/\n/,/g"
| eval annotations.mitre_attack = split(mitre_technique,",")
| eval annotations.frameworks="mitre_attack" , annotations._all='annotations.mitre_attack'
| makejson annotations.mitre_attack output=annotations
| fields - mitre_technique

If you have further questions, it would be worth asking around on the RBA Community Slack. Multiple people are utilizing either | collect or | sendalert for various reasons.

---

Q: Why does the risk normalization object us a "mvindex" approach instead of allowing users to more customize which field value is used?

A: 

The field used for a risk object should not be MV: the risk ARA creates a risk event for each defined risk object for ease of use querying the risk index without the overlap of additional objects (this can become annoying with accounts like SYSTEM). To maintain the connection with additional objects, I suggest adding something like related_risk_object to the risk DM, with something like:

if(risk_object_type="system",user,src)

Or something more complex with a case statement if you'd like to keep that stored in the risk abstraction layer.

---

Q: first alert is generated when user collects 100 points. We confirm it as False Positive. Then alert is generated every time user receives any additional points, for ex. %2B2pts., %2B5pts, generating lots of annoying alerts. How to solve it?

A: 

There are a few methods:

1) The truth table method on the Github - this creates a truth table of looking at previous notables, their closed status, and the new rules or score that has fired, so you can decide when it would create a new alert and when it would not. The second method will help with additional notables that appear on the back end of the dynamic window but not what you asked about in this question.

2) You could do something similar on a saved search that creates a lookup by looking at notables, their closed status, and based on the status, giving some sort of flag to the risk rules inside. Something like:

`notable` | search eventtype=risk_notables | stats count by normalized_risk_object,risk_message,source | eval remove_risk=case(status="False Positive","true",status="Benign Positive","true",true(),null() | where remove_risk="true" | outputlookup remove_risk.csv

Then in your Risk Incident Rules, you may have to juggle some stats commands (and break out source, risk message, and risk_object like I have in this example), but basically looking to insert:

| lookup remove_risk.csv normalized_risk_object risk_message source OUTPUT remove_risk
| eval risk_score = if(isnotnull(remove_risk),"0",risk_score)

And then re-do your stats to aggregate the score like in the base search of the RIR. This will zero out the score of rules that have been marked as "False Positive" in the notable index for that risk object.

3) Lastly, I know some people use SOAR to create negative risk events in the risk index for that object, but you could also mimic the behavior of the "Ad-Hoc Risk Score" button in the Risk Analysis dashboard (or just use it outright). Basically you're just using the | collect command to store a new event in the risk index that has negative score. You could have analysts just use this button and insert a negative risk score, but it is an extra step and having things automated can be really nice.

---

Q: How would you implement RBA in a cloud environment where multiple assets may share the same ip across multiple accounts?

A: 

I *assume* in this question that multiple assets sharing the same IP means they are on separate private IP spaces, and that's where we would want to be using CIM entity zones. Potentially you could create a macro with logic to reuse in your risk rules that determines zone by naming convention in src/dest/user fields, or maybe a saved search that generates a lookup to check against (which is basically just CIM entity zones from A&I, so if you can get that to work, do that!).

And that's why ideally we want risk_object to be both user and system in every log source possible. The holy grail of A&I is getting system, IP, and user interlinked (which something like Splunk Asset Risk Intelligence really helps with), so if you don't have one or the other available in a log source your detections are on, you can enrich it to do so. It isn't entirely necessary either so don't let that stop you; the more coverage you build out on what you do have the better, and when you *can* interlink things, your cross coverage will improve.

---

Q: Reduces analysts chasing the same ghost when implemented. Saw same reduction but more importantly, the overlapping work dropped and the hunting began a primary part of the soc rather than just alerts.

A: I'm glad you called this out as another potential benefit of RBA. Yes, when everything investigated is not just a single event but connected events, you naturally remove some of that overlapping redundant work and analysis. And yes, then you have more time for really high-value security stuff like maturation of technology/operations and threat hunting! Plus you have the risk index for threat hunting which is fantastic.

---

Q: do we see any impacts to existing RBA risk rules and risk incident rules when ES is upgraded to 8.0?

A: 

Everything should just work when ported over to ES8, however there are a few things to be aware of:

All EBDs require a risk_object + risk_score when saving for the first time in ES8. Any notable (finding EBD) you save from now on, just set the risk score to zero.
For your traditional RRs, analyst queue (previously notable ARA) stuff is mostly irrelevant, you can however define a drilldown which is nice.
For your traditional RIRs, be aware if you're searching tstats, the risk DM now has notables in it. This can be great context to surface with your risk notables/findings.

---

Q: You mentioned an app to check for RBA readiness. What was the name of that?

A: I specifically mentioned the RBA Navigator app by Matt Snyder, which he talks about at conf here. Also highly recommend Splunk App for Detection Insights in parallel, which does have some RBA related audit checks as well as many other useful features for ES.

---

Q: The RBA example culminating in a user putting in a 2wk notice -- is there a notable for a 2wk notice?! Not important, just curious lol

A: That's a hard one to design something OOTB that works for everyone; should be relatively easy to create a detection for this as long as you have the relevant data. If you're able to get that in Splunk, definitely a worthwhile event for RBA; generally I would veer away from notables for something like this that can happen frequently and you don't need to investigate every time it happens.

---

Q: I missed how we get the Slack invite. Could someone send me that?

A: https://rba.community has the link to the Slack invite request!