Keys to Data Loss Prevention (DLP) Success

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.

Backtrack 5 & Scapy Python Dependecies

Have not blogged on any security-related topics in a while so I thought it was time. Scapy is a Python-driven program for generating TCP/IP packets on the fly and programtically. If you fire up Scapy on a fresh Backtrack 5 system you will be welcomed with two dependency errors; one complaining about the GNUPlot Python library and the other for PyX. I think there was another one for a GUI library, but can’t seem to find it in my Bash history.
Like most things Ubuntu/Debian the fix is pretty trivial:

apt-get install python-scitools python-pyx

There you go, happy packet hacking!