Limitations on using field filters in your environment
Before you begin, see Plan for field filters in your organization for important considerations about planning for field filters.
READ THIS FIRST: Should you deploy field filters in your organization?
Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but it might not be a good fit for everyone.
If your organization uses downstream configurations, such as accelerated data models, Splunk Enterprise Security (ES) detections using those data models, and user-level search-time field extractions, make sure that you plan around the implications of field filters on those configurations before deploying field filters in your environment. See READ THIS: Downstream impact of field filters.
If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.
Field filter limitations
Consider the following issues when setting up your environment to take advantage of field filters.
For additional limitations about searching with field filters, see Use field filters in searches.
Federated search
Field filters can't be used to protect sensitive fields in remote datasets using federated search.
Summary indexes
Summary indexes generated by scheduled reports can expose sensitive index information that you might not want unprivileged roles to be able to access. If you collect sensitive summary index information that you want to filter with field filters, carefully consider which highly trusted roles can create those summary indexes.
By default, all reports run with the permissions of the report "owner", which is the person who created the report. To ensure that unprivileged users don't have access to sensitive data, set up your summary indexes using a role restricted by field filters. For example, if your field filter applies to the support role, you must also use the support role when you set up your summary indexes.
See Determine whether to run reports as the report owner or report user in the Reporting Manual and Create a summary index in Splunk Web in the Knowledge Manager Manual.
Example
If the role you use to set up your scheduled searches is exempt from a field filter, but your users hold a different role that is restricted by the field filter, you might expose your confidential data to people who aren't allowed to access that information.
Consider what might happen if you set up a scheduled search using the admin role, which you have exempted from a field filter that replaces the value of the host name field with a SHA-256 hash. When a user holding a role called test that is not exempt from the field filter runs a search on the index, this is what they might see:
| Time | Event |
|---|---|
| 2/28/23
10:15:00.000 AM |
02/28/2023 10:15:00 -0800, search_name=TestSummary, search_now=1646075700.000, info_min_time=1646072100.000, info_max_time=1646075700.000, info_search_time=1646075700.607, orig_host="test-mbp-571a7", action=upload_mmdb_files, psrsvd_v=1, psrsvd_gc=9, testField="testValue"
host = c1fe560f903b48c96812691329a783a9333414bbf7ac26c26bf41cebbaf79b6d |
Notice that the host name shows up in two places in the summary index. The value for the first instance of the host field is test-mbp-571a7, and the value for the second instance is a hash. In this case, using one role, the admin role, to set up the scheduled search and then running the search using a different role, the test role, that is restricted by field filters, resulted in exposing the data that was supposed to be obfuscated with the hash value.
If the same test role that is configured with field filters is also used to set up the scheduled search, this is what the user who holds the test role sees when they run the search:
| Time | Event |
|---|---|
| 2/28/23
10:15:00.000 AM |
02/28/2023 10:15:00 -0800, search_name=TestSummary, search_now=1646075700.000, info_min_time=1646072100.000, info_max_time=1646075700.000, info_search_time=1646075700.607, orig_host="c1fe560f903b48c96812691329a783a9333414bbf7ac26c26bf41cebbaf79b6d", action=upload_mmdb_files, psrsvd_v=1, psrsvd_gc=9, testField="testValue"
host = c1fe560f903b48c96812691329a783a9333414bbf7ac26c26bf41cebbaf79b6d |
Now both instances of the host field in the summary index are obfuscated with the hash value. As a result, sensitive data about the true value of the host name is no longer exposed to unprivileged users.