Operationalizing Entity Risk Score with Enterprise Security 8.3+

[7thdrxn]

Overview

Enterprise Security 8.3 introduces a powerful new feature called “Entity Risk Scoring” (ERS) for detecting threats in a new way with Risk-Based Alerting (RBA). RBA is Splunk's method to aggregate low-fidelity security events as interesting observations tagged with security metadata to create high-fidelity, low-volume alerts. In practice, it takes time and effort to meaningfully curate the risk score of these events to reach the ideal state of high-fidelity and low-volume. Entity Risk Scoring was developed to translate those risk scores into something more immediately useful for analysis and investigation without significant curation.

What is Entity Risk Score?

First, let’s ensure we understand the basics of what ERS is built from. Detections can create direct alerts (findings) or store an observation that a potentially security-relevant event occurred (intermediate findings) with the intention that these are aggregated later to surface subtle or complex interconnected attacker behavior which can’t be determined from a single alert in isolation. By adding metadata like score and a relevant MITRE ATT&CK tactic and technique, we can look at an entity’s behavior over time and only create an alert when the aggregated metadata indicates this entity may be compromised.

Traditionally, the finding risk score indicates severity, and adding it together is still a useful approach when there is curation of score and a method for deduplicating similar events. However, because many of these events we monitor for potential risk are also indicative of benign activity, simply adding the scores together can result in an ever-increasing finding risk score sum. This can be more indicative of a detection needing tuning than an entity requiring analysis, which is why something like Entity Risk Score can be so valuable.

Entity Risk Score is an aggregate score for an entity based on the frequency, severity, and uniqueness of intermediate findings observed for that entity. ERS then weights these multiple factors for each event and combines them into a score bounded between 0 and 100. Thanks to the multiple calculations involved in the score, it is much easier to grasp the likelihood that an entity is a threat. In this article we will discuss how you might utilize this new feature to power your Detection & Response with RBA capabilities in less time than ever before.

What is the Difference between Finding Risk Score and Entity Risk Score?

Finding Risk Scores are the metadata attached to every event in the risk datamodel which are also attached to a specific risk object / entity, which can be calculated into a sum over any time period. The Entity Risk Score is this new aggregation method over the past seven days for an entity.

Difference in Editions

Entity Risk Scoring is available for all customers with Enterprise Security 8.3, however ES Premier has additional features that leverage ERS. As part of ES Premier, User Behavior Entity Analytics (UEBA) contains a suite of behavioral detections which detect anomalous behavior by an entity in comparison to its past behavior and its peer group, which is a valuable capability that automatically contributes to ERS. In addition, it contains a set of dashboards for investigating an entity with additional detail and insight.

How is Entity Risk Score Calculated?

The Entity Risk Score (ERS) is calculated over the past seven days and normalized to a range of 0 to 100 based on attributes of its events. It uses a scheduled search called Risk - EWA Entity Risk Score Calculation to calculate risk scores for all entities that have at least one risk modifier from the past 7 days. The search runs every 20 minutes by default.

The new ERS is a weighted average of the following components for events in the Risk Index:

• The sum of all calculated_risk_score values
• The maximum calculated_risk_score value
• The number of events with a calculated_risk_score ≥ 50
• The total count of events
• The sum of risk across different detections, utilizing the highest risk score from each detection

Where is Entity Risk Score?

In previous versions of ES, a simple additive score over the past 7 days was seen next to fields in Incident Review related to entities: orig_host, dvc, src, dest, src_user, and user. Now in ES8’s Analyst Queue, Side Panel, and within Investigations, the entity field – now part of Findings and Intermediate Findings – will display ERS when it is available. This score can be clicked on to interact with the Entity Risk Score workbench, which lists the contributing detections and breaks down what percentage of the score is related to the five metrics listed above.

The Entity Risk Score Workbench

This is what appears when you click on one of the ERS glyphs next to an applicable entity:

This gives you a picture of the events for that entity over the past seven days and how much each of them contributed to the final score. If using ES Premier, you’ll see the MITRE breakdown panel as well as the “Open in UEBA entity analysis” button in the top right to access that workflow.

Essential Building Blocks for Success with ERS

Ultimately, RBA is a journey. Even before you utilize it in production, you now have a place to put detection events if their volume is far beyond what would be feasible to respond to as alerts. For further guidance, please download my Splunk Guide to Risk-Based Alerting for step-by-step instructions to light your path. You can also join the RBA Community which has helpful apps, monthly office hours, and a Slack channel hosted by Outpost Security where you can ask questions of our helpful community anytime. I also recommend this great talk by Matt Snyder talking about how to plan your journey, and there are plenty more .conf talks listed in the RBA guide!

The Entity Risk Scoring framework is built with the Risk-Based Alerting methodology in mind, so we need to make sure that we have enough risk being created to generate valuable insights. Most content from Enterprise Security Content Updates is already configured to create risk, so if the vast majority of your enabled content is from there you will likely already have a thriving risk index. If not, you’ll need to configure your custom detections to create risk events.

In the Detection Editor, you’ll see a section specifically for risk information, including:

• Risk Message: a summary of what happened, can utilize $tokens$ from fields in the SPL output
• Entity Type: generally, user (identity) or system (asset)
• Entity: the field which contains the user/system
• Finding Risk Score: the severity of the event if/when observed. I recommend the Splunk Threat Research Team’s guidelines around Impact (severity) and Confidence (likelihood of true positive).
• Output: Select “Intermediate Finding”
• Threat Object: what our entity interacted with, like a file_name, process_name, ip_address, etc.

The incredible Splunker-developed app Detection Insights can provide all sorts of valuable information about your detections, and also has a tab specifically for risk so you can audit detections and ensure they are configured properly to feed into RBA.

Things to keep in mind:

RBA thrives on generating signal from noise, so having a diversity of scores and detections is important. If you make all scores the same, it’s going to be hard for any aggregation to properly surface what is a useful signal.  Remember, the ERS specifically weights events with a score above 50, so you want those higher scores to be meaningful.

When creating detections, run the SPL over the past month and see how many events it would generate so you can set the default risk score to a more valuable place. Generally, you would expect to have many low risk events with decreasing frequency as score increases. Once your searches are feeding into risk, if you run something like:

index=risk | stats count values(source) as sources by risk_score | sort - risk_score

You should see something close to that pattern. It doesn’t need to be exact, but if there’s a significantly higher number in your higher score ranges, you either need more detections that generate low severity events or tuning some of those detections’ scores down a bit will help make those higher scores meaningful.

How to Operationalize Entity Risk Scoring in ES Essentials

Every security operations program is going to have a unique way of responding to threats. We can likely leverage some of your existing process to respond to these threats, but first we need to decide on how we will use ERS:

• Purely for context when investigating your current alerts
• As an additional queue for threat hunting
• Integrated fully into the Analyst Queue as a direct alert

I will walk through these each in turn as they increase in complexity.

ERS Context with Alerts

When your detections are equipped with the entity field, now you will have the ERS glyph next to them in the analyst queue and side panels. 

We could pop out the side panel to review the details of the “Any Powershell DownloadFile” finding, but clicking on the ERS glyph will present the panel that lets us see other contributing detections over the past seven days for this entity:

As well as Asset & Identity information in the entity details tab:

Additionally, we could add a Workflow Action to the entity + normalized_risk_object fields that leads to the Risk Analysis dashboard so we could investigate individual pieces or pop out the risk event timeline. Try this:

The tokenized URI here you can duplicate is:

/app/SplunkEnterpriseSecuritySuite/risk_analysis?tab=tab0&form.risk_object_raw=$normalized_risk_object$&form.risk_object_type_raw=*&form.risk_object=risk_object%3D"$normalized_risk_object$"&form.risk_object_dm=All_Risk.risk_object%3D"$normalized_risk_object$"&form.risk_object_type=risk_object_type%3D"*"&form.risk_object_type_dm=All_Risk.risk_object_type%3D"*"&form.index=Risk&form.source=*&form.global_time.earliest=-7d%40h&form.global_time.latest=now

Now when we click on the entity dropdown we can dive in further:

ERS Threat Hunting

Now that this capability exists, I’m excited to see what customers end up building on top of it. To give you an idea of how you could explore this data, I made a (relatively) simple dashboard for browsing the ERS lookup:

Now when I click on one of those entities, I have it look in the asset and identity lookups to display information about the object, as well as store all of its possible asset or identity names so we can find all connected findings later. Then I made a timeline of all detections with their risk messages and threat objects in an easy to read list:

Finally, using the various asset or identity names this entity also utilizes, I list all of the connected findings in the past seven days:

And each one can be clicked on to find that specific finding in the Analyst Queue. That’s just the initial skeleton of something I might build out on top of Entity Risk Score for hunting purposes, if you build something you’d like to share, definitely reach out and let me know.

ERS Alerts

You might also want to create some sort of alert pipeline for when entity risk scores reach a certain amount. It is likely that these entities have already alerted through findings or with RBA aggregation, but if you haven’t set up Risk Incident Rules or Finding Based Detections for surfacing risk events, then this might be a great way to get started with that.

With this query, the general idea is that I’m checking the ERS for values above fifty, then double-checking for previous findings from this same search so we don’t constantly alert for every entity exceeding that threshold. This allows a few different cases where it will alert:

• The entity hasn’t alerted before
• The ERS has increased by at least 10 since the last finding created by this search
• The latest ERS entry for this entity has new detection sources

index=ers source=ers_history ers>50 | dedup normalized_risk_object risk_object_type sortby -_time
| eval detections = split(detections,"- Rule ") , detections = mvfilter(NOT match(detections,"- Rule"))
| stats count max(ers) as ers values(detections) as detections by _time normalized_risk_object risk_object_type
| eval detections_hash = md5(mvjoin(rtrim(detections),""))
| sort - normalized_risk_object risk_object_type _time
| join type=left normalized_risk_object risk_object_type [
search index=notable source="*Entity Risk Score Exceeds 50*" earliest=-7d | dedup normalized_risk_object risk_object_type sortby -_time | fields normalized_risk_object risk_object_type detections ers | rename ers AS ers_old | eval detections_old = md5(mvjoin(rtrim(detections),"")) | fields - detections]
| eval ers_alert_check = if(isnull(ers_old) OR ers > ers_old+10 OR detections_hash!=detections_old,"yes","no")
| fields - detections_hash detections_old
| where ers_alert_check="yes"

If you come up with another novel way for utilizing Entity Risk Score for alerting, I would love to hear about it.

Additional UEBA Capabilities with ES Premier

UEBA has its own set of features and detections, but there is some overlap with the Entity Risk Score I wanted to touch on here. Firstly, you’ll have this overview dashboard for investigating top riskiest users or assets:

You’ll see that you can create entity lists to narrow down your scope to specific subsets of assets or users, as well. Then, when you click into any of these entities you can dive one layer deeper:

You can see the progression of the entity risk score over time, as well as an annotation when an investigation was created. You get the entity info on the right, and below you can explore the connected assets that fired in conjunction with the user entity.

Further down, we see a similar panel to the one on the Entity Risk Score workbench, however we can click the “view contributing risk” target icon to see a breakdown of events from that detection:

The next icon allows an analyst to add a “finding exclusion rule” to tune this detection and the Entity Risk Score going forward:

Conclusion

As you can see, Entity Risk Score is a useful feature you can utilize to either start or augment your Risk-Based Alerting journey within Splunk Enterprise Security. The power of alerting on aggregated observations can help discover subtle attacker behavior as well as offloading high-volume, low-fidelity alerts into a system that can surface those potentially useful observations when there’s enough of them to warrant an actual investigation. Most people don’t believe the percentage volume reduction I had as a customer, and I’m happy to help people achieve those results for themselves.

Please join us in the RBA Community if you’d like to ask questions, learn more, or contribute! I’d love to see some additions to the Github that add additional features or leverage Entity Risk Score in unique ways.