Being a Information Security geek for sometime I have had a significant exposure to DLP over the years and being exposed to two major vendor distributions along with processes and procedures I have found some high-level principles that should be followed.
1. Know Thy Risk – This often seems to be taken for granted, but depending upon your business model not everyones risk for data leakage will be the same. Healthcare will be more at risk for HIPAA than the Banking industry and Food Chains will be more at risk for PCI than body shops. In addition to known regulatory laws such as HIPAA and PCI you also need to assess the risk to your organization if one classification of data was leaked versus another. Once this risk assessment has been completed it will make it easier to drive priorities around your DLP initiative.
2. Data Classification – It is also important to define a Data Classification policy so that you can use this to define and drive your DLP policies. For example, you may have a Data Classification such as Highly Sensitive, Sensitive, Internal, and Public. Policy might dictate that all data identied as ‘Highly Sensitive’ must be encrypted, while data that falls under ‘Sensitive’ just needs to have strong access controls.
3. Document & Define Workflows – This is probably the most difficult aspects of DLP due primarily to dependecy upon other groups (Legal & HR) and the potential resource hours needed to manage the process. It basically comes down answering questions such as:
Who needs to be notified when an incident is created by the DLP solution? Do we need to define thresholds for the notifcations?
Who will determine if the incident is a false-positive or a real incident?
Should the data be acted upon automatically? Should we quarantine or block the data that was identified in the incident?
I’m planning on making a series of additional blog entries around various other aspects of DLP in the near future.
