The Road to DLP Leads to Encryption

So a mailing list I subscribe to had a question come in about how to do data loss prevention (DLP) in order to satisfy these essential requirements:

1. User puts in USB drive. Is user authorized to use USB drives?
2. User puts in USB drive. Is it malware free?
3. USB is plugged in; user is authorized and USB drive is malware free. Is user trying to run executable from USB drive?
4. USB is plugged in; user is authorized and USB drive is malware free. Is user trying to copy sensitive data to USB drive?

I spent some years in the DLP world and did a lot of this. All of this is do-able but may be a bigger project than it looks. There are three policies here;

1) no access: file operations to USB device types are blocked.

2) Executable files: USB file operations for executable file types (some four dozen executable file type extensions in the windows space; a better solution would be to parse PE headers and the like, esp. if a user is going to strip extensions from files).

3) Sensitive data writes: USB file writes for data that matches a particular classification are blocked (obviously requires good data classification and ruleset based on locations like UNC paths, file name patterns, regexes on the content, etc). If you're limited to locations like UNC paths you will need to block writes to the local file system as well because there are too many ways to move data from off of a desktop.

Issues to consider;

- What does "malware free" mean? AV tools are at best 70% effective; in order to have a robust defense against USB based malware it's more effective to block access to executable file types.

- Renaming files; effective against simple malware but if the tools are doing simple file extension mapping then obviously a user can strip extensions to get around the rules. If you have users consistently circumventing tools then it behooves security to understand the needs the users are trying to meet.

- Data classification. Many organizations do not have data classifications - necessary for successful implementation of policy (3) above - in which case a second project will need to be spun up to design and implement data classification.

- Business process. Many DLP projects run aground because security do not take the time to understand the workflow in the business lines they are trying to regulate. Get to know your line managers and learn about their operations. Trying to impose a restrictive DLP policy without any context or understanding of the business process will often fail, as the Russians would say, "with very big noise".

The trouble with trying to do data loss prevention in a large enterprise is that, as with many detection problems, the extrusion vectors (the different ways data can leak out of a network) are numerous and evasion techniques are supernumerary, particularly when you have semi-skilled users. I found in the end that mandatory encryption is the place where you arrive after you spend some time trying to police every extrusion point. By encryption I mean something smarter than simple full-disk encryption – second generation tools can take steps to make sure data taken off a running system is encrypted, not just protect a dark laptop.

Analyzing the difficult or ease of doing DLP this is fairly straightforward in most organizations and can be an educational exercise as well. It’s not terribly hard..start by setting up machines jut like the computers line workers have; set up a tester like a credentialed user; have them study the apps in the environment and enumerate the ways important data can be exfiltrated (just make sure this project is duly authorized by everyone - legal, hr, c-level- and take care not to commit a material breach of regulated data in the process). Gather lots of data, analyze the results and you can evaluate your business case for DLP and/or encryption.