Splunk® Enterprise Security

Use Splunk Enterprise Security

Acrobat logo Download manual as PDF


This documentation does not apply to the most recent version of Splunk® Enterprise Security. For documentation on the most recent version, go to the latest release.
Acrobat logo Download topic as PDF

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

The host RLOG-10 is a jump server that is generating several notable events. The correlation searches Excessive Failed Logins, and Default Account Activity Detected are creating one notable event a day for that system. As RLOG-10 is a jump server, several network credentials are being used against this host, and software or other utilities may have been installed. As a jump server, this behavior is less interesting than if the same behavior is observed on the production DNS server. Rather than ignoring or suppressing notable events generated by jump servers, you can create jump-server-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 jump servers.

  1. Isolate jump 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 Excessive Failed Logins, but isolate the search to the jump server hosts and assign a risk modifier alert type only.
  3. Verify the risk modifiers are applied to the jump server hosts by raising their risk score incrementally. With the new correlation search, no notable events will be created for those hosts based on failed logins.

As the relative risk score goes up, RLOG-10 can be compared to all network servers and to other jump servers. If the relative risk score for RLOG-10 exceeds its peers, that host would be investigated by an analyst. If the risk scores of all jump servers are higher relative to other network hosts, 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 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.

Last modified on 24 September, 2020
PREVIOUS
Use Analytic Stories for actionable guidance in
  NEXT
Create an ad hoc risk entry in Splunk Enterprise Security

This documentation applies to the following versions of Splunk® Enterprise Security: 5.0.0, 5.0.1, 5.1.0, 5.1.1, 5.2.0, 5.2.1, 5.2.2, 5.3.0, 5.3.1, 6.0.0, 6.0.1, 6.0.2, 6.1.0, 6.1.1, 6.2.0, 6.3.0 Cloud only


Was this documentation topic helpful?


You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters