Preventing Data Loss = DLP + ICAP Proxy

Aside from a few new features each year, the core of the Data Loss Prevention marketplace has been pretty well baked for a number of years. That's why it surprises me still to hear new buyers of DLP frustrated to find that they will need to have an ICAP-capable proxy in order to block sensitive data leakage via HTTP (and HTTPS, FTP). This is true of leading DLP vendors Symantec, RSA, McAfee, Websense and Code Green Networks, among many others.

Some of these vendors have their own proxy solutions, while others rely on one of many available proxy solutions that support ICAP (Internet Content Adaptation Protocol). ICAP, simply put in DLP terms, is a protocol that allows a proxy to communicate with a DLP solution to provide visibility and blocking for HTTP/S and FTP. ICAP is a feature found on many commercial (and even open source) proxy solutions.

So, why does blocking HTTP require an ICAP-capable proxy? The proxy accepts and holds the request to be inspected by the DLP solution. The proxy uses ICAP to pass the request to the DLP solution for inspection and the DLP solution returns its response via ICAP. If sensitive data is detected per DLP policies, the proxy does not forward the request. If sensitive data is not found, the proxy sends the request along normally. All this happens in milliseconds with no perceivable latency to the end user.

The proxy also provides two additional and critical features for the DLP solution:

• Username. The proxy passes the Microsoft Active Directory username to the DLP solution so the incident shows the end user information rather than an IP address. This saves precious time and energy in handling a data breach.

• HTTPS. Most ICAP proxies have the ability to open SSL-encrypted communications. This allows the DLP solution to not only inspect communication with websites such as Gmail.com, but also facilitates blocking when sensitive data is detected. 

For companies with an existing proxy in place, adding data loss prevention technologies presents little added concern. But what if your organization is proxy-free? Will you have to pony up budget dollars for a proxy in addition to DLP? Probably so, if you intend to block sensitive data leakage via the web. But, before you get too bothered, consider these points:

• Companies rarely come out of the DLP gate blocking. It's recommended to run in monitor-only mode for a period of time prior to blocking. This allows you to tune policies for accuracy in anticipation of blocking in the future. What this means is that most companies have a time lag between the monitoring and blocking phases of their DLP project. So, don't stress it if you can't put the DLP and Proxy purchases in the same budget period. The ICAP proxy purchase can still be made down the road.

• Proxies provide other benefits. Most major proxies now provide full Secure Web Gateway (SWG) protection and provide plenty of benefit outside of DLP. In fact, many companies are considering SWG solutions for their non-DLP capabilities. URL filtering is delivered very competently using a proxy. And given that malicious code is often delivered via the web, it can be a huge benefit to have this additional protection at the gateway, making DLP integration just a nice plus.

• An ICAP proxy doesn't have to be expensive. A number of open source proxies are available that support ICAP for DLP integrations. If you're not averse to Linux and open source, one of these may meet your requirements. In my experience, however, open source proxy solutions are not as full-featured as their commercial counterparts. This is especially true when considering the full breadth of Secure Web Gateway solution capabilities. You get what you pay for, right?

Given the need to secure the gateway, for my money it's best to go with an ICAP-capable proxy that supports full SWG capabilities. Below are some of the leading ICAP proxy vendors in the space. Keep in mind that while these vendors support ICAP, the specific implementations may differ, resulting in varying results with different DLP vendors.  

• Blue Coat. By far the leading proxy/SWG solution on the market. Not only do 85% of FORTUNE Global 500 companies use Blue Coat, the company also provides solutions that scale downward to support very small installations.
• Cisco IronPort. Cisco's IronPort Web Security Appliance supports ICAP.
• M86 Security. M86's Secure Web Gateway solution is best known for protecting against malware with its real-time code analysis technology. Company sources say they plan to support ICAP for DLP by Q1 of 2012.
• McAfee. The McAfee Web Gateway (Webwasher) supports ICAP.
• Symantec. The newest version of Symantec Web Gateway provides SSL visibility.
• Websense. While Websense can provide their SWG as a standalone solution, the company promotes TRITON, providing a single intergrated solution for DLP, SWG and email security.  

Before delving into a data loss prevention project, consider whether you intend to block HTTP/S and FTP. If so (and most companies do), be sure to plan and budget for an ICAP-compatible proxy. By selecting a proxy that provides critical web gateway security, you'll be able to address DLP blocking while also improving network security. 

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! 

False Positive "Rates" of Data Loss Prevention (DLP) Solutions

I saw an interesting request posted in a DLP discussion group today asking for the false positive rates for some of the top DLP products in the marketplace.  (Just the question itself, I think, goes to prove that the DLP space is still misunderstood by a lot of would-be DLP users.)

Oh, that it were that easy to have someone provide the "official" false positive rates of each vendor and go and buy the vendor with the lowest false positive rate.  Not only are false positive rates of DLP vendor products impossible to effectively and fairly determine, but the question seems to oversimplify the whole idea of DLP as it discounts dozens of other critical criteria for selecting the right DLP product.

A Note About False Positive Rates

The question of false positives was one of the early complaints about first-to-market DLP technologies.  False positives cast a negative shadow on DLP technologies because of user experience with other commonly-used security technologies.  What added more to the concern was the idea that a false positive could have the unintended effect of hobbling business efficiency.  I have heard horror stories of business production being shut down single-handedly by DLP enforcement technologies.  While the effect is possible, it's hardly likely if today's legitimate DLP technologies are configured and used effectively in the enterprise.  (Maybe a specific post on that at a later time...?)

Unfortunately, while false positives still occur with DLP, many DLP detractors beat that drum with the assumption that false positives will undermine the effectiveness of DLP in general.  Too often, these detractors make such accusations without first-hand experience with legitimate, comprehensive DLP technologies.  

By way of example, many of my customers have used content monitoring technologies of various email security platforms in what they then considered to be DLP.  You can't really blame them for expecting these solutions to effectively prevent sensitive data from leaving the network since almost all email security platforms use the term "Data Loss Prevention (DLP)" in marketing literature.  The difference is that these solutions are limited in how they detect sensitive data.  They rely almost wholly on regular expression patterns for identifying this data, so throw in a pattern for a US SSN and lo and behold, you get a bunch of false positives.  (That's why I hate how the term DLP is so loosely applied to all kinds of security technologies.)

The good news is that today's legitimate DLP technologies rely on far more effective means of sensitive data detection, including exact data matching.  This methodology makes a fingerprint of the known sensitive data (whether that's sensitive database fields or complete documents) and detects actual matches to these fingerprints.  This, along with a number of other detection methods, effectively reduce false positives to next to nothing when used correctly.  This is *the* advantage of legitimate DLP technologies over technologies that include DLP as a feature.

My recommendation is to let legitimate DLP technologies do what they do best:  detect and deal with sensitive data.  Let the email security solutions of the world do what they're good at.

Determining False Positive Rates

I also contend that it's terribly difficult, if not impossible, to get fair and accurate data on the false positive rates of the major DLP vendors.  Here's why:

Legitimate DLP vendors use very similar data detection methods.  Not all, but, most combine a) regular expression patterns (SSN or credit card number pattern matches); b)  data fingerprinting (hashes of specific known sensitive data, database fields, files, etc.) and c)  content analysis techniques (in its many varied forms).  Between a combination of these technologies, it's likely that each DLP technology can be tuned to accurately detect the same stuff as the next guy.  The problem for fair and accurate testing, however, requires that tuning be performed over a period of time longer than most test are willing to run.

This also means that users will likely be forced to rely on the studies paid for by the DLP vendors themselves.  Not exactly what I would consider to be fair and accurate reporting of fales positive rates.

In the end, because every customer has different data, they will need to test and determine the best solution for their specific needs.  There are DLP vendors that, because of their specific detection methods, may handle certain data types better than others.  That's why it's critical to always understand your sensitive data and then seek a solution that matches your needs.

What Could Be More Important Than Accuracy?

Really, sensitive data detection accuracy is the most critical component of effective DLP.  However, there are so many other criteria for selecting the right solution, including coverage areas (gateway, endpoint, discovery), appliance versus software, tolerance for architectural complexity, etc.

All the effectiveness in the world won't do a bit of good if the platform is too complex for your organization to manage or if it doesn't provide the coverage you need.

Ultimately, do your homework.  But do not get bogged down with this idea of having to know false positive rates of each vendor.  If you wait to move on your DLP project until you get this data, you'll be waiting a long, long time.