data loss prevention: a red herring

A few years ago, the acronym DLP, which stands for Data Loss (or Leakage) Prevention, hit the security market. Every enterprise was crazy for it, every vendor touted it, and everybody had a different idea of what, exactly, it was.

Half a decade has passed and we still don't know. The problem is that DLP is a misleading term, because preventing data loss is the key reason for information security in the first place. If you think about it, every component of your enterprise's security solution, from policy to compliance reports, is in place to prevent your data from being lost or leaked.

There is no panacea for the problem of potential data loss, no matter what your vendor of choice might tell you. The smartest vendors don't even try to claim such a thing. Because nobody can agree on what, exactly, DLP is, nobody has a complete solution. However, the industry in general does agree on a few key concepts:

- A product that can recognize credit card / SSN / other identifying data both at rest and in motion and (better) control the transmission of such data is a necessary part of your security solution, if you deal with such data

- A product that can tag certain types of files and control the transmission (in whole or in part, encrypted or not) of those files is key

- A product that can recognize certain types of removable storage device being attached and/or written to and IMMEDIATELY control this activity is important

- If your business employs "mobile warriors" and you do not implement some sort of whole disk and file encryption, your data is at risk

- If your employees use mobile phones for business purposes then you should have some control over what type of data they can access on those devices

These are just a few of the concepts behind DLP, and those concepts keep changing as new risks are discovered. Adding to the complexity is the fact that some issues are going to apply to some enterprises, whereas other issues will be unimportant. For instance, the DoD never, ever transmits SSNs in the clear. However, many private sector businesses transmit SSNs in the clear as a matter of course (although they shouldn't). Ergo, when the DoD talks about data leakage, they are most often concerned with SSNs and other types of personally identifying information (referred to as PII), but protecting credit card information is not so much a concern. The private sector, on the other hand, is much more occupied with protecting credit card information but not so much (say) SSNs, driver license numbers, and other types of PII. Ergo, the part of the DLP solution that identifies certain types of data at rest and in motion needs to be flexible and customizable to be useful for the environment it's being used in.

Whole disk and file encryption is probably the easiest piece of the DLP pie to choose and to implement. In fact, you can get your whole disk encryption from one source and your file encryption from another, and as long as they don't fight with each other you're fine (as long as you remember that nothing is 100% foolproof, that is). But after that, it gets more complex, and vendors only make it worse when they try to convince you that their solution does everything you need for DLP. Well, no, it doesn't.

A smart executive will realize that DLP is not a single concept, and certainly not a single product; rather, it's a method. The first thing to do is to revisit your security policy. If you do not have a section detailing the specific types of data that you need to protect from loss/leakage and some (probably non-vendor-specific) methods for doing so, then it is time for a rewrite. [Note: you should be revisiting and perhaps editing your security policy on at least a quarterly basis anyway.] Sit down with your fellow executives and brainstorm your data pitfalls, and then do the courtship dance with vendors who claim to have solutions to these pitfalls. Again, do not fall into the trap of the One True Solution. It doesn't exist.

As you work on your DLP method, you will see that many of your current solutions and/or their vendors already work towards securing your data...of course, because that, as I said, is the entire point of infosec. For instance, your vulnerability scanner already scans for removable storage devices (both currently inserted and having been inserted at any time). That's great, but it's asynchronous. Does the vendor have a real-time solution (agent or sniffer based) that does the same thing? You already have auditing in place to determine if a file's been touched. How about if it's been excerpted and transmitted without being edited? And so on. If your current vendors have addons that can fit your newly-perceived needs, then that can perhaps save you money and implementation time.

One big problem with potential data leakage is that many businesses, to save money, don't issue their employees mobile phones but rather reimburse the employee if his or her existing phone is used for business purposes. However, in many cases, "business purposes" doesn't mean just calls; if an employee is using a smartphone, he or she is probably also downloading and responding to email and possibly also VPN'ing into the network and accessing corporate resources. If you're not virus scanning and otherwise protecting his phone in the event of theft and other compromise, then all the time and expense that you've gone to in implementing disk and file encryption on his laptop is pretty much useless.

All of this is a lot to think about. The good news, especially if you are a smaller business, is that you don't have to think about it and implement it all at once. This is why you should be always spiralling back to your security policy in order to revist your business's current needs.  Each time, you can tighten up your data security a little more.