*  I just re-read this post that goes back two-plus years.  It’s interesting to see how things have changed–and what remains the same.  I’ll post later this week with my thoughts on ending the data loss prevention debate.

Ending the Data Loss Prevention Debate?  April, 2008

What do Symantec (Vontu), Reconnex, Fidelis, Websense, RSA (Tablus) and the rest of the DLP vendors all have in common?  Not nearly enough.  At least not enough to conclusively call a winner in the battle of DLP technologies.

I spent last week in San Francisco at the annual RSA Conference with the primary goal of getting answers to questions and concerns I have regarding the data loss prevention (DLP) market and the claims and approaches of each of the many vendors.  I was amazed at the extreme opposing viewpoints of different vendors over a number of key technological points.  I walked away with the continuing conclusion that the different platforms, technologies and features are still largely unproven. 

All that notwithstanding, DLP is certainly proving its value.  That’s clear from speaking to organizations that have deployed DLP technologies and many of those that haven’t, but now wish they had!  Any organization with data essential to its operation—whether its own intellectual property, customers’ personally identifiable information, protected health information or non-public information—needs to ensure that it remains safe within the confines of the company’s protected network. 

While I heard a lot of interesting claims as I engaged sales and techs alike at RSA, there were three points on which a number of vendors argued quite forcefully with me.  They were:  the endpoint versus network; stand-alone versus integrated network devices and fingerprinting versus content analysis.

Endpoint or Network?

There are two major camps on the question of where to start monitoring for sensitive data:  the endpoint and the gateway.  While most companies acknowledge the need to address both ends, there is at least one endpoint vendor that doesn’t.  I was told by this vendor that they have no plans to build or OEM a gateway device.  From their perspective, everything can be done more effectively at the endpoint.  A very bold statement, indeed, but one I happen to disagree with.

For the other vendors who take a softer approach on the subject, the preference typically still falls in line with the vendor’s roots.  If the vendor started building DLP gateways, then they very likely favor gateway devices, allowing for the endpoint to handle the “less essential” functions of protecting data in use.  If the vendor started as an endpoint solution, then they likely favor starting at the endpoint, using the gateway device to identify anything the endpoint may have missed.

While it’s true that an endpoint solution has the ability to see everything that the gateway may eventually see, the fact is that most security professionals would rather stick an appliance in the rack rather than perform a rollout of software on every single workstation in the company. 

Regardless of the angle, the fact remains that not all essential data will leak via the network nor will all of it leak at the endpoint.  The first step in any DLP initiative is a risk assessment to determine the extent of the problem—who is sending what to where and how?  From my personal experience, this is most quickly and easily accomplished at the gateway.  From there, the deployment should certainly include software at the endpoint as well as a discovery module to identify where the essential data resides in the network.

Stand-Alone or Integrated Network Device?

One commonly overlooked aspect is whether the gateway device should be a stand-alone appliance or integrated with other network devices.  The question seldom comes up simply because there are very few vendors in the space who have built products that can not only detect sensitive data, but also prevent it from leaving the network.  This may come as a surprise to most people interested in DLP, but nearly all of the available solutions in the DLP marketplace require other devices in order to prevent (or block) more than just SMTP. 

This typically comes in the form of an in-line proxy device—either from a third-party vendor or from one of the DLP vendors themselves.  These devices are typically limited to preventing only the most basic network protocols of HTTP and FTP (and HTTPS if the device can handle SSL certs).  This still leaves open a number of widely-used protocols as well as generic TCP traffic.

If your company already has a proxy infrastructure, this may be a moot point as you’re able integrate the DLP solution with the proxy device.  If proxies are not a part of your current infrastructure, you might consider one of the vendors who provide integrated enforcement on a single device.

In either case, it pays to address this issue up front before you get too far down the road in evaluating the different DLP vendors.  Ask this question:  How can your product effectively block all protocols—including generic TCP—at the gateway?

Fingerprints or Content Analysis?

Each vendor must identify sensitive data in order to effectively function as a data loss prevention solution.  There are two general methodologies used to identify sensitive data:  data registration, where known sensitive data is logged and stored in a database using a digital fingerprinting process and content analysis, where sensitive data is identified on the fly based on content and/or context.  Here are a couple examples of both technologies in action:

Example 1:  A financial institution wants to protect their customer database of personally identifiable information (PII), such as name and credit card number.  They elect to fingerprint their customer database, including first and last name and an account number that varies between 5 and 8 digits.  They create a policy that prohibits the sending of first and last name and social security number such that when the DLP solution sees the exact matches of “Jared Thorkelson 123456” in an email transmission, it takes action and blocks the email.

Example 2:  A large retailer wants to protect their customer payment card data before it reaches their main database.  They choose to use the content analysis tools of their DLP solution to watch for generic credit card numbers.  They create a policy that prohibits the sending of credit card numbers such that when the DLP solution sees a number “4444 4444 4444 4444” which matches the DLP solution’s regular expression for a Visa Card number in an email transmission, it takes action and quarantines the email.

The examples above show situations where one data identification method works far better than another.  In the case of Example 1, it is impossible for a content analysis tool to consistently and correctly identify a first or last name and to distinguish between an account number and any other 5- to 8-digit number.  In Example 2, it is impossible to fingerprint data before it reaches a database, so a credit card regular expression works best.

Most DLP solutions use some level of both methods for identification of sensitive data since certain methods are simply better suited to different types of data.  I was surprised to hear one vendor dismissing fingerprinting technologies altogether and another downplaying the benefits of content analysis.  Get the low-down from your DLP vendor on their different detection methodologies.

Conclusion

There is no right answer to any of the different vendor claims.  No vendor technologies, platforms or features can be proven superior to another’s largely because the technology is so new and very few organizations have tested more than a single vendor’s product.  I guess that may be the natural course of all new technology.

It pays to do your homework and to invest in outside DLP expertise before venturing down your own DLP project road.