What DLP Policy Group Rule configurations are supported?
search cancel

What DLP Policy Group Rule configurations are supported?

book

Article ID: 393032

calendar_today

Updated On:

Products

Data Loss Prevention Data Loss Prevention Enforce

Issue/Introduction

The steps below indicate an example scenario that you may encounter when adding a rule under the Group tab in a DLP policy and clarifies which configuration is supported and which may lead to problems. 

  1. You are creating a DLP policy and want to add a group rule in the Groups tab. You are hoping to add a rule such as protocol, Data Identifier or one of the many other types of rule that DLP offers
  2. On clicking Add Rule or Add Exception however, you notice that the range of available rules is more limited compared to when adding a rule in the Detection tab: The only rules that appear as initial options are those based on Sender/Recipient or User Group membership see the screen shot example below: 



  3. On adding such a rule however, you also notice that you are able to add an additional match condition from the drop down menu that contains the full range of DLP rule options, so you go ahead and add the rule criteria that you'd originally wanted. 
  4. After configuring this you are left with a Sender/Recipient/User Group rule that is AND'd with another rule that you originally desired (eg. a protocol, data identifier, index or some other rule)
  5. At this point, you may be tempted to delete the original Sender/Recipient/User Group rule, leaving only your preferred rule as the only rule in the Group. The console will allow you to save the policy and does not throw an error. However, see the Resolution section of this article for why this may be problematic.

 

Environment

15.x 16.x

Cause

DLP Enforce console loophole

Resolution

If you configure your Group Rule up to step 4 in the Issue/Introduction section above and save it -  your rule is compliant and in a supported state.

If however you continue on to step 5 you will have exploited an Enforce console loophole and created an unsupported Group Rule. 

See below for some supported and unsupported examples as they will appear in your Enforce console: 

Supported Configuration:

  • Group Rule contains only a Sender/Recipient or User Group based rule (example below)



  • OR... Group Rule contains a Sender/Recipient or User Group based rule that is AND'd with another rule (example below AND'd with a Protocol rule):


Unsupported Configuration

  • Group Rule contains any rule that is not Sender/Recipient or User Group based either stand alone or in AND'd with other non-Sender/Recipient/User Group based rules. Example below is a standalone protocol rule:

Additional Information

What does 'unsupported' mean in this context?

Unsupported means that although you may get the expected results on testing the policy, its behaviour may change after an upgrade or patch. This is because the described configuration is not anticipated and therefore not a tested scenario during DLP product development. If you encounter any issues with such a policy, you must return it to a supported state and retest before contacting support if the observed issue is still present. 

What should I do if I see policies in my DLP console are configured in this way?

Option 1: Leave the policy as it is.

If it is currently working as expected you can leave the policy alone BUT make a careful note to re-test it for expected behaviour after any hotfix, maintenance pack or upgrade is applied. 

Option 2: Bring the policy into compliance

This can be done EITHER by:

1. Removing the Group Rule entirely and adding the desired rule as an AND'd rule with each rule that you have under the Detection tab. (This may be cumbersome if you have a large number of detection rules). OR…

2. Including a supported Sender/Recipient/User Group rule in the Group tab rule that is so broadly scoped that it will encompass all your outgoing data scenarios. The screen shot example above uses a company's email domain as a sender pattern to encompass all outgoing email messages and an IP range example that would encompass all of the example company's sender traffic if they were using a 10.* range.