Data Leakage Protection
Thoughts
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:
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.
10 comments:
Dr 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?
Or?
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?
Or?
Gunnar 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?
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?
Kevin Rowney 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
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
Alex Raitz 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.
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.
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.
b said...
LonerVamp 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.
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.
Tigercat
6795 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".
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".
Dominic White said...
My response ended up too long, so I moved
it to my blog, you can find it at
http://singe.za.net/blog/archives/972-A-Response-to-Bejtlich-on-DLP.html
Joe Allesi 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.
No comments:
Post a Comment