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 #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 #5: DLD is the same thing as DLP

It may surprise you to find that many DLP enforcement technology implementations are not even DLP--they're DLD, data loss detection.  Too many companies forget that the "P" stands for prevention.  Blocking.  Frankly, it's not really the end user's fault, rather the responsibility of the vendors.  There are a couple critical elements at play in this discussion:

• Inaccuracy often is the cause for failing to enable blocking.  If a vendor's DLP technology does not prove accurate, to turn on blocking is far too risky for the end user.  This will impede normal business process.  Unfortunately, a DLP vendor is only as good as their capacity for accurate detection.  Keep in mind that not all DLP detection is create equal.  (We'll discuss this topic in a later post).

• Most DLP enforcement technologies are limited in what they can block:  SMTP, FTP, HTTP, HTTPS and other proxiable protocols.  This is true of the biggest names in DLP and is not something that's commonly known among buyers of DLP technologies.  Since this is the case among most vendors,  analysts accept it as a limitation of DLP, and since the analysts help shape the expectations of the marketplace, most buyers accept the limitation (once they finally know about it).  The limitation lies in the core technologies of these vendors which depend on proxy devices to do the dirty work of blocking.  There are two vendors I'm aware of that have the ability to block all protocols and not just proxiable ones:  Fidelis Security Systems and GTB Technologies.  However, in my opinion, each have their own deficiencies in other areas that may cancel out the blocking benefit.  There is no perfect DLP enforcement technology (and we'll discuss this in a later post also).

The bottom line is, as much as you may like to, you'll likely not be able to block everything that needs to be.  However, if you choose a vendor with the right detection capabilities, it will go a long way toward being able to flip the switch to turn your data loss detection into true data loss prevention!