DLP Myth #6: The "perfect" DLP solution exists

Again, I'll take some heat from a number of vendors because of this post, but it's something I've said before and DLP buyers need to be aware of it.  In the past, I've spoken of the "perfect" DLP solution, but it's unfair of me to use that word.  So, I'll retract the word "perfect" and simply say there is no DLP technology that addresses all of what I consider to be key requirements of DLP.  But if there were a perfect DLP product, it would meet all of the following:  

1. Provided by a stable and viable company.  It's critical for a DLP buyer to be confident of a vendor's ability to support their product in the long term.  DLP costs are generally too high to make a switch a year or two into it.  I'll admit that this is much less a concern today than it was a year or two ago as most of the major indepedent DLP vendors are now part of much larger organizations, the latest is Vericept being acquired by Trustwave (when Vericept was really on the ropes).  However, there are still two independent DLP vendors listed in the 2010 Gartner Magic Quadrant that haven't seemed to be able to generate any acquisition interest and that I don't see often enough in the marketplace to believe they have the revenue to be self-sustaining.  I won't mention their names in this post, but it's not Fidelis or Code Green. 
2. Includes coverage for all three main DLP components:  gateway (data-in-motion), endpoint (data-in-use) and discovery (data-at-rest).  There are some great DLP core technologies out there, but unless these are combined with all three DLP components through a single web interface, I wouldn't recommend them.  This puts vendors like Palisade, Fidelis (both gateway) and Verdasys (endpoint) at a real disadvantage.  All the technology partnerships in the world--Fidelis + Safend, Verdasys + Fidelis (explain that one to me)--just won't cut it.
3. Provides a single web-based user interface to manage all three components, including data registration, policies, reporting and administration.  As mentioned above, this is a critical component which can't be overstated.  I've never had a client who has been accepting of registering data, creating policy, running reports and managing the solution through two or more interfaces.  When we talk about duplication of efforts, this is it!
4. Includes prevention capabilities across all protocols, not just select protocols of Web, FTP and email.  I believe this to be the single largest deficiency of the major DLP products.  It's a tough one; the marketplace largely has come to accept that the only protocols you can actually block are SMTP, FTP, HTTP, HTTP (and some IM).  Take note, however, there are a couple of products in the marketplace that have the ability to block any/all protocols, including some widely-used ones like P2P and IM or even unknown TCP.  Both Fidelis and GTB make this claim and if either vendor did not suffer from other deficiencies on this list, I might be able to back them.
5. Provides a combination of data registration and content analysis techniques that are accurate and effective.  While most of the majors provide these data detection techniques, there are a few who are still working on one or the other.  In order to be fully effective, a DLP solution must provide a combination of these detection techniques.  And watch out for the "channel DLP" and "add-on DLP" vendors.  Many of them are limited in their detection capabilities. 
6. Has a simple architecture which does not require a server/appliance for each component (monitor, prevention, manager, etc.).  Again, this is an area where the marketplace has come to accept the fact that DLP is just complex.  But it doesn't have to be.  Among full-suite vendors (gateway, endpoint, discovery) who have taken a simplified architectural approach are Code Green and GTB (both single appliance approaches).  Even the more traditional DLP solutions (read: complex) like Symantec and RSA are looking for ways to simplify their architectures in leveraging virtual machines.  Be careful with the VM approach, however.  Remember that these multiple components (monitor, email prevention, web/FTP prevention, endpoint, discover, etc.), even as virtual instances still act as standalone servers and must communicate/integrate with each other.  They may reduce the number of devices on your network, but may not really simplify the complete package.
7. Does not utilize expensive modular pricing approach for each component (monitor, email prevention, web/FTP prevention, endpoint, discover, etc.).  DLP has proven to be an expensive technology, especially among the elite solutions.  However, there are effective and reputable solutions that do charge buyers for each individual component.  These solutions provide a simplified licensing approach that also happens to provide greater cost savings.

So, these are my big seven requirements.  To date, no one company meets them all.  There may be two vendors who could rise to meet them, either by becoming more financially viable (acquisition?) or by simply putting some effort into developing the one component they may be lacking. 

In fact, I'm surprised by a couple of vendors who fought the marketplace at a critical juncture and stubbornly held to a gateway-only or endpoint-only approach.  I remember conversations at RSA 2008 with the VP sales at one endpoint vendor and the Founder/CEO at a gateway vendor where I was told emphatically, "We will not build a gateway component; everything can be done through the endpoint," and "We will not build an endpoint; everything can be done throught the gateway," respectively.  As much as I understand (and appreciate) the desire to believe in your product and direction, if one of these vendors had given in and built the missing component a few years back, they might be sitting in the catbird seat today, in the far upper-right of the Gartner MQ enjoying a revenue-leader position.  Then again, maybe not.

DLP Myth #2: DLP is Architecturally Complex

A common misconception is that DLP must always be archtiecturally complex.  This myth has roots in reality; traditional DLP techonologies have been architecturally complex.  However, as DLP technologies evolve, there is a move toward greater archtitectural simplicity.

To understand how we go to the architectural complexity, consider the origins of data loss prevention:  built for the world's largest enterprises and with an immature roadmap that was a moving target in early years.  Original DLP technologies were really DLD, data loss detection.  They were designed first as passive network monitors looking for patterns matching simple expressions such as for social security and credit card numbers, but there was no blocking involved.  As companies saw data leaving the organization, it didn't take long for the next requirement to come to light:  blocking.  Then came discovery, endpoint and so on. 

Most early vendors employed a modular, multi-server architecture, which is typical among the .  This gave them the ability to develop one server component at a time as market demand required, rather than bring everything together under a single server.  The results were shortened development times.  Plus, it allowed early adopters to get their feet wet with the new technology, one component at a time. 

A key side benefit of the modular approach was that it spread the load among many servers, keeping the network monitor free for the all-critical task of identifying sensitive information.  It was an unspoken concern that an overloaded network monitor could "slip," allowing sensitive data to get by without being seen.  This was an especially important concern to address among the early adopting large enterprise, who have a tendency to run at bandwidths that can overload packet filters.

This evolution resulted in DLP architectures that require many servers:  management server, network monitor, database server, email blocking server, web blocking server, discovery server, endpoint management, etc.  Couple this mult-server approach with separate integrations for mail transfer agents, ICAP proxies, databases, active directory, etc., and you end up with a very complex architecture.

Contrast this traditional DLP architecture with the concept of a single appliance that combines everything required for a complete DLP suite:  network monitor, management interface, incident database, web and email blocking, discovery and endpoint management.  This is the approach of a couple of DLP vendors.  And even the traditional DLP vendors normally requiring 4-5 servers are reconizing the need to simplify with single appliances running 2-3 DLP components as virtual machines.

DLP does not have to be architecturally complex.  Some vendors have developed simple architectures combining components in single appliance, while others are leveraging virtual machines to make their architectures more steamlined and easy to deploy.

DLP Myth #1: You can get DLP as an add-on to an existing solution.

I read a blog post today from Midwest IT Professional entitled Myths of Data Loss Prevention (DLP).  The post didn't really address the kind of thing I consider to be myths about DLP, but it did get my thought process going.  So, over the coming days, I'll present a series of myths related to Data Loss Prevention.

The first myth I'd like to address came in the form of a firewall/UTM vendor announcement about the growing demand for DLP.  The quote that accompanied the press release stated:  "Today, customers can have both state of the art multifunction firewall protection and unbeatable Web, messaging and DLP security that is affordable, powerful, highly reliable and easy to use."  

From this, I pull myth number one:  You can get effective DLP as an add-on to your firewall, web or email security solution.  While some rudimentary data loss prevention functionality can be added to most any network security device, its effectiveness may often do more harm than good.  

Most add-on DLP functionality comes in the form of scanning network traffic (web, email, other) and looking for simple regular expression pattern matches for social security numbers, credit card numbers, etc.  This content monitoring capability has been around for many, many years, however in my experience it has been ineffective and in many cases counterproductive.  

I had one client, for example, who tried to use their leading email security solution to identify and block incidents of sensitive data leakage using regular expression patterns.  They went this route initially to avoid having to buy a purpose-built DLP technology--trying to save some money in this tough economy.  What they found was that the rudimentary content monitoring and filtering technologies did a poor job of identifying *true* incidents of data leakage.  They ended up with more incidents each day than they could keep up with and since the vast majority of the incidents were false positives, they stopped looking at them altogether.  I won't go into detail about why this just doesn't work.  Just give it a try with your own email security solution and see the results for yourself.  

In addition to the fact that regex patterns alone are ineffective, consider the fact that in most cases, an SSN alone does not constitute a data breach.  Most regulatory or legal mandates state an SSN when accompanied by other data points that together make an individual "personally identifiable" (hence the term PII--personally identifiable information).  True DLP technologies have the ability to do much more than just pattern matching.  In fact, a key feature of most every major DLP technology includes the ability to do "exact matching" of specific individual data fields.  This means that a rule can be established that when an SSN combined with other data fields *from the same database record* are seen in a single communication, this will trigger an incident.  So if it's my SSN along with the name Steve Smith (not my name), that won't trigger.  However, if it's my SSN along with my name, it will trigger.  This exact matching capability is critical to effective data loss prevention and adding "DLP" to your basic firewall, web or email security device just may do more harm than good.

Other data loss prevention (DLP) myths to follow!