Analyze risk in Splunk Enterprise Security

A risk score is a single metric that shows the relative risk of a device or user in the network environment over time. Splunk Enterprise Security classifies a device as a system, a user as a user, and unrecognized devices or users as other.

Enterprise Security uses risk analysis to take note of and calculate the risk of small events and suspicious behavior over time to your environment. The Risk Analysis dashboard displays these risk scores and other risk-related information. Enterprise Security indexes all risk as events in the risk index.

How Splunk Enterprise Security assigns risk scores

A risk score is a single metric that shows the relative risk of a device or user object in the network environment over time. An object represents a system, a user, or an unspecified other.

Enterprise Security uses correlation searches to correlate machine data with asset and identity data, which comprises the devices and user objects in a network environment. Correlation searches search for a conditional match to a question. When a match is found, an alert is generated as a notable event, a risk modifier, or both.

• A notable event becomes a task. It is an event that must be assigned, reviewed, and closed.
• A risk modifier becomes a number. It is an event that will add to the risk score of a device or user object.

Risk scoring example

Host 192.0.2.2 is a system that is generating several notable events. The correlation search for Personally Identifiable Information Detected is creating five notable events per day for that system.

Using the Risk Analysis dashboard to view the risk for this host shows a risk score of 480.0 in the Risk Score by Object and Most Active Sources panels for the last seven days by default.

Risk Score by Object
risk_object	risk_object_type	risk_score	source_count	count
192.0.2.2	system	480.0	1	6

Most Active Sources
source	risk_score	risk_objects	count
Audit - Personally Identifiable Information Detection - Rule	480.0	1	6

Perhaps 192.0.2.2 is a test server, so this behavior is less interesting than if the same behavior is observed in the production environment. Rather than ignoring or suppressing notable events generated by test servers, you can create specific rules to monitor those servers differently.

You can do this by creating a correlation search that assigns a risk modifier instead of creating a notable event, when the correlation matches hosts that serve as test servers.

1. Isolate test servers from the existing correlation searches using a whitelist. See Whitelist events in Administer Splunk Enterprise Security for more information.
2. Create and schedule a new correlation search based on Personally Identifiable Information Detected, but isolate the search to the test server hosts and assign a risk modifier alert type only.
3. Verify the risk modifiers are applied to the test server hosts by raising their risk score incrementally. With the new correlation search, no notable events will be created for those hosts based on personally identifiable information.

As the relative risk score goes up, 192.0.2.2 can be compared to similar test servers. If the relative risk score for 192.0.2.2 exceeds its peers, that host would be investigated by an analyst. If the risk scores of some similar test servers are higher relative to others, an internal security policy may need to be reviewed or implemented differently. See the Risk Analysis With Enterprise Security 3.1 blog post for additional examples.

It is also worth noting that risk modifiers cannot be suppressed in the same manner as notable events. Instead, the following options are available:

Correlation Search Aggregation

You can aggregate multiple firings of a correlation search based on fields and duration via savedsearches.conf in the alert.suppress settings. See Savedsearchesconf.

Correlation Search Modification

To prevent further false positives, you can edit the correlation search syntax to filter events or results.

Assign risk to an object

Create a risk analysis response action, or risk modifier, to assign risk to an object. You can assign risk to objects in several ways.

• Assign risk automatically as part of a correlation search. See Modify a risk score with a risk modifier in Administer Splunk Enterprise Security.
• Assign risk on as an ad hoc adaptive response action from Incident Review. See Modify a risk score with a risk modifier in this manual.
• Create an ad hoc risk entry from the Risk Analyis dashboard. See Create an ad hoc risk entry in Splunk Enterprise Security in this manual.
• Assign risk through a search. See Assign risk through a search.

Assign risk through a search

You can assign risk using search rather than an alert. You can do this to modify risk on multiple risk objects, or to alter the risk score of an object based on the results of a search.

Use these search examples to assign risk to a user, system, or other risk object in a custom correlation search. To assign risk to just one field, or on an ad hoc basis, use the risk adaptive response action instead.

Each example uses ... to indicate a search that includes the field to which you want to assign risk in the results.

Assign risk with the appendpipe command

Use appendpipe to add risk to multiple objects. Replace <your_risk_score_integer> with the risk score that you want to apply to the fields.

... | eval risk_score=<your_risk_score_integer> | eval risk_object=if(isnotnull(dest),dest,null()),risk_object_type=if(isnotnull(dest),"system",null()) | appendpipe [| eval risk_object=if(isnotnull(user),user,null()),risk_object_type=if(isnotnull(user),"user",null())] | sendalert risk param._risk_score=<your_risk_score_integer>

For example, run this search to assign a risk score of 15 to mysystem and myuser.

| makeresults | eval dest="mysystem", user="myuser" | eval risk_object=if(isnotnull(dest),dest,null()),risk_object_type=if(isnotnull(dest),"system",null()) | appendpipe [| eval risk_object=if(isnotnull(user),user,null()),risk_object_type=if(isnotnull(user),"user",null())] | sendalert risk param._risk_score=15

Assign risk with sendalert

You can use sendalert without appendpipe to assign risk directly to field values, without performing conditional evaluations of the field values.

... | sendalert risk param._risk_object_type="system" param._risk_score=<your_risk_score_integer> | eval risk_object=user | sendalert risk param._risk_object_type="user" param._risk_score=<your_risk_score_integer>

For example:

| makeresults | eval dest="mysystem", user="myuser" | sendalert risk param._risk_object="dest" param._risk_object_type="system" param._risk_score=15 | sendalert risk param._risk_object="user" param._risk_object_type="user" param._risk_score=20

Compute and assign a risk score

You can also set a risk score based on a calculation performed in the search, rather than setting it to a static integer.

For example, if you want to set a higher risk score for users that log into multiple infected assets, write a search that collects the users that logged in to infected assets, then does a count of the users in the results, split by user so that you see how many login attempts there are by each user.

... | stats count by user | eval risk_score=(count*2) | sendalert risk param._risk_object="user" param._risk_object_type="user" param._risk_score="risk_score"

For example, the Threat Activity Detected correlation search uses search-assigned risk in addition to an alert-type risk modifier. When the search finds an asset or identity communicating with a host that matches a configured threat list, the search modifies the risk score accordingly. In this case, the risk modifier reflects the number of times the system or user communicated with the threat list, multiplied by the weight of the threat list. As a formula, risk score of a system or user + (threat list weight x event count) = additional risk.

... | eval risk_score=case(isnum(record_weight), record_weight, isnum(weight), weight, 1=1, null()) | fields - *time | eval risk_object_type=case(threat_match_field="query" OR threat_match_field=="src" OR threat_match_field=="dest","system",threat_match_field=="src_user" OR threat_match_field=="user","user",1=1,"other") | eval risk_object=threat_match_value

See the risk score in search

See the changes that you made by searching the data model or the risk correlation lookups:

| from datamodel:Risk.All_Risk | search (risk_object=myuser OR risk_object=mysystem)

or

| makeresults | eval dest="mysystem" | `risk_correlation`

Score ranges for risk

Risk scoring offers a way to capture and aggregate the activities of an asset or identity into a single metric using risk modifiers.

The correlation searches included in Enterprise Security assign a risk score between 20 and 100 depending on the relative severity of the activity found in the correlation search. The searches scope the default scores to a practical range. This range does not represent an industry standard. Enterprise Security does not define an upper limit for the total risk score of an identity or asset, but operating systems can impose a limit. For example, 32-bit operating systems limit a risk score to two million.

Risk score levels use the same naming convention as event severity. You can assess relative risk scores by comparing hosts with similar roles and asset priority.

• 20 - Info
• 40 - Low
• 60 - Medium
• 80 - High
• 100 - Critical

ES Admins can edit correlation searches to modify the risk score that the risk analysis response action assigns to an object. See Included adaptive response actions with Splunk Enterprise Security in Administer Splunk Enterprise Security.

Managing risk objects

Enterprise Security associates risk modifiers with risk objects.

Risk object field

The risk object field is a reference to a search field returned by a correlation search. Correlation searches use fields such as src and dest to report on matching results. The risk object field represents a system, host, device, user, role, credential, or any object that the correlation search is designed to report on. Review any correlation search that assigns a risk score for examples of fields that receive a risk score.

Risk object types

Splunk Enterprise Security defines three risk object types.

Object type	Description
System	Network device or technology. Can represent a device in the asset lookup.
User	Network user, credential, or role. Can represent an identity in the identity lookup.
Other	Any undefined object that is represented as a field in a data source.

If a risk object matches an object in the asset or identity table, Enterprise Security maps the object as the associated type. For example, an object that matches an asset in the asset lookup is mapped to a risk object type of system. However, devices and users do not need to be represented in the corresponding asset and identity tables to be identified as system or user risk objects. ES categorizes undefined or experimental object types with a risk object type of Other.

Resetting a risk score

There is a limitation with completely resetting a risk score for an object. Consider a scenario where a system is infected, the correlation searches generate many notable events for it, which leads to a high risk score. This system is re-imaged, but still has the same IP address or hostname, and you want to reset the risk score to zero as if it's new.

Using the previous example host again of 192.0.2.2 with a 480.0 risk score, you have few options for changing the score to zero because risk scores contain a time component:

• Change the time range picker from the default, and the risk score changes. You might see no results for this host if you change the time range to Last 15 minutes. The score is zero if no events are created in that timeframe. This does not reset the score, but helps you verify the new risk score, if you know the timeframe when the system is re-imaged.
• Create an ad-hoc risk entry with a risk score of -480. However, this is very dependent on the timeframe. This also does not actually reset the score. If your ad-hoc risk entry is outside the time window of the event, then the negative offset does not apply, and the object has a score of -480. See Create an ad hoc risk entry in Splunk Enterprise Security.