Reporting
Highlighted

Datamodel Acceleration: Bug, misconfiguration, or by design?

Ultra Champion

Looking at a specific CIM DataModel (Authentication for example):

The DataModel specifies a macro as its criteria: cim_Authentication_indexes
The intent of this is that you edit the macro to specify only the relevant indexes for that DataModel .
You would enter something along the lines of: (index=authentication_index OR index=other_auth_index) and save that in the Macro.

The expectation following such, is that when the DataModel runs it need only look for events in those specific indexes, and specifically excludes every other index.

However... (at least in my environment)
The search which gets executed is:

| search (index=* OR index=_*) ((`cim_Authentication_indexes`) tag=authentication NOT (action=success user=*$)) |....

(as reported in: https://localhost:8089/servicesNS/nobody/Splunk_SA_CIM/datamodel/acceleration/Authentication, among other places)

Aside from the argument that index=* is generally agreed to be bad practice (and * or _* is even worse) I am trying to understand if this is common to other deployments or if we have somehow introduced this.

Since the execution is additive, I know the search is still effectively index=any AND index=$myauthindexes$ which essentially evaluates to just index=$myauthindexes$ but I had never noticed this before, and cant help wonder if we have something funny going on.

Be interested to hear if others have the same, and any thoughts on why this was implemented if it was by design.
Running 6.5.2, upgrading to 7.0.2 imminently, so don't want to drag any bad config with us.

Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

Influencer

Hey

Not a misconfiguration, I have a brand new ES install and the same thing occurs to me.

What goes through my mind is, imagine if you don't specify any cimAuthenticationindexes, then Splunk should still try to get over your lack of accuracy in that matter, so it searches them all by default.

For me it is just a protection against the case where you are not specific. If no index was set, Splunk would only search the default indexes like main (well depending on what default indexes are in the role splunk-system-user used to run the accelerations)

0 Karma
Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

Communicator

I downvoted this post because not an issue

0 Karma
Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

SplunkTrust
SplunkTrust

This has been done by design, they have chosen to use this option so you do not have to specify any index for the data model and it will still work.

Perhaps they could have defined the macro as index=* OR index=_*, however I'm unsure if we will receive an answer on the community forum to advise why!

0 Karma
Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

Esteemed Legend

If you are asking What happens when I do not define a value for any cim_*_indexes macro?, then you have discovered the answer, it INVISIBLY defaults to index=*. How and why, who knows?

0 Karma
Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

New Member

I'm currently wondering why the CIM Authentication Datamodel does NOT search my custom indexes defined by the cimauthenticationindexes macro. Without anything defined for the macro, I can see the following search from my search head internal index.
(index=* OR index=
) index=_audit "action=login attempt" NOT "action=search" (NOT action=success OR NOT user=$)

To me it looks like only a search against 'index=audit AND "action=login attempt" ' and this is indeed what happens. Even if I add my custom indexes into macro, it will added before index=audit. I don't see the tag=authentication in the search string at all, which is also a bit weird.

I'm using Splunk 7.2.4.2 with CIM 4.13.0.

0 Karma
Highlighted

Re: Datamodel Acceleration: Bug, misconfiguration, or by design?

New Member

My issue was custom event types permissions being 'this app' only, when they were only seen by Search app, but NOT SplunkSACIM app. I had to change them to globally shared, then the search 'tag=authentication' got them in use.

0 Karma