The "All recipients must match" setting in DLP Recipient Matches Pattern group rules and exceptions is not working in DLP 16.0 MP1

Products

• Data Loss Prevention
• Data Loss Prevention
• Data Loss Prevention Enforce

Issue/Introduction

An issue was introduced in DLP 16.0 MP1 where either the "All recipients must match (Email Only)" or the "At least N recipients must match (Email Only)" where N is greater than 1 setting in the Match Counting section is paired with the "Check for existence (don't count multiple matches)" setting. The group rule or exception will not trigger in this case leaving either missed detections or false positive incidents.

Environment

Release : 16.0 MP1

Cause

A change added to 16.0 MP1 caused this behavior.

The recipient matching can contain a conflict between the "Check for existence" in combination with either "All recipients must match" or "At least N recipients must match" where N is more than 1.
16.0 MP1 attempted to resolve this conflict by just matching "At least 1 recipients must match" when "Check for existence" is selected causing the selected match option to be overridden by the "existence" option.

Resolution

Attached is the 16-0-ExistsVsCountconflicts.sql script that returns the policies and rules where the above conflict exists and will need to be updated to avoid this conflict.
This shows which type of conditions have the conflict (2 Recipient Pattern and 13 Recipient DGM), the policy and condition names, if it's used as an exception, and if it's part of a compound condition group.
If the SQL results show type 5 then please install 16.0 MP1 HF1 or later, any other type besides 2, 5, or 13 are not expected to exist and should be reported to support.

Using the list of type 2 and 13 conditions returned by the script above, you can manually update them in the policy from "Check for existence" to "Count all matches".

While using "Count all matches" is the only current workaround, it does cause a side-effect to non-exception rules which returns all recipient matches instead of just the first match which also means a higher condition match count. This only really matters for when the recipient condition is part of a compound rule condition that has severity thresholds that relies on that the recipient count only every returns 1 of its matches so that the other condition in the rule drives the severity threshold. These specific recipient conditions that will have this side-effect of the workaround will temporally have to deal with that the severity will be pushed higher due to higher rule match count. The fix for this issue (to be made available on MP2 and RU1) will allow switching these policies back to "Check for existence", for the original expected behavior from the 15.x release branch.

Exceptions conditions don't return their matches in the first place so they can use this workaround without any side effect.