Protect sensitive fields in DMA-summarized data

Prevent original field values from being written into new summaries

If your security goal is to prevent original sensitive values from being written into DMA summary files, make sure to implement use case 1, so field filters are applied during the data model acceleration search.

None of the roles used by the internal system account for background DMA summary generation can be exempt from the field filter that protects the source field. If any of the internal system account's roles is exempt from a field filter, the field filter is not applied to DMA summary generation searches and sensitive data can be written into the .tsidx files that store DMA summaries on disk.

In a default environment, the roles associated with the internal system account are user, power, admin and splunk-system-role. To determine which roles these are in your environment, run the following search:

index=_audit action=search info=completed id="DM_search*" search_id='scheduler*' | head 1 | table roles | eval clean_str=replace(roles,"'","")  | eval list_roles=split(clean_str,"+") | table list_roles

The results of this search in a default environment look like this:

To prevent original values from being written into summaries, make sure the admin, power, splunk-system-role, and user roles are not listed as exempt roles on any of your field filters.

See Exempt certain roles from field filters using Splunk Web.

Protect data returned from existing summaries

If your approach follows use case 2 and your DMA summary already contains original sensitive values, configure the field filter on the DMA summary field name that tstats reads. This protects tstats search results for non-exempt users even when the summary was created before the field filter was created and applied.

Field filters in this use case protect the values returned by searches. They do not remove original sensitive values that already exist in summary .tsidx files on disk. If those original values must not remain on disk, rebuild the accelerated data model summary after configuring field filters for summary generation, or wait for the summary to be rebuilt or aged out.

Use role-based access control (RBAC) to restrict access to accelerated data model summaries that still contain original sensitive values. Be especially careful with field filter exemptions as a role that is exempt from a field filter can see original sensitive field values from an existing summary.

Control access to non-summarized sensitive data

If you need specific users to access sensitive fields in non-summarized data while still protecting DMA summary generation, create a new role for those users. The new role can inherit from a predefined role such as admin, power, or user.

Then, exempt the new role from the field filter. Do not exempt the roles that the internal data model acceleration search uses if you want summaries to be built with replacement values. Following this recommendation gives selected users controlled access to original values in raw searches while allowing the DMA summary generation path to write replacement values.

Use role-based access control (RBAC) for sensitive data on disk

Use RBAC in addition to field filters when sensitive data exists in DMA summary .tsidx files on disk.

If a summary was built before field filters were configured, or if the summarization search ran with an exempt role, original values can remain in the summary. A field filter can hide those values from non-exempt search results, but it does not remove the values from disk and it does not prevent exempt roles from seeing them.

To remove original values from a DMA summary, rebuild the accelerated data model summary after configuring the field filter so it applies during summary generation, or wait for Splunk software to rebuild or age out the summary according to the configured schedule. Manually rebuilding a summary can be resource-intensive and might affect the performance of other running processes. For instructions, see Manage data model acceleration.

Test your use cases before rollout

Test your DMA summarized data and field filter configuration before deploying field filters to production environments to make sure that none of your sensitive data is unintentionally exposed. Include the following tests:

• Run the same tstats search as a non-exempt user and as any exempt role.
• Test summariesonly=t and summariesonly=f behavior if users rely on both modes.
• Verify the exact field name returned by tstats, including dataset-qualified names such as dataset.field.
• Verify that ES detections, dashboards, alerts, and other downstream searches still produce the expected results after field values are replaced.
• Confirm whether original values remain in existing summary files and decide whether RBAC, summary rebuild, or both are required.