Policy Tuning – A key step to a successful DLP implementation

Policy Tuning – A key step to a successful DLP implementation

DLP architecture has been finalized, network configurations have been made, firewall rules are in place, components are deployed, polices are enabled, and incidents have started to appear. Now if you think that your DLP tool has been successfully implemented, you are wrong!


Imagine getting bombarded with hundreds of incidents every day that your security team can’t keep up with. Well, that is usually the case of any DLP tool deployment without proper rules in your policies. Without implementing the right rules within your polices, a new DLP implementation will generate lots of incidents (false positives) that are not relevant to your organization. This is where the most important step in a DLP implementation comes into play – The Policy Tuning. 


Blog Policy


There are multiple ways a policy can be tuned. I will talk about three important items that you could factor in while tuning the polices:


1) Known and relevant factors


2) Multiple data type matches


3) Information from false positives


Known and relevant factors


When a policy is first created, the tendency for most administrators is to enable the policy with the default rules. Keep in mind that the default rules are set to only look for the content that the policy is built for. You might be wondering, what’s wrong it that? Well, a big step to eliminate false positives is to eliminate content matches that you are not interested in. This is where you need to add additional rules to eliminate content matches that are not relevant to your organization.


The most efficient way to start this process is to use information/data that is only relevant to your organization. For example, use fields like source and destination email addresses (*@yourcomany.com). For keyword-based matching, rather than just using a keyword such as “confidential," use keywords that are relevant to your organization – such as project code names, company name, etc. This way, the incidents that are generated will most likely be true positives and will be relevant to your specific organization.


Multiple data type matches


Most of the time, matching on just one data type is far less valuable (and generates more false positives) then matching on a combination of data types. For example, matching on just a credit card number is less valuable or less critical than matching on data that contains credit card number along with first and last name, expiry date, etc. So when creating a policy, add rules that look for more than one data type within the policy scope.


Information from false positives


After going through the above two steps, you will most likely eliminate a significant number of false positives. However, no policy is perfect, and you will always see incidents that are false positives. But the good thing is we could use this information to further tune our policies so we don’t see similar incidents in the future.


Even though you can’t completely eliminate all false positives, by spending time tuning the polices and adding the necessary rules to find content that is relevant to your organization, you could prevent true data loss and simultaneously not mpact your organization’s normal business operations.