Configure correlation searches
A correlation search scans multiple data sources for defined patterns. When the search finds a pattern, it performs an adaptive response action such as creating a notable event.
Correlation searches can search many types of data sources, including events from any security domain (access, identity, endpoint, network), asset lists, identity lists, threat intelligence, and other data in Splunk platform. The searches then aggregate the results of an initial search with functions in SPL, and take action in response to events that match the search conditions with an adaptive response action. Configure correlation searches to update the settings associated with how they run.
Enable correlation searches
Enable correlation searches to start running adaptive response actions and receiving notable events. installs with all correlation searches disabled so that you can choose the searches that are most relevant to your use cases.
- Select Configure > Content Management.
- Filter on a type of Correlation Search.
- Locate the name of the correlation search you want to enable.
- In the Actions column, click Enable to enable the searches that you want to enable.
- After you enable correlation searches, click "Back to PCI Compliance" in the menu bar.
The following correlation searches are used in PCI:
Correlation search | Default notable event status |
---|---|
Access - Account Deleted - Rule | notable event disabled by default |
Access - Brute Force Access Behavior Detected - Rule | notable event disabled by default |
Access - Cleartext Password At Rest - Rule | notable event disabled by default |
Access - Completely Inactive Account - Rule | |
Access - Default Account Usage - Rule | notable event disabled by default |
Access - Default Accounts At Rest - Rule | notable event disabled by default |
Access - Excessive Failed Logins - Rule | |
Access - Inactive Account Usage - Rule | |
Access - Insecure Or Cleartext Authentication - Rule | |
Asset - Asset Ownership Unspecified - Rule | notable event disabled by default |
Audit - Anomalous Audit Trail Activity Detected - Rule | notable event disabled by default |
Audit - Expected Host Not Reporting - Rule | |
Audit - Personally Identifiable Information Detection - Rule | |
Endpoint - Anomalous New Processes - Rule | |
Endpoint - Anomalous New Services - Rule | |
Endpoint - High Number of Hosts Not Updating Malware Signatures - Rule | notable event disabled by default |
Endpoint - Multiple Primary Functions Detected - Rule | |
Endpoint - Outbreak Observed - Rule | |
Endpoint - Prohibited Process Detection - Rule | |
Endpoint - Prohibited Service Detection - Rule | |
Endpoint - Recurring Malware Infection - Rule | |
Endpoint - Should Timesync Host Not Syncing - Rule | notable event disabled by default |
Identity - Activity from Expired User Identity - Rule | |
Network - Network Device Rebooted - Rule | notable event disabled by default |
Network - Policy Or Configuration Change - Rule | |
Network - Substantial Increase in an Event - Rule | notable event disabled by default |
Network - Substantial Increase in Port Activity (By Destination) - Rule | notable event disabled by default |
Network - Vulnerability Scanner Detection (by event) - Rule | |
Network - Vulnerability Scanner Detection (by targets) - Rule | |
PCI - 1.2.3 - Unauthorized Wireless Device Detected - Rule | |
PCI - 1.3.3 - Unauthorized or Insecure Communication Permitted - Rule | |
PCI - 1.4.2- Inbound traffic from untrusted network to trusted network - Rule | |
PCI - 11.1 - Rogue Wireless Device - Rule | |
PCI - 2.1.1 - Unencrypted Traffic on Wireless Network - Rule | |
PCI - 2.2.2 - System Misconfigured - Rule | |
PCI - 2.2.3 - Weak Encrypted Communication Detected - Rule | |
PCI - 2.2.4 - Prohibited or Insecure Port Detected - Rule | |
PCI - 4.1 - Credit Card Data Transmitted In Clear - Rule | |
PCI - 5.2 - Inactive Antivirus Client Detected - Rule | |
PCI - 5.2.1a - Anti-malware solution(s) not detected on system - Rule | |
PCI - 5.2 - Inactive Antivirus Client Detected - Rule | |
PCI - 5.2.3c - Anti-malware solution(s) not detected on system - Rule | |
PCI - 5.3.1b - Anti-malware data or definitions that are NOT up to date - Rule | |
PCI - 5.3.2.1b -Anti-malware scan results not found for host - Rule | |
PCI - 5.3.2b -Disabled anti-malware on host - Rule | |
PCI - 5.3.2c - Anti-malware scan incomplete or did not run - Rule | |
PCI - 5.3.3b - Anti-malware disabled on host with removable electronic media connected - Rule | |
PCI - 5.3.4 - Inbound traffic from untrusted network to trusted network - Rule | |
PCI - 6.1 - Anomalous Update Service Detected - Rule | |
PCI - 6.1 - High/Critical Update Missing - Rule | |
PCI - 6.1 - High/Critical Update Missing - Rule | |
PCI - 6.1 - High/Critical Update Missing - Rule | |
PCI - 6.3 - Open Critical Vulnerabilities in the last 30 days - Rule | |
PCI - 6.3.3a - Medium and low security in more than 30 days - Rule | |
PCI - 6.4.2 - Web data was not logged in last 7 days - Rule | |
PCI - 8.2.4 - Addition of user IDs without approvals - Rule | |
PCI - 8.2.4 - Modification of user IDs without approvals - Rule | |
PCI - 8.2.4 - Deletion of user IDs without approvals - Rule | |
PCI - 8.3 - Privileged Authentication Without Multifactor - Rule | |
PCI - 8.3 - All Authentication without multifactor - Rule | |
PCI - 8.3.4a - User account lockout after 10 invalid login attempt - Rule | |
PCI - 8.3.10.1 - Sample set of users showing password changes for every 90 days - Rule | |
PCI - 8.4.1a - Access to CDE without MFA/2FA - Rule | |
PCI - 8.4.2b - Access to CDE without MFA/2FA - Rule | |
PCI - 8.5 - MFA replay attack detected - Rule | |
PCI -10.7 - Data logging for all the listed solution in last 6 hrs - Rule | |
PCI -11.3 - Open High Vulnerabilities in the last 60 days - Rule | |
PCI -11.3 - Open Critical Vulnerabilities in the last 30 days - Rule | |
PCI -11.3.1- Vulnerability scan is older than 3 months- Rule |
To create notable events for the correlation searches that have notable events disabled by default, see Create a notable event in the Splunk App for PCI Compliance User Manual.
For details about the correlation searches shipped with the Splunk App for PCI Compliance, see Search View Matrix in the User Manual.
Change correlation search scheduling
Change the default search type of a correlation search from real-time to scheduled. uses indexed real-time searches by default.
- From the Content Management page, locate the correlation search you want to change.
- In the Actions column, click Change to scheduled.
Editing correlation searches
You can make changes to correlation searches to fit your environment. For example, modify the thresholds used in the search, change the response actions that result from a successful correlation, or change how often the search runs. Modifying a correlation search does not affect existing notable events.
- Click the name of a correlation search on the Content Management page to edit it.
If you modify the start time and end time for the correlation search, use relative time modifiers. See Specify time modifiers in your search in the Splunk Enterprise Search Manual.
Edit the correlation search in guided mode
You can edit some correlation searches in guided mode. Not all correlation searches support guided search editing. If a search appears grayed-out and has the option to Edit search manually or Edit search in guided mode, the search was built in guided mode and can be edited in guided mode. If a search can be edited in the search box and only has the option to Edit search in guided mode, editing the search in guided mode overwrites the existing search.
- Click Edit search in guided mode to open the guided search creation wizard.
- Review the search elements in the correlation search, making changes if you want.
- Save the search.
Throttle the number of response actions generated by a correlation search
Set up throttling to limit the number of response actions generated by a correlation search. When a correlation search matches an event, it triggers a response action.
By default, every result returned by the correlation search generates a response action. Typically, you may only want one alert of a certain type. You can use throttling to prevent a correlation search from creating more than one alert. Some response actions allow you to specify a maximum number of results in addition to throttling. See Set up adaptive response actions in .
- Select Configure> Content > Content Management.
- Click the title of the correlation search you want to edit.
- Type a Window duration. During this window, any additional event that matches any of the Fields to group by will not create a new alert. After the window ends, the next matching event will create a new alert and apply the throttle conditions again.
- Type the Fields to group by to specify which fields to use when matching similar events. If a field listed here matches a generated alert, the correlation search will not create a new alert. You can define multiple fields, and available fields depend on the search fields that the correlation search returns.
- Save the correlation search.
Throttling applies to any type of correlation search response action and occurs before notable event suppression.
Use security framework annotations in correlation searches
Use annotations to enrich your correlation search results with security framework mappings. You also see these annotations as field labels in Incident Review and Risk Analysis.
- Select Configure > Content > Content Management.
- Click the title of the correlation search you want to edit.
- You can use annotations for industry-standard mappings or unmanaged annotations for custom mappings.
The annotations are stored in action.correlationsearch.annotations
in JSON format in the savedsearches.conf file. MITRE ATT&CK definitions are pre-populated in the security_framework_annotations.csv file. You don't need to revise this unless you want to display non-default info in the annotations dropdown field.
Use annotations to enrich your correlation search results with the context from industry-standard mappings.
- Scroll to Annotations.
- Add annotations for the common framework names listed. These fields are for use with industry-standard mappings, but also allow custom values. Industry-standard mappings include values such as the following:
Security Framework Five Random Mapping Examples CIS 20 CIS 3, CIS 9, CIS 11, CIS 7, CIS 12 Kill Chain Reconnaissance, Actions on Objectives, Exploitation, Delivery, Lateral Movement MITRE ATT&CK T1015, T1138, T1084, T1068, T1085
This field also contains mitre technique IDs for you to select from the mitre_attack_lookup lookup definition.NIST PR.IP, PR.PT, PR.AC, PR.DS, DE.AE - Click Save.
Consider MITRE ATT&CK annotations as an example. At search time, the mitre_attack_enrichment automatic lookup uses the mitre technique id that you selected, and it outputs additional industry-standard context as event fields. Some examples include, but are not limited to, the following: annotations.mitre_attack.mitre_description, annotations.mitre_attack.mitre_detection, annotations.mitre_attack.mitre_software_name, annotations.mitre_attack.mitre_software_platform, annotations.mitre_attack.mitre_tactic, annotations.mitre_attack.mitre_technique, annotations.mitre_attack.mitre_technique_id, annotations.mitre_attack.mitre_url
.
Search your MITRE ATT&CK intelligence download data to verify the annotation details as follows:
| inputintelligence mitre_attack
Unmanaged annotations won't be enriched with any industry-standard context.
- Scroll to Unmanaged Annotations.
- Click + Framework to add your own framework names and their mapping categories. These are free-form fields.
- Click Save.
Consider an unmanaged annotation as an example. In your events, you will see annotations.<unmanaged_framework_name>=<unmanaged_tactic_id_value>
.
Add additional security frameworks to your annotations
While the MITRE ATT&CK framework annotations are available by default, you can also add other industry-standard frameworks. You can add them from scratch, but clone the existing mitre_attack for convenience.
Add the intelligence download by completing the following steps:
- From the Splunk Enterprise menu bar, select Settings > Data inputs > Intelligence Downloads.
- Filter on mitre.
- Click the Clone action for mitre_attack.
- Type a name for the industry-standard framework.
- Revise the description.
- Leave Is Threat Intelligence unchecked.
- Revise the type.
- Revise the URL.
- Click Save.
Add the lookup definition by completing the following steps:
- From the Splunk Enterprise menu bar, select Settings > Lookups > Lookup definitions.
- Filter on mitre.
- Click the Clone action for mitre_attack_lookup.
- Leave Type as-is.
- Type a name for the industry-standard framework.
- Revise the Supported fields.
- Click Save.
Add the automatic lookup by completing the following steps:
- From the Splunk Enterprise menu bar, select Settings > Lookups > Automatic lookups.
- Filter on mitre.
- Click the Clone action for source::...- Rule : LOOKUP-mitre_attack_enrichment.
- Leave Destination app as-is.
- Leave Apply to as-is. The named* source::...- Rule is necessary.
- Type a name for the industry-standard framework.
- Revise all the fields.
- Click Save.
Allow non-admins to edit correlation searches
If you want non-admins to edit correlation searches, add the edit correlation searches capability to a different role in .
- Select Configure > General > Permissions.
- Locate the role that you want to allow to edit correlation searches.
- Select the check box for Edit Correlation Searches for that role.
- Click Save.
Correlation searches migration to savedsearches.conf
Starting in the Splunk App for PCI Compliance version 3.4.0, correlationsearches.conf
is no longer used to define correlation searches. Instead, savedsearches.conf
uniquely identifies correlation searches using the action.correlationsearch.enabled=1
parameter. The correlationsearches.conf
file is deprecated.
For stability, the Threat - Correlation Searches - Lookup Gen
saved search continues to use the contents of both correlationsearches.conf
and savedsearches.conf
to populate the correlationsearches
KV Store collection used by Incident Review.
Changes the Splunk App for PCI Compliance makes at upgrade
When you upgrade to the Splunk App for PCI Compliance version 3.4.0, the Splunk App for PCI Compliance migrates all correlation searches in your environment, including custom correlation searches. The confcheck_es_correlationmigration.py
script migrates all entries in correlationsearches.conf
into updated entries in savedsearches.conf
. The migration can take up to five minutes to complete after the upgrade.
During the upgrade, the Splunk App for PCI Compliance continues to create notable events without interruption.
Changes you have to make after upgrade
After upgrading to the Splunk App for PCI Compliance version 3.4.0, you have to make additional changes.
- Check for searches that did not migrate successfully and migrate the
correlationsearches.conf
entries manually using the parameter definitions below. - Update searches that call the
correlationsearches
REST endpoint.- For example, a search that displays a list of correlation searches in your environment would change from
to| rest splunk_server=local /services/alerts/correlationsearches | rename eai:acl.app as app, title as csearch_name | table app security_domain csearch_name description
| rest splunk_server=local count=0 /services/saved/searches | where match('action.correlationsearch.enabled', "1|[Tt]|[Tt][Rr][Uu][Ee]") | rename eai:acl.app as app, title as csearch_name, action.correlationsearch.label as csearch_label, action.notable.param.security_domain as security_domain | table csearch_name, csearch_label, app, security_domain, description
- For example, a search that displays a list of correlation searches in your environment would change from
Both the correlationsearches.conf
and savedsearches.conf
files are used to populate the KV Store collection used by Incident Review. Custom search macros that reference that KV Store collection continue to work as before, but consider updating them anyway.
correlationsearches.conf
parameter translation to savedsearches.conf
All correlationsearches.conf
parameters now exist in savedsearches.conf
and the correlationsearches.conf
file has been deprecated. Do not update it directly except to manually migrate correlation search definitions.
Identification parameters for correlation searches
New parameters identify whether a saved search is a correlation search and the name of the correlation search.
correlationsearches.conf parameterin pre-3.4.0 versions |
savedsearches.conf parameterstarting in 3.4.0 |
Notes |
---|---|---|
N/A | action.correlationsearch=0 |
This is an internal parameter and can be ignored. |
A stanza for the search exists | action.correlationsearch.enabled=1 |
This parameter identifies a saved search as a correlation search. |
rule_name |
action.correlationsearch.label |
This parameter provides the name of the correlation search. |
description |
description |
This parameter provides the description of the correlation search. |
Notable event parameters for correlation searches
The action.notable
parameter identifies a notable event associated with a correlation search. The parameters that describe additional details associated with the notable event now exist in the savedsearches.conf
file.
correlationsearches.conf parameterin pre-3.4.0 versions |
savedsearches.conf parameterstarting in 3.4.0 |
---|---|
security_domain |
action.notable.param.security_domain
|
severity |
action.notable.param.severity
|
rule_title |
action.notable.param.rule_title
|
rule_description |
action.notable.param.rule_description
|
nes_fields |
action.notable.param.nes_fields
|
drilldown_name |
action.notable.param.drilldown_name
|
drilldown_search |
action.notable.param.drilldown_search
|
default_status |
action.notable.param.default_status
|
default_owner |
action.notable.param.default_owner
|
Related search parameters for correlation searches
Searches related to a correlation search, such as the context-generating searches associated with a correlation search that uses extreme search, are now part of a JSON blob action.correlationsearch.related_searches
parameter.
correlationsearches.conf parameterin pre-3.4.0 versions |
savedsearches.conf parameterstarting in 3.4.0 |
---|---|
related_search_name = Endpoint - Emails By Source - Context Gen
related_search_name.0 = Endpoint - Emails By Destination Count - Context Gen |
action.correlationsearch.related_searches = [\ "Endpoint - Emails By Source - Context Gen",\ "Endpoint - Emails By Destination Count - Context Gen"\ ] |
Example correlation search stanzas from this version and previous versions
The savedsearches.conf
stanza for a correlation search looks as follows starting in 3.4.0.
[Access - Concurrent App Accesses - Rule] action.correlationsearch = 0 action.correlationsearch.enabled = 1 action.correlationsearch.label = Concurrent Login Attempts Detected action.email.sendresults = 0 action.notable = 0 action.notable.param.security_domain = access action.notable.param.severity = medium action.notable.param.rule_title = Concurrent Access Event Detected For $user$ action.notable.param.rule_description = Concurrent access attempts to $app1$ by $user$ from two different sources( $src1$, $src2$ ) have been detected. action.notable.param.nes_fields = user action.notable.param.drilldown_name = View access attemps by $user$ action.notable.param.drilldown_search = | datamodel Authentication Authentication search | search Authentication.user="$user$" action.risk = 1 action.risk.param._risk_object = user action.risk.param._risk_object_type = user action.risk.param._risk_score = 20 alert.suppress = 1 alert.suppress.fields = user alert.suppress.period = 86300s alert.track = false cron_schedule = 10 * * * * description = Alerts on concurrent access attempts to an app from different hosts. These are good indicators of shared passwords and potential misuse. disabled = True dispatch.earliest_time = -70m@m dispatch.latest_time = -5m@m enableSched = 1 is_visible = false request.ui_dispatch_app = SplunkEnterpriseSecuritySuite search = | tstats `summariesonly` count from datamodel=Authentication.Authentication by _time,Authentication.app,Authentication.src,Authentication.user span=1s | `drop_dm_object_name("Authentication")` | eventstats dc(src) as src_count by app,user | search src_count>1 | sort 0 + _time | streamstats current=t window=2 earliest(_time) as previous_time,earliest(src) as previous_src by app,user | where (src!=previous_src) | eval time_diff=abs(_time-previous_time) | where time_diff<300
In previous versions of the Splunk App for PCI Compliance, the savedsearches.conf
and correlationsearches.conf
definitions for the same correlation search looks as follows.
savedsearches.conf
[Access - Concurrent App Accesses - Rule] action.email.sendresults = 0 action.risk = 1 action.risk.param._risk_object = user action.risk.param._risk_object_type = user action.risk.param._risk_score = 20 alert.suppress = 1 alert.suppress.fields = user alert.suppress.period = 86300s alert.track = false cron_schedule = 10 * * * * disabled = True dispatch.earliest_time = -70m@m dispatch.latest_time = -5m@m enableSched = 1 is_visible = false request.ui_dispatch_app = SplunkEnterpriseSecuritySuite search = | tstats `summariesonly` count from datamodel=Authentication.Authentication by _time,Authentication.app,Authentication.src,Authentication.user span=1s | `drop_dm_object_name("Authentication")` | eventstats dc(src) as src_count by app,user | search src_count>1 | sort 0 + _time | streamstats current=t window=2 earliest(_time) as previous_time,earliest(src) as previous_src by app,user | where (src!=previous_src) | eval time_diff=abs(_time-previous_time) | where time_diff<300
correlationsearches.conf
[Access - Concurrent App Accesses - Rule] security_domain = access severity = medium rule_name = Concurrent Login Attempts Detected description = Alerts on concurrent access attempts to an app from different hosts. These are good indicators of shared passwords and potential misuse. rule_title = Concurrent Access Event Detected For $user$ rule_description = Concurrent access attempts to $app1$ by $user$ from two different sources( $src1$, $src2$ ) have been detected. nes_fields = user drilldown_name = View access attemps by $user$ drilldown_search = | datamodel Authentication Authentication search | search Authentication.user="$user$" default_owner = default_status =
IDS/IPS Alert Activity | Create new correlation searches |
This documentation applies to the following versions of Splunk® App for PCI Compliance: 5.0.1, 5.0.2, 5.1.0, 5.1.1, 5.1.2, 5.2.0, 5.3.0, 5.3.1, 5.3.2
Feedback submitted, thanks!