Use detections to search for threats in Splunk Enterprise Security
Use detections to scan multiple data sources to identify defined patterns and create intermediate findings or findings.
Detections are scheduled correlation searches or risk rules that can search many types of data sources, including events from any security domain (access, identity, endpoint, network), asset lists, identity lists, threat intelligence, third-party alerts, findings, and other data in Splunk platform. When the detection finds a pattern that might indicate anomalies or threats, it aggregates the results of an initial search with functions in the search processing language (SPL) and take action in response to events in the search conditions. The actions can include creating a finding, adjusting a risk score, or performing an adaptive response action.
Detections are a key part of the case management lifecycle and drive the analytics that generate findings and investigations. Splunk Enterprise Security allows you to aggregate findings and intermediate findings in any combination of risk based on factors such as a specific system, user, threat actors, and security framework such as Killchain or MITRE, and by similar findings.
Detections can be one of the following types:
- Event-based detections
- Finding-based detections
A single detection can either create findings or intermediate findings based on how you configure the detection. A single detection cannot create both findings and intermediate findings.
Findings are alerts or events created by event-based detections or finding-based detections. Findings contain custom metadata fields that contain details about what was calculated or observed by the detection such as a timestamp, key-value pairs, entity information, summary information about the behavior observed, metadata such as a MITRE tactic or technique, a calculated risk score based on the confidence and impact of the entity, and so on. Findings can be displayed in the analyst queue as standalone or as a group and are used to assist in the investigation of the alert conditions and to track event remediation. This term applies to Splunk Enterprise Security, the Splunk App for PCI Compliance, and Splunk IT Service Intelligence.
Intermediate findings are records or observations created by event-based detections that indicate anomalies but might not be standalone security incidents. Intermediate findings in conjunction with other findings might be used as input by advanced finding-based detections to discover potential security incidents with high fidelity and confidence. Intermediate findings might look identical to findings based on the data stored in the index. However, intermediate findings are not displayed in the analyst queue and are not triaged by analysts. The style and format of an intermediate finding is identical to that of a traditional finding and contains fields such as timestamp, key/value pairs, an entity, risk score, threat objects, and other metadata.
Splunk Enterprise Security offers approximately 1700+ detections associated with 225 analytic stories. For more information on available the latest Splunk Enterprise Security Content Updates, see Splunk Security Content. Operationalizing detections can be time consuming and challenging when detections lack the necessary data to generate actionable findings, which result in poor security outcomes. Therefore, a periodic review of detections used in the security operations center (SOC) is necessary to customize and deprecate detections for your specific use-cases. You can use detection versioning to review and maintain your detections.
You can make any changes to a detection to customize it to your unique needs and preferences. It is recommended to turn on versioning so that modifications are always saved as a new version of a detection without overwriting prior settings such as the SPL.
Following are some examples of detections:
- Identify an access attempt from an expired account by correlating a list of identities and an attempt to authenticate into a host or device.
- Identify a high number of hosts with a specific malware infection, or a single host with a high number of malware infections by correlating an asset list with events from an endpoint protection system.
- Identify a pattern of high numbers of authentication failures on a single host, followed by a successful authentication by correlating a list of identities and attempts to authenticate into a host or device. Then, apply a threshold in the search to count the number of authentication attempts.
Detection engineers create and manage detections within their SIEM environment based on the evolving threat landscape, advisories, security framework coverage priorities, and internal investigations or postmortems. SOC analysts and incident responders review the findings generated by the detections. System administrators manage access control to detections and high-level configuration settings for detections.
Event-based detections
Event-based detections evaluate raw events to generate findings or intermediate findings based on user selections during configuration.
The following figure shows how event-based detections create findings or intermediate findings:
Consider the following sample authentication event from a location in Hong Kong, which triggers the Geographically Improbable Access Detected detection if the entity typically logs in from the United States:
{"signinDateTime": "2024-01-07T22:03:26.8756252Z", "userPrincipalName": "fyodor@splunktshirtcompany.com", "appId": "00000002-0000-0ff1-ce00-000000000000", "loginStatus": "Success", "geoCoordinates": {"latitude": 22.396400451660156, "longitude": 114.1094970703125}, "dataSource": 1, "appDisplayName": "Office 365 Exchange Online", "failureReason": null, "signinErrorCode": 0, "location": {"country": "HK", "state": null, "city": "Hong Kong"}, "correlationId": "33be1f11-b730-4de7-9323-530bfe82a7ab", "mfaRequired": false, "id": "4c30c932-16c4-4611-b24a-715d15530000", "mfaAuthMethod": null, "deviceInformation": ";Windows 7;IE 10.0;", "ipAddress": "104.207.83.63", "userDisplayName": "Fyodor Malteskesko", "signinDateTimeInMillis": 1534763453875, "mfaResult": null, "mfaAuthDetail": null, "userId": "18af02a7-8541-4209-9dd5-600ab965d8a7"}
While this event can be considered interesting, it might not indicate a security incident for any of the following reasons:
- The user is using a VPN or remote access software.
- The data supporting the geographic location of the IP address is incorrect or out of date.
- The authentication event might be a proxy through an intermediate single sign-on (SSO) system and incorrectly reflected as the source of the authentication event.
As a detection engineer, you can choose to identify this detection output as an intermediate finding. This means that this security event is not displayed on the analyst queue until some subsequent finding-based detection groups it together with other findings or intermediate findings that raises the confidence value and indicates a potential security threat. Alternatively, you can choose to make this detection output a finding, which is triaged by a security analyst.
Behavior of the Threat Activity Detected search in Splunk Enterprise Security 8.0
The '''Threat Activity Detected''' detection in Splunk Enterprise Security version 8.0 works the same as in ES prior releases unless the detection is edited and saved to create intermediate findings or findings.
In Splunk Enterprise Security version 8.0, the Threat Activity Detected is an available event-based detection that creates either intermediate findings in the risk index or findings in the notable index. Events cannot be sent to both indexes for this event-based detection, though it was possible in prior releases using the adaptive risk actions (ARA's). Therefore, if the detection is saved to create intermediate findings, the events are sent to the risk index and events are not displayed in the analyst queue. Alternatively, if the detection is saved to create findings, each risk modifier creates an event that is sent to the notable index and separate events for the same threat object are displayed in the analyst queue.
The risk modifiers are also updated and use only entity types such as user or system. Therefore, risk modifiers that are not entity types such as user or system such as risk_hash, risk_score, risk_network, risk_host, and risk_other are removed from the detection SPL using the Assign risk section of the event-based detection editor.
You can also create alternative SPL searches to avoid creating multiple findings and reduce noise on the analyst queue. You can configure the SPL of the detection to create only one finding and multiple intermediate findings to indicate a single threat on the analyst queue.
Finding-based detections
Finding-based detections allow you to aggregate findings and intermediate findings in any combination of risk based on factors such as a specific system, user, or threat actor without a complex knowledge of SPL. These aggregates of findings, intermediate findings are called finding groups. Finding-based detections allow alerting to correspond to the magnitude of the risk associated with the entity whereas an event-based detection alerts every time it finds the pattern. While event-based detections review raw events to generate findings, finding-based detections review findings to create finding groups.
Finding-based detections review the findings in the risk index and the notable index for anomalous events and threat activities and use an aggregation of findings impacting a single entity, or other group type and criteria to generate finding groups that indicate a security risk. For example, when the finding-based detection finds an entity associated with several risk events that exceed a risk threshold, it creates finding groups in Splunk Enterprise Security. This allows analysts to focus their efforts on connected behaviors associated with the finding groups. Finding-based detections replace what was formerly known as risk incident rules.
The following figure shows how finding-based detections create finding groups:
For example, a single finding that matches the criteria of a finding-based detection with an entity such as win-host-mhaag-attack-range-791 might not indicate a security incident.
However, as the following example indicates, when multiple findings are grouped together, they can collectively be a strong indicator that the entity win-host-mhaag-attack-range-791 is under a security threat and must be investigated.
https://github.com/splunk/security_content/blob/develop/detections/system_processes_run_from_unexpected_locations.yml",risk_message="System Process Running from Unexpected Location has been triggered on '''win-host-mhaag-attack-range-791''' by Administrator.",event_id="null",entity_id="d002ccb3-eabd-3ee5-b488-c430ca8cf2cd",detection_id="28179107-099a-464a-94d3-08301e6c055f",detection_version="13",parent_process_id="8068.0",process_id="6016.0",process=""C:\Windows\notepad.exe"",sourceType="WinEventLog",process_name="notepad.exe",parent_process_name="file.exe",process_path="C:\Windows\notepad.exe",dest="'''win-host-mhaag-attack-range-791'''",user="Administrator",parent_process_path="C:\Users\ADMINI~1\AppData\Local\Temp\2\T1105\file.exe"
Differences between event-based detections and finding-based detections
The following table summarizes the differences between an event-based detection and a finding-based detection:
| Event-based detection | Finding-based detection |
|---|---|
| Analyzes raw events to create findings or intermediate findings. | Analyzes findings and intermediate findings to create a new finding group or aggregates common findings or intermediate findings into an existing finding group. |
| Triggers every time a pattern is identified. | Triggers when a pattern is identified, or a risk threshold is crossed. |
| Creates findings or intermediate findings that might not be as critical to resolve. | Creates finding groups based on 7 types of outputs and contain more event-based details. Might require more urgent resolution. |
See also
For more information on how to configure, manage, and use detection versioning in Splunk Enterprise Security, see the product documentation:
| Customize table settings for the analyst queue in Splunk Enterprise Security | Identify the relevant use case for your detection in Splunk Enterprise Security |
This documentation applies to the following versions of Splunk® Enterprise Security: 8.0.0, 8.0.1
Download manual
Feedback submitted, thanks!