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.

Employees Are More Apt to Take Company Data than a Stapler

The title of this post is taken from the headline of a press release from SailPoint as reported in NetworkWorld.  While it is a great headline, more importantly it should tell us that no organization's data is safe, especially for those laying off employees. 

For me the takeaway from SailPoint's survey is that companies should not trust their employees, especially when layoffs are on the horizon.  I have spoken to many companies in the past three years who have laid off workers.  Some have implemented some strategy to protect that data (technology or otherwise), but most have proceeded with the layoffs without any method for ensuring the safety of their sensitive data. 

In the SailPoint survey, they found that 29% of US workers admitted they would take customer data.  This is consistent with my recent personal experience.  A banking customer confessed to me that many of the home lending staff they had laid off apparently took the bank's customer list to use as a sales prospecting list--presumably along with personally identifiable information (PII).  One trucking company that contacted me for data loss prevention was concerned that their competitors would somehow gain access to their customer contacts (read:  "from their former employees"). 

The problem could be exacerbated by a bad economy and the personal impact on individual finances.  While the survey did indicate that 45% of the US respondents claimed this tendency to steal from an employer was not influenced by the recession, there were slightly less than .5% of US respondents who said they would try to sell confidential data.  Using these stats, one out of every 200 employees, would try to sell your confidential data.  All it takes is one to end up like TJX.

This is not the first survey of its kind with similar findings.  For me, this confirms what I've felt for years:  that data loss prevention technologies will eventually become part of every network security plan.

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!