We have a lot of indicators in our Splunk Incident Review queue, and I am having a challenging time with Splunk Enterprise Security Suppression, and it's driving me nuts. It's been about a year and I cannot figure out how people efficiently suppress domains, IP's and URL's.
I can click an event, and add it to a suppression, but it appears you can have only 30 suppressions maximum, or they roll over into not being able to see your previous suppressions. Plus, each individual suppression adds an additional search, which can cause overhead so we try to add a lookup within a suppression and it does not work properly.
So then we edit the "Threat Activity Detected" correlation search with either a macro or a lookup with domains we don't want to see and it still does not seem to properly tune out indicators that constantly populate our queue.
| search `high_level_domains_tuneout` NOT [ |inputlookup IP_DomainIntelTuneOut.csv | return 999 threat_match_value ]
So what methods are you guys doing to suppress all of your different kinds of indicators? Are you using lookups or the Splunk Suppression workflow? I'm open to suggestions for better methods. I don't think it should really be this complicated. What methods are you using to do your Splunk ES Incident Review Suppression?
Interesting that you mention 30 suppressions maximum, as that seems to be some limit that displays in the Web UI, and it seems to be related to a recent upgrade from ES 4.0.1 to ES 4.1.3, as it used to not be the case for us.
We have ~300 suppressions that all used to show up under Configure --> Incident Management --> Notable Event Suppressions, but now it only displays 30 of them. However, all of the other ~270 are still there and working. You can see them in the Web UI:
Settings > Event types.
Search suppression event types using: notable_suppression-*
Or you can see them in $SPLUNK_HOME/etc/apps/SA-ThreatIntelligence/local/eventtypes.conf
That said, I know that doesn't answer your question completely. For us it was important that we allowed our analysts the ability to implement suppressions based on an IP address or user for a specific notable, so we've given them the ability to do so.
What I still want to implement though, is a process by which we Audit those suppressions and consolidate/review as necessary.
Hope that helps.
Interesting that you mention 30 suppressions maximum, as that seems to be some limit that displays in the Web UI, and it seems to be related to a recent upgrade from ES 4.0.1 to ES 4.1.3, as it used to not be the case for us.
We have ~300 suppressions that all used to show up under Configure --> Incident Management --> Notable Event Suppressions, but now it only displays 30 of them. However, all of the other ~270 are still there and working. You can see them in the Web UI:
Settings > Event types.
Search suppression event types using: notable_suppression-*
Or you can see them in $SPLUNK_HOME/etc/apps/SA-ThreatIntelligence/local/eventtypes.conf
That said, I know that doesn't answer your question completely. For us it was important that we allowed our analysts the ability to implement suppressions based on an IP address or user for a specific notable, so we've given them the ability to do so.
What I still want to implement though, is a process by which we Audit those suppressions and consolidate/review as necessary.
Hope that helps.
Thanks for that context.
As an update, Splunk has confirmed that the 30 Suppressions view limit is a known bug for which there is no present hotfix for 4.1.3 BUT is fixed in 4.5.1. I'll also note that managing Suppressions via Event types means that ES does NOT log the audit trail of that Suppression. This means no events logged to index=_internal sourcetype=notable_event_suppression:rest_handler "SuppressionAudit" action=* (aka eventtype=suppression_audit). Still looking for a workaround on that 🙂
Last update. We got a workaround from Splunk support for displaying more than 30 suppressions inside of ES.
It's in the comments here:
https://answers.splunk.com/answers/482839/splunk-enterprise-security-why-is-the-notable-even-1.html