I'm just trying to grok out how the Splunk_SA_CIM overlaps with the ES app in terms of data model accelerations. Out of the box it looks like it's set to accelerate a set of datamodels from the SPLUNK_SA_CIM app, but I can't seem to find a matrix or straightforward way to know which models support which ES components, etc...
I don't want to accelerate models unnecessarily since that can be expensive, but I don't want to just turn them off and see what breaks if there's a more logical path either. But we're also not using all the out-of-box searches and dashboards so it would be nice to have a way to make the app leaner in our usage.
Anyone have thoughts on how to tie them together?
If you've got Enterprise Security version 3.2 - 3.3, the Dashboard Requirements Matrix page in the ES docs will give you the dashboards and panel names with the associated data model. I would also consider the suggestion of lowering the default retention of any data models you're not intending to use.
ES relies on CIM (and its own datamodels). The accelerations that it enables are expected to be required; they won't be expensive if there's no data that matches them, so I would tend to lean towards TA modifications to prevent accidental overreach instead of turning off accelerations.
The thing for us is -- some of those models will likely hit on data that we're not using ES to monitor for SIEM purposes. So I was curious if there was any mapping, otherwise I suppose I could just cut off the ES search head's access to those indexes that aren't relevant...
You can edit the constraints of the data models to exclude indexes. Out of the box, the data models strictly use tags to collect data. E.g., tag=network AND tag=communicate.
You can easily modify this to be: tag=network AND tag=communicated NOT (index=myindex1 OR index=myindex2 ...)
After modifying, you do need to kickoff a rebuild so old data accelerations are rebuilt.
Another approach would be to modify the TA's, and in the eventtypes where the CIM tags are associated, specify or exclude your specific indexes.
You can always restrict the time frame of the datamodel accelerations that you don't want to be expensive that your instance of ES won't be using. That way, even if they have a lot of data in them, and you aren't relying on ES to use them, they won't hit you as hard.