What Do DLP and Condoms Have in Common?

DLP and condoms? Neither is a 100% solution. Best results when used in conjunction with axillary monitoring.

The report states “a single case contained the use of an encrypted channel for data extraction”, indeed encryption at the network level is seldom used for data exfiltration. However, what the report does not mention explicitly is that attackers do use encryption at the *data* level.

Splitting the data in a series of archives protected by a password allows to exfiltrate large sets of data. Plus you can drop files to third parties servers without having to disclose the information. Unless your DLP solution rings a bell when such files get transported on your network, you will be blind.

TLG-

The context in the paper makes it clear the files weren’t encrypted either, but I agree that wasn’t explicitly stated.

Yes- the technique you describe would probably work, but again, that’s not yet how the bad guys are doing it. Also, some DLP solutions can detect and alert on encrypted archives if a standard encryption method is used. A bunch of the tools support that.

I prefer an analogy of DLP protection to a six foot fence.  You aren’t going to protect against a very determined bad guy but you will prevent the majority of violations.  Your intentions to protect are made very clear.  Further, it is getting to the point where it is difficult to report a violation while admitting you didn’t at least put up some kind of fence.

At the risk of offending someone with graphic descriptions, a better analogy when explaining DLP solutions is “coitus interupptus”.

Let me explain.

The extreme approach to “content blindness” in DLP is indeed encryption. However, there are other methods that are equally as effective in making DLP “content blind” that do not necessarily involve malicious users, for example, modifying content at its origin by users and systems. The modus operandi of DLP agents (network gateways, crawlers, or endpoint agents) is to identify the similarities in content at the exit/channel/medium from the sources that they were generated. In this case, we are now playing in the field of statistics and probability, even if we assume that they are 99% exact. For the record, I don’t believe DLP technologies are that accurate. What this means is that one or two items per user per day will mistakenly be enforced (AKA false-positives or false-negatives).

Can organizations afford it?  Probably not. That is why most DLP solutions end up in “Monitoring Mode”. So I ask, what type of “birth control” does this resemble?

I believe that in order to make data loss prevention solutions effective, it must identify the content as close to the origin and/or point of creation as possible, where information is produced from enterprise applications, databases, repositories, or even users. At this stage, before the end-user manipulates the content (to the extreme, before the end-user tries to encrypt or send it in encrypted channels), content is still in its original form, in a structured format, that can be identified with no false-positives. At this stage, the solution should embed the protection into the data at creation, by using E-DRM rights or encryption. This technique will, also, overcome the challenges that you have mentioned – adding agents in order to support additional ports/exits to be scanned. Now, you can kill three birds with one stone. In a single action, you have an integrated solution that handles the three aspects of information protection and control; data at rest, data in use, and data in motion. This solution is agnostic to channels, ports, devices, and mediums. This should be the way IPC/DLP solutions should work. Let’s not be confused of the current and future integration of DLP & E-DRM solutions- Embedding ERM rights in the late stages of the information cycle (acting upon exits or acting when directories are scanned). These solutions will have the same flaws that DLP solutions encounter today…

We, at Secure Islands Technologies, are focused on solving these issues by supplying an automated data-centric security from the origin.

Anyway, sending mail from outlook using gmail for example uses sll, so it’s encrypted, so sometimes user encrypts without even knowing

All Enterprise DLP solutions have the ability to peak into and actively remediate SSL connections containing sensitive data.

Also, using a DLP solution you can easily sniff out many other types of encrypted traffic on the wire.  You do this by leveraging the DLP solutions ability to identify files of different types.  Encrypted Zip files, Protected PDFs, and Protected MS Word documents can all be easily identified and blocked even if you can’t see what is inside them.

**Editors note- this comment was left by a member of a DLP company; they identified themselves with their email, but since we don’t display that I’m adding it as a note.

I think that the analogy is “interesting” but the issue is not really the effectiveness but the cost.

In South Africa we have a huge AIDS problem so government issued condoms are free and very easy to get hold of. Fancier condoms are slightly more expensive but not much.

A DLP solution can cost in the multi-millions which is quite a bit of money for something that is “sorta” effective.

A feature like identifying the encryption of a file will not help much…Indeed you can block encrypted files but it will block also a legitimate business activity that I am sure security officers will not do it. So we again end up with monitoring mode…which is ineffective in this case (” audit spamming”).

Regarding SSL connections, DLP solutions dont have ability to decrypt SSL without integrating through ICAP to solutions like BlueCoat…Aha and what about laptops/endpoints outside the perimeter? It wont work!

**Moderators note- The commenter is with a vendor that offers an alternative to DLP. He indicated this in his registration, but since we don’t display email addresses I’ve added this note.

I bet the topic of condoms has never seen so much scrutiny from a security/performance perspective.

DLP and SSL…
It kind of sometimes works, but you have some problems:

- Show a trusted! certificate on behalf of the ssl server (gmail). This usually requires root authority certificate distribution to all endpoint.

- Know what certificate to show by IP and port only.

- Know what IPs and ports to monitor.

And it’s compromise the security of the ssl.

Condom anyone?

Roee