Enterprise Security Incident Review - Incomplete list or correlation searches in filter

[rafiki]

Hi folks,

A user in my company discovered that the pre-built list of Correlation-Searches in the filter on the Incident Review dashboard is incomplete.

I can well retreive the correlation searches in Content view and in Alerts views, and they have triggeresd notables.

I tried to find out the search ran to populated it but my skill in html/js are not enough.

Any idea ?

Thanks!

[rafiki · Accepted solution]

Hi,

It appears that the problem disappeared by itself after the upgrade of Enterprise Security from 6.4.0 to 6.6.2.

[ro_mc]

You mentioned you have other working searches. Are there any differences between these and the search above that is not working? I.e. are you able to create other correlation searches based on these differences to replicate the issue? If you recreate the correlation search, does the problem continue?

Incident review functionality is typically open to anyone with the ess_analyst role, but it may be helpful to see if the same issue occurs for an admin role (if you're not already logged in as an admin).

In ES Content Management, is the correlation search listed and enabled, with a notable event action? Are there any conflicting alerts with a notable event action (in searches, reports & alerts)? Are there any logs that might provide further information? See https://community.splunk.com/t5/Splunk-Enterprise-Security/How-do-I-determine-why-a-Correlation-Sear... for details.

I.e. can the correlation search and notable event be traced from start to finish without error?

You can also check the following for other potential issues at the time of the notable firing and the time you perform your search. You may want to remove the source file to expand the search, and optionally filter by other keywords relevant to your search:

index=_internal source=*splunkd.log sourcetype=splunkd " ERROR " OR " WARN "

[rafiki]

Hello,

Thanks for your help.

I walked through the article you suggested without seeing any issue:
- scheduled search results

- Events are well in notable (also checked for removal action but none)

- Checked the alerts generation:

- Checked the output : simple multiple fields, no xml or any other huge field's values.

- And more globally, nothing but INFO level in _internal

I find out that 2 correlation searches had a double-quote in a variable in action.notable.param.rule_description (e.g. $"variable$) but it has particular no effect on the parsing, as it didn't solve the problem.

Checking two searches, one working , one not, I didn't notice any noticable difference in the naming, special caracters or configuration options..

The working example has no drilldown, but found others working with it and without particular differenceon this.

At this point, it would be very helpful to know the search executed to populate the dropdown list...

Example:

Working:

[Threat - [C0005] [\w\s]+ - Rule]
action.correlationsearch.enabled = 1
action.correlationsearch.label = [C0005] [\w\s]+
action.customsearchbuilder.enabled = false
action.customsearchbuilder.spec = {}
action.email = 1
action.email.format = table
action.email.inline = 1
action.email.sendcsv = 1
action.email.sendresults = 1
action.email.subject = [C0005] [\w\s]+
action.email.to = emain@address
action.notable = 1
action.notable.param.next_steps = {"version":1,"data":\w+}
action.notable.param.recommended_actions = [\w,]+
action.notable.param.rule_description = [\w\s]+
action.notable.param.rule_title = [C0005][\[\]\w\s()$]+
action.notable.param.security_domain = threat
action.notable.param.severity = high
action.notable.param.verbose = 0
alert.suppress = 1
alert.suppress.fields = <suppressed_ield>
alert.suppress.period = 86400s
alert.track = 0
counttype = number of events
cron_schedule = */5 * * * *
description = [()\w\s]+
disabled = 1
dispatch.earliest_time = -10m@m
dispatch.latest_time = -5m@m
dispatch.rt_backfill = 1
enableSched = 1
quantity = 0
relation = greater than
request.ui_dispatch_app = SplunkEnterpriseSecuritySuite
search = <search>

- Not working:

[Threat - [C0804] [\w\s]+ - Rule]
action.correlationsearch.enabled = 1
action.correlationsearch.label = [C0804] [\w\s]+
action.customsearchbuilder.enabled = false
action.customsearchbuilder.spec = {}
action.notable = 1
action.notable.param.drilldown_name = [\w\s]+
action.notable.param.drilldown_search = <search>
action.notable.param.recommended_actions = [\w,]+
action.notable.param.rule_description = [\w\s]+
action.notable.param.rule_title = [\[\]\w\s()$]+
action.notable.param.security_domain = threat
action.notable.param.severity = high
action.notable.param.verbose = 0
alert.suppress = 0
alert.track = 1
counttype = number of events
cron_schedule = 8-59/5 * * * *
description = [\w\s]+
dispatch.earliest_time = -10m@m
dispatch.latest_time = -5m@m
dispatch.rt_backfill = 1
enableSched = 1
quantity = 0
realtime_schedule = 0
relation = greater than
request.ui_dispatch_app = SplunkEnterpriseSecuritySuite
search = <search>

[ro_mc]

Correlation searches in savedsearches.conf have a search name, as well as a correlation search name as an attribute within the stanza, which from memory is the display name of the correlation search.

The correlation keyword search may be matching on the actual search name rather than what is displayed in the results from the free text keyword search. Alternatively, it may be due to minor breakers in the target string. I.e. if there's a special character in the target string, it may need to be included in the search in order to match.

Let us know if you're able to match based on the alternate search name or different keywords.

[rafiki]

Hi,

Unfortunately, both savedsearch and correlation search's label contains the same words and have no more special caracters than working others.

No result either typing the entire label or savedserach name.