A user need to create one or more Data Protection policies and would like to know the best practices to creating these policies to minimize the policy evaluation time.
When creating a web data protection policy, it is strongly recommended to look for opportunities to combine multiple policy rules into one policy rule with multiple conditions where possible.
Within a policy rule, the conditions should be ordered from least expensive to most expensive to evaluate so that as soon as a condition is not met then that policy evaluation can end without having to wait for the remaining conditions to be evaluated (assuming that the policy requires that all of the conditions specified have to be met). This will help to minimize the policy evaluation cycle time and any data processing delays.
The conditions below are listed from least expensive to most expensive without any content evaluate
File Upload is Spoofed
File Upload is Password Protected
File Upload Size
File Upload is Present
Destination URL Category
Destination URL Category List
File Upload MIME Type
File Upload Filename List
Destination URL List
Content URL List
Content Keyword List
Content Regular Expression List
The content regular expressions (Regex List) are the most expensive to evaluate therefore it is recommended to place it as the last condition in a policy.
In a scenario where a web data protection policy has multiple Content Regular Expression conditions and these are set to execute the policy if "ALL CONDITIONS ARE MET".
Symantec recommends to add any of the least expensive condition first (if required), followed by a Content Regular Expression condition to check if the web traffic is a POST HTTP request by looking in the headers of the web request.
If the first conditions are not met then the policy evaluation can end without having to wait for the remaining conditions to be evaluated.
To learn more about each condition and what to look for in the web request when inspecting outbound traffic, see About Conditions and Web Data Protection.
Before proceeding to create any web data protection policy make sure to ask your self are you trying to block/allow a URL or content inside the URL including POST or GET requests?
If you are simply trying to block/allow URL please use URL filtering to create the policy. URL filtering is much faster and more accurate for this type of action. Data Protection policies are meant to block data leakage from within a company.
In the situation where you need to implement Data Protection policy to block a URL using lists keep in mind the following:
1) In URL filtering policies, we'll automatically add a "*" (wildcard) to the string that the customer specify so that saying "www.domain.com" will be compared with an arbitrary string as if you had specified "www.domain.com*". In Data Protection we don't add anything to the string that the customer specified and will just pass that string as is to the regular expression engine. If you need to block everything from domain.com you would need to explicitly state "www.domain.com*" .
2) When creating a list it states "Note that the “/” and “\” characters cannot be used in a list." in Client Net. This statement is incorrect and we are working to correct this. You are allowed to use "/" but not "\". Since Data Protection uses regular expressions, the "\" character is used to "escape" other characters so it cannot be used or if it was meant to be interpreted literally then it has to be escaped itself (i.e. "\\" when you want to say "\").
3) Don't use any leading wildcards. For example Any http://*<ip>/ pattern should be changed to remove the leading wildcard (which serves no purpose and is very long to evaluate) and add a trailing wildcard if required, e.g. http://*18.104.22.168 -> http://22.214.171.124/*
Any http://*www.<domain>/ pattern should be changed to remove the leading wildcard as well (www is a top-level domain), and add a trailing wildcard if required, e.g. http://*www.domain.com/ -> http://www.domain.com/*Note that the system does not check that the policies you create are logical. You can enter a combination of conditions that contradict each other and are ineffective. We recommend that you analyze your requirements carefully before creating your policies. You should also test your policies to ensure that they deliver the results you expect.