Search-time order and DMA

Since field filters process field values in searches before all other search-time operations and change the values of fields extracted in data model searches, operations that come later in the search pipeline and depend on the value of the field that is changed by a field filter are affected. As a result, if you're running DMA searches, be aware that you might get search results that you don't expect. For example, say you have a data model called DM_search_xintestdm10 that uses the following summarization search to create summaries to detect malicious users:

| summarize tstats=t override=partial manual_rebuilds=f max_time=3600 poll_buckets_until_maxtime=f id=DM_search_xintestdm10 [  search (index=* OR index=_*) (index=xintest2) | eval nodename = "xintest"| eval malicious_user=if(searchmatch("val=86"),"true","false") | rename Code AS xintest.Code malicious_user AS xintest.malicious_user | fields nodename, _time, host, source, sourcetype, xintest.Code, xintest.malicious_user ]

When this summarization search runs without a field filter, the malicious_user field evaluates to true, alerting you to a possible security breach.

Then, you create a field filter on the sensitive field called val. When the DM_search_xintestdm10 data model's search runs with the field filter on the val field, the result of the search command is the redacted value, which is a value other than 86. When the next command in the pipeline, the eval command, evaluates the val field to the redacted field value, the malicious_user field is now false. Now when you have alerts with tstats searches on the accelerated data model set on the malicious_user field that trigger on true instead of false, you might not be alerted and, therefore, miss potential security breaches.