Next to NAC (Network Access/Admission Control), DLP (Data Loss/Leakage Protection/Prevention) is the second most abused acronym in IT. You know there is a problem when there isn’t an agreed upon meaning to a simple TLA (Three Letter Acronym). It turns out the source of the confusion is technology. It’s the last thing you need for DLP; not the first.

At Nemertes we’ve just completed an in-depth security benchmark, involving all shapes and sizes of organizations with 23% financial services representation. Despite confusion over a DLP definition organizations we work with are clear on what they expect of DLP (in order of importance):

• Preventing exposure of Intellectual Property (IP)

• Preventing exposure of personally identifiable information (PII) or
• personal health information (PHI)

• Helping to manage risk by adding a potentially strong preventive and detective control
• Preventing general exposure of corporate information

Preliminary results indicate nearly 40% of organizations are now implementing some form of DLP, which tells us more about the breadth of the DLP definition than about any specific technology adoption. My expectation was much lower, given the squishiness of DLP definition. And, to this point DLP covers everything from AV and email scanning services like MX logic and Postini to full encryption of data in motion and at rest with products from companies like Credent Technologies or Check Point (PointSec). Essentially, any technology that stops, alerts or obfuscates data falls into the - way too big- DLP bucket.

Herein lies the root problem: DLP (whatever it is) is seen as a product/technology when it should be a process. In fact, maybe the “P” in DLP should be “Process.” A great first step in defining the DLProcess is to learn from e-discovery, a topic I wrote about last month.

Though not obvious, DLP and e-discovery are really the same function (just turned around) with many of the same issues. e-Discovery requires locating specific data according to pre-determined search criteria. The data may be in any format (database, email, vmail, video file, IM log, encrypted, unencrypted, etc.) and any location (desktop, server, archive, USB drive, etc.). Similarly, DLP is the prevention of data loss according to pre-determined rules (search criteria) and the data may be in any format and in any location.

It’s the rules, format and location that create challenges for both functions: With e-discovery you often don’t know exactly what you’re looking for – or where to look - until you find it and with DLP it’s nearly impossible to monitor every egress point and create enough rules to catch all IP, PII or PHI. So, as with e-discovery successful DLP requires separation of the data from the medium and the location. The DLProcess must start with identification of PII, PHI and IP, independent of location and format. It doesn’t matter if my mental condition is noted in the HR database, an email that HR sends to my supervisor or the urgent vmail she leaves for building security. All that matters is I need protection of these data. Period.

This is a fundamental shift in thinking about DLP, but once done the process definition is a relatively straightforward….process: Defining processes and roles to flag PII, PHI and IP at the source and to protect these data as they live and move within – or outside - the corporate environment. Technology’s role is to facilitate the implementation, management and monitoring of these processes and not the other way around.