How do I restrict search terms (securely)?

[mkolkebeck]

Scenario: Let's say I have a single index (e.g., main) containing data of interest to multiple different parties/roles, and it is understood that Role1 should only see all data with type=t1 in it, Role2 should only see type=t2, and Role3 only type=t3, etc.

For Role1, if I set my restrictions to the following:
index=main type=t1

And a user creates a calculated field with the following definition:

• Apply to = source
• named = *
• Field name = type
• Eval expression = "t1"

This user will be able to see results for all of index=main, since the user's search-time extraction of type=t1 will now be true for all sources.

Question: How do I securely restrict search terms such that it cannot be circumvented by the user's search-time knowledge objects, like calculated fields?

Related post (but I find the answer is not secure):
https://answers.splunk.com/answers/75912/restrict-search-terms-conditionally-depending-on-the-index-...

[woodcock]

It is poor security. If you have the CPU and Disk space, the disallow everybody from the main index and split it into separate Summary Index values as it comes in.

[ddrillic]

An index is the entity on which the security framework of Splunk is being built. Therefore, maybe you can find out whether this single index which needs to be shared, can be broken down to multiple indexes and build it from there.

[mkolkebeck]

I don't disagree with your comment. My biggest concern is that the Restrict search terms feature is not clearly displayed as insecure if leveraging search-time fields, and I have not seen a Splunk Answers post or Splunk Documentation that clearly warns against using this feature with search-time fields.

Also, I would look to separate this data into distinct indexes if I could, but many times it's not easily separated out at the source. You could use a transform to route the data, but it adds a performance hit to the indexers. Also, if there is overlap in what Role1 should see with what Role2 should see, such as network communications, there is no easy way to do this without using this feature. One could use summary indexing, but then that transforms the original data and default fields, it requires more storage, and it leaves the potential for gaps if the scheduled searches are skipped.

[mkolkebeck]

Use of the Restrict search terms feature on a role definition should be limited to the following:

• index-time fields, using the indexed-field notation such as sourcetype::value
• search strings, such as "type=t1" or "type=\"t1\"", as opposed to search-time fields like type=t1 or type="t1"
• combinations of the above using OR, AND, or NOT

I have only found index to be the only indexed field where you don't need the indexed-field notation, where as default fields like host, source, and sourcetype can take on a user-defined calculated field.

As a user, you can easily spot if your searches are being filtered using this method by running a search, such as index=*, and click Job > Inspect Job, click Search job properties, and identify potential search-time fields within remoteSearch.