Data Leakage Protection Thoughts

"Data Leakage Protection" (DLP) appears to be the hot product everybody wants. I was asked to add to the SearchSecurity section I wrote two years ago, but I'm not really interested. I mentioned "extrusion" over five years ago in What Is Extrusion Detection?

This InformationWeek story had an interesting take:

What constitutes DLP? Any piece of backup software, disk encryption software, firewall, network access control appliance, virus scanner, security event and incident management appliance, network behavior analysis appliance--you name it--can be loosely defined as a product that facilitates DLP.

For the purposes of this Rolling Review, we will define enterprise DLP offerings as those that take a holistic, multitiered approach to stopping data loss, including the ability to apply policies and quarantine information as it rests on a PC (data in use), as it rests on network file systems (data at rest), and as it traverses the LAN or leaves the corporate boundary via some communication protocol (data in motion).

Locking down access to USB ports or preventing files from being printed or screen-captured isn't enough anymore; organizations require true content awareness across all channels of communication and across all systems.

Wow. Cue a giant product rebranding effort. "Yes, we do DLP!!"

I tried to capture my concerns in the following two figures.

I usually approach security issues from the point of view of a security analyst, meaning someone who has operational responsibilities. I don't just deploy security infrastructure. I don't just keep the security infrastructure functioning. I am usually the person who has to do something with the output of the security infrastructure.

In this respect I can see the world in two states: 1) block/filter/deny or 2) inspect and log.

As a security analyst, B/F/D is generally fairly simple. Once a blocking decision is made, I don't care that much. Sure, you might want to know why someone tried to do something that ended up resulting in a B/F/D condition, but since the target is unaffected I don't really care.

Consider this diagram.

As a security analyst, inspect and log is much more complicated. Nothing is blocked, but I am told that a suspicious or malicious activity was permitted. Now I really need to know what someone successfully completed an act that resulted in a permitted yet inspected and logged condition, because the target could be negatively affected.

Consider this diagram.

Some might naively assume that the solution to this problem is just to forget inspection and logging and just block/filter/deny everything. Good luck trying that in an operational setting! How often do we hear about so-called "IPS" running in passive mode? How many fancy "DLP" products are running now in alert-only mode?

At the risk of discussing too many topics at once, let me also contribute this: is it just me, or are we security people continuously giving ground to the adversary? In other words:

  1. Let's stop them at our firewall.

  2. Well, we have to let some traffic through. Our IPS will catch the bad guy.

  3. Shoot, that didn't work. Ok, when the bad guy tries to steal our data the DLP system will stop him.

  4. Darn, DLP is for "stopping stupid." At least when the bad guy gets the data back to his system our Digital Rights Management (DRM) will keep him from reading it. (Right.)

I guess my thoughts on DLP can be distilled to the following.

  1. DLP is "workable" (albeit of dubious value nevertheless) if you run it solely in a B/F/D mode.

  2. As soon as you put DLP is inspect and log mode, you need to hire an army of analysts to make sense of the output.

  3. The amount of asset understanding to run DLP in either mode is likely to be incredibly large, unless you so narrowly scope it as to make me question why you bought a new product to enforce such a policy.

  4. DLP is not going to stop anyone who is not stupid.

Is anyone else hearing demand for DLP, and what are you saying?

Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.


Anton Chuvakin said…
"DLP is not going to stop anyone who is not stupid"

Maybe. So, let's define 'stupid' a bit.

1. Negligent employee?
2. Script kiddie?
3. A no-so-skilled attacker who is still beyond a SK?

Anonymous said…
Was about to comment then I had a brief spell of rofl when i read the "Let's stop them at our firewall." comment.

To answer questions on hearing demand for "DLP", sure but I just chalk it up to InfoSec's endless Silver Bullet quest, where they reach for the stars and deliver next to nothing.

Here is a crazy idea - what if we put authentication, authorization, and auditing into our systems?
Anonymous said…
Yes, DLP does plenty of "stopping stupid" and in many large scale deployments does so in what you call b/f/d mode.

DLP has also busted numerous id-theft rings, corrupt employees, and hackers.

The threat surface is actually quite complex and not so simple as "stupid-employee" vs. "evil genius hacker".

@Gunnar: AAA is baseline protection, but field results from DLP deployments clearly indicate this is a low hurdle to clear. More detail on that here
Anonymous said…
When I began analyzing network traffic via NSM, management was extremely worried about the data leakage being detected, especially data leaked from inside to outside the corporate network via IM, FTP, etc.

When management directed me to investigate data leakage protection/prevention (B/F/D), it quickly became apparent that whatever risk mitigation these systems provided would be trumped by the business impact of administering the system. The anticipated increase in first-level help desk calls alone was nightmarish.

On the other hand, I did not find the "inspect and log" modes to be terribly verbose or challenging to handle. I agree that there was a fair amount of asset understanding involved in making data leakage detection systems useful, to the extent they are a poor candidate for outsourcing/MSSP, but I cannot imagine that an organization which can manage an NSM infrastructure would not be able to manage a DLP infrastructure.

In the end, I didn't find much that the DLP systems had to offer in "inspect and log" mode compared to SGUIL. Vigilance, some clever Snort rule writing, and user training on data leakage will go a long way to managing the "stupid" leakage.
Anonymous said…
DLP is part of the problem, not part of the solution.

It is an impossible exercise - if you have the capability to read data, you have the capability to copy it, some way or another. It is folly to pretend otherwise.

The best one can hope for with DLP is that it will help you tell a more convincing lie to an auditor, regulator or judge about "due diligence".

As a product category it's guaranteed to be an expensive, distracting failure. That money and productivity are flushed away on products that can fundamentally deliver nothing but a CYA story (the MORE it costs, the more it shows you care!) -- that the entire category of DLP has even the tiniest shred of credibility and legitimacy -- is a perfect example of the problems of fossilized corporate infosec.

Let us just pray that these jokers don't manage to ensconce themselves as a requird best practice in government, PCI or audit requirements.
Unknown said…
I think you and other commentors above hit this one properly.

To me, "DLP" is nothing more than the continued marketing spew of antivirus->antispyware->antimalware->Hips->endpoint security->DLP... Basically the same product, bloated.

It does fine on the surface, but anything below that is weak or hard to analyze. Anyone with a proper security environment anyway won't need DLP. It's just the same old HIPS product with some endpoint security pieces tacked on, most of which should be done anyway by system management tools or LDAP-pushed policies.
Anonymous said…
I agree with several commentors and disagree with others so here it goes:

I am very much a supporter of DLP products as a level of protection for general users. I also agree that DLP isn't the answer to all your problems.

I see DLP tools as a technology solution to help drive awareness and behavior patterns. More a "front end" tool. Policies used in these tools can help reduce significant gap areas that network and log monitoring aren't going to cover all the way. Examples: CD burning, USB writing, Emailing files, and uploading classified data to websites. To me this can also be leveraged as a Security Awareness tool that helps when you can't do presentations 24 hours a day.

This being said I have reservations on network based DLP products and lean more toward the client side. I do not see this as a replacement for personal firewalls, antivirus, anti-malware tools. I would have serious doubts over any "single-client" product that would profess to cover all those areas.

My experiences with client side DLP tools is that it is very intrusive (+ and - on that),but once you get past the configuration hurdles (standard in a number of products) it has proven in several occasions to be very enlightening to those using it in terms of what was "thought" to be happening to what was "really" happening. Very helpful when explaining to a non-technical crowd as they see data flying out the door.

I think NSM has the potential to be a good complement to DLP, but will reserve commentary on it as a replacement until I see the end results of an ongoing implementation.

Fortunately I will have the opportunity to see both sides.

PS - I second Kevin Rowney's comment. "The threat surface is actually quite complex and not so simple as "stupid-employee" vs. "evil genius hacker".
Anonymous said…
My response ended up too long, so I moved it to my blog, you can find it at
Venious said…
Yep, Data Leakage (Loss) Prevention is really just another method of enforcing policy. And you are correct, it's just a nice marketing term for extrusion detection, however I think DLP is best managed by the owner of an edge service and/or by the data owner's themselves. For example, if the policy is no SSN's will leave the company via SMTP or HTTP unencrypted. The email gateway is then configured to force encryption on the message before handing it to the remote domain, and an HTTP post of the SSN is rejected by the proxy. There are lots of other options, but I really think this level of data detail would be too much for an NSM team to support.

Popular posts from this blog

Five Reasons I Want China Running Its Own Software

Cybersecurity Domains Mind Map

A Brief History of the Internet in Northern Virginia