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:
- Let's stop them at our firewall.
- Well, we have to let some traffic through. Our IPS will catch the bad guy.
- Shoot, that didn't work. Ok, when the bad guy tries to steal our data the DLP system will stop him.
- 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.
- DLP is "workable" (albeit of dubious value nevertheless) if you run it solely in a B/F/D mode.
- 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.
- 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.
- 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.