Introduce customisation to built in DLP rules (or allow exceptions to existing rules)
We use DLP on email to assist in our PCI compliance. As an online payments provider, we often provide dummy credit card information to help our customers set up their APIs (typically 4444 3333 2222 1111). Unfortunately, despite this *not* being a valid card number, it triggers Microsoft's built in "Credit Card" definition resulting in 100s of false positives per week. We need to have this hard coded as an exception to the "Credit Card" definition, or, better yet, allow definitions to be customised and/or excluded from via. the Admin portal.
As stan mentions below, this level of customization is certainly possible. There are many other tweaks you can perform based on your specific requirements. For example, you can only look for multiple cards together, or other identifying information like expiration dates. Please review the documentation and work with support as needed.
I am using a rule to force encryption if the email contains subject line keywords. I would therefore like the DLP rules to have the ability to not create an incident if fake data as the original user mentioned or to not create an incident if one of the subject line keywords are used.
You can modify the definition or create your own xml file to exempt this number. This is done in powershell, so you need someone who knows a little bit of powershell. Here's the command to get the definitions ( I got these from various technet and microsoft sites )
$rulecollection = get-classificationrulecollection
set-content -path exportedrules.xml -Encoding byte -Value $rulecollection.SerializedClassificationRuleCollection
Now the issue is, how do you exempt that particular number? While an exception sub-element would be convenient ( refering to "Aaron Dinnage"s comment) you can do it as a regex that excludes the number you want to exclude but not valid numbers.
Aaron Dinnage commented
I'd like to see the addition in the Classification Rule XML definition of an "Exception" sub-element of the "Match" tag to ensure that the context of the matches is understood and observed. That is to say, to ensure that the positive match itself is ignored only if it then matches an exception rule as opposed to just finding an exception match somewhere else in the content (which could be achieved with the existing DLP rule configuration). Or something similar to meet this requirement.