rss.livelink.thread@place:occasion

Security: Risk-Based Alerting (RBA) - 11/08/23

adepp — Sat, 11 Nov 2023 16:02:00 GMT

Register here. This thread is for the Community Office Hours session on Splunk Enterprise Security: RBA on Wed, November 8, 2023 at 1pm PT / 4pm ET.

This is your opportunity to ask questions related to your specific challenge or use case using Splunk Enterprise Security Risk-Based Alerting. Including:

Implementing RBA in Splunk Enterprise Security
Best practices for proper creation of risk rules, modifiers, etc.
Troubleshooting and optimizing your environment for successful implementation
Anything else you’d like to learn!

Please submit your questions at registration or as comments below. You can also head to the #office-hours user Slack channel to ask questions (request access here).

Pre-submitted questions will be prioritized. After that, we will go in order of the questions posted below, then will open the floor up to live Q&A with meeting participants. If there’s a quick answer available, we’ll post as a direct reply.

Look forward to connecting!

Re: Security: Risk-Based Alerting (RBA) - 11/08/23

adepp — Sat, 11 Nov 2023 16:00:42 GMT

Here are a few questions from the session (get the full Q&A deck and live recording in the #office-hours Slack channel):

Q1: What’s the best way to manage risk scores?

Navigate to https://research.splunk.com/ and check out the detections under the detections tab.
Scroll down to the section called “RBA,” where you’ll see a risk score that comes along with each of the detections. It uses the formula:

Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

You can also add risk factors (multipliers & modifiers) to make risk scores more dynamic. For example “if this account is a service account, or if this user is a privileged user, then multiply by 2”

Q2: Does Splunk have best practices for setting and adjusting risk scores as our implementation improves?

Best practice at the start is to just pick a risk score and stay consistent with it for a while until you have had some time to curate the risk in your environment, and see if rules excessively add risk or not, make adjustments and tune your rules as needed to insure excessive risk isn’t being added.
With that said, the default risk score threshold of 100 for alerts and each triggered rule adjusting risk by adding 1 to the score each time works just fine. You may have to adjust risk factors and tune rules to keep things reasonable.
I think the main guidance is to not constantly adjust your risk scoring on a frequent basis. If you need to adjust it for your environment, make your adjustment, then let it bake for a little while and see how it reflects in your environment.

Q3: When working with ES's Assets & Identities with RBA, how would you handle things such as the SYSTEM account, or 'Unknown' from TA's not mapping properly, so that RBA wouldn't trigger on it?

For unknown field contents, you need to address the data onboarding for the relevant datasource.
When onboarding data for use in ES, it needs to be CIM compliant (if applicable, which means that it maps to one of the CIM data models), all fields required need to be extracted correctly to rid yourself of the “unknowns”
Dashboard requirements matrix for Splunk Enterprise Security

Re: Security: Risk-Based Alerting (RBA) - 11/08/23

adepp — Sat, 11 Nov 2023 16:01:28 GMT

Here are some other questions from the session (check the #office-hours Slack channel for responses):

Are there plans to integrate into ES the ability so when a notable is closed as a false positive (by disposition), to be able to automatically lower the risk score of the associated objects to remove the risk modifier from the correlation search in question?
Where do people start with scoring their risk...is it really as "eyballing it" as I think? E.g. Let's just start with a risk of 100, and something I think is more risk I make 150 or 200, and something less risk is 50.
Is it Splunk's expectation/best practice to only triage RBA notables and only close/resolve those and to ignore *from a workflow resolution standpoint) non-RBA notables?