Yet Another DLP Player

For a number of years, Lumension has skirted the DLP space with its device control capabilities.  In fact, it's been a number of years since the company first started touting the "DLP" capabilities of its device control product (SecureWave acquisition). 

Well, now Lumension is ready to really move into DLP with the recent announcement of a relationship with RSA's DLP solution.  Lumension will license the RSA DLP SDK in order to bring these DLP features to its solution.  This move is not surprising as many of Lumension endpoint control competitors have already signed on to increase true DLP functionality. 

It does make me wonder how the face of DLP may change in coming years.  With so many endpoint solutions adding real DLP features, will they be able to significantly compete and win marketshare from the DLP suites that include network and discovery?

Single Channel DLP "Excluded" from Gartner DLP MQ?

There is some chatter in and out of DLP circles about "single channel DLP" solutions.  The question is, should these solutions be included in that exclusive fraternity of solutions known as DLP or should the definition of DLP be altered to allow their inclusion? 

By way of definition, single channel DLP would be solutions that do not address the generally-accepted DLP requirements of network, endpoint and discovery (aka data in motion, in use and at rest).  Specifically, there have been some mentions of single channel DLP in the following articles/posts on the Internet:

Network World article by Ellen Messmer in which "Single Channel DLP" is mentioned

and

LinkedIn Data Loss Prevention (DLP) Forum post

In the Network World article, the term single channel DLP is attributed to Gartner and described as "a second track for DLP...which often focuses on the sole task of monitoring e-mail and attachments and ensuring e-mail encryption is properly used." Eric Ouellet is quoted as saying, "What we've learned over five or six years is that organizations overall seem to be buying more DLP than they need for the real-world case.  Routinely, they do not deploy all of the components within the two- to three-year timeframe."

My interpretation of Ouellet's comments combined with the reference to single-channel DLP, is that such a solution may be suitable for some companies, given the fact that some organizations do not deploy all channels (network, endpoint and discovery) during the course of a two- to three-year deployment.

The LinkedIn DLP Forum post includes a comment from Joshua Block, vp bizdev at Safend, lamenting the fact that to use a definition of DLP as solutions that cover *all* channels (unfairly?) excludes "a large number of vendors."  Single channel DLP vendors were, in fact, left out of the recently-released 2010 Gartner Magic Quadrant for Content-Aware DLP.  One requirement for inclusion in this MQ is that solutions be able to "detect sensitive content in any combination of network traffic, data at rest or endpoint operations."  The simple fact is that single channel DLP solutions do not provide this functionality.

Joshua goes on to say that many single-channel DLP solutions partner and/or OEM in order to provide complete coverage of network, endpoint and discovery. I say vendors who partner or OEM in order to provide complete DLP channel coverage should be included in future DLP comparisons, however, these vendors will need to keep in mind, they'll be going up against solutions with full integration between all channels.  Sometimes no showing at all in an analyst review is better than a poor showing.

Speaking of DLP Vendors You've Never Heard Of...

Well, I've actually heard of CoSoSys in my research, but have never encountered them in a production environment.  They have a funny YouTube video referencing their "Data Leakage" offering, which is an endpoint device control solution.  I don't see anything on their site about the solution being content-aware (IMHO a critical requirement for endpoint protection if it's to be considered DLP).

Enjoy the video.  But beware the creepy voice at the end.  It gave me nightmares.  ;)

Ending the Data Loss Prevention Debate?

*  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.

Where to Start DLP? Gateway or Endpoint?

Should we start our DLP implementation (or even our product evaluations) at the endpoint or gateway?  Many companies want to roll out DLP in a phased approach with gateway, endpoint and discovery each coming at a different time.  The big question is which of these three critical components should come first? 

Good question.  So, what’s the right answer?  It depends. 

It can depend on any number of factors and the answer may be different for each company.  However, there are some key considerations.

• Shortest Distance to DLP.  For most DLP vendors, the simple shortest distance to mitigating data loss risk is through the gateway.  A single passive monitoring device can provide a great deal of visibility into end user habits and broken business processes. 

• Biggest Bang.  For the investment in time and money, where will your company see the greatest benefit?  For many companies the simple answer is a single monitoring gateway device.  Once installed, this device can monitor ALL outbound traffic for violations.  Contrast that with a company-wide rollout of an endpoint client and all the trappings that go along with managing hundreds or thousands of individual clients.  Often, the load of help desk alone is enough to keep endpoint in the backseat behind gateway monitoring.

• Most Urgent Need.  Where did your most recent data loss scare happen?  Was it an errant email (gateway) or a lost USB thumb drive (endpoint)?  Your company’s management may have provided direction to address what is perceived to be the most pressing need, in which case, you may not have much say in the matter.

• Infrastructure Redundancy.  For many DLP products, a central management server will be required in order to manage either gateway or endpoint deployments.  And with certain vendors, this same management server can be used also for monitoring outbound traffic—without having to install multiple clients.  If the server has to be installed in either case, often the gateway rollout can be done in a fraction of the time or an endpoint rollout. 

• Core Technology Considerations.  Put very simply, some DLP solutions are designed to be rolled out at the gateway first and supplemented by endpoint.  Some DLP solutions can be rolled out as endpoint alone, however, as pointed out above, the fact is they need a management server (which can often serve as the gateway monitoring device).  Other solutions may only include endpoint (making this a moot point).  The bottom line is, if you have a predilection for one vendor or another, they will likely have something to say about where you start your deployment.

• Birth of a Vendor.  Today's DLP vendors all started somewhere and most still carry the same mindset from birth.  Some were born as endpoints, however, most of the leading solutions today were born as gateways.  Take the vendors in Gartner's DLP leaders quadrant, for example.  Their main DLP product acquisitions were gateway-focused:  Symantec/Vontu, RSA/Tablus, Websense/PortAuthority, McAfee/Reconnex (included because they're close to the leader quadrant, they're one of the more powerful security vendors and their recent announcement of endpoint/gateway integration in ePO will likely land them in a leader position).  How a DLP product was born will often determine their starting point. 

• Hey!  What About Discovery?  Discovery tends to be a bit of a different animal.  With most of today’s DLP products, discovery can be done either at the network level or the endpoint.  And wouldn’t you know, most vendors now offload endpoint discovery to their endpoint agent.  Likewise, the gateway component often drives network-based discovery.  As much as a company may want to start with the discovery process, it’s often a sub-component of the other two, at least among DLP vendors.

One thing I’ve learned is to not let this kind of distraction get in the way of doing something--anything-- to protecting your company sensitive information.  Make a decision and go with it.  Chances are the next phases are not far behind and within a short time, how you started the project won’t be near as important as how well you’re mitigating data loss risk today!