Information confidentiality: protecting the spring or the spigot?

Blogger: Ramon Krikken

With Data Leakage Prevention (DLP) being one of the ‘hot products’ for 2008, It should be no surprise that nearly every single loss of sensitive information results in one or more “our product would have prevented this” messages from the different vendors. The latest incident where a USB flash drive containing sensitive usernames and passwords was left in the parking lot of a pub in the U.K. is no exception. And while it is certainly the case that a DLP solution might have prevented the storing of such data on the USB drive, it always makes me wonder if it provides the best control for its cost.

In the ideal world, security would be integral to the data. Enterprise Digital Rights Management (e-DRM) offers some promise, but lack of interoperability standards and never-ending discussions on how to implement encryption, key management, and make data accessible off-line quickly derail the effort. More mature would be disk and file encryption technologies, but when implemented with poor controls such as simple passwords and not automatically requiring or enabling encryption on removable devices they also quickly lose their effectiveness. So we tried the next best solution: preventing data from going or being where it isn’t supposed to. It’s not that the discussions on the what, where, and how are necessarily less heated, but at least there is some emerging body of evidence on how to make it work for certain use cases. Network content detection can work well for accidental disclosures via email, agent-based contextual detection can be a better alternative when the enterprise is concerned about employees stealing trade secrets using their iPod. But still, using or not using the active prevention features of DLP is a contested race.

We expected this, of course: because active blocking technologies are very visible to users in the case of failure (in this case a false positive, where something is blocked even though it’s an approved operation) the security teams and IT departments are, rightfully so, concerned about inhibiting business. Unless the environment and culture are conducive to this kind of rigid control with the occasional problem – or unless the security and IT team have the time and resources for a careful roll-out and endless fine-tuning – using blocking technologies can be a risky proposition. The alternative is to use DLP solutions to scan data repositories in order to find sensitive information, which is certainly helpful in a time when many enterprises aren’t even sure what data lives where. To me this loses some of the value proposition of DLP, but in some cases – especially if combined with classification and ‘tagging’ of the information – it may certainly be good enough. If nothing else it is a helpful tool in the identification and classification of data in the organization, a journey on which most companies have hopefully embarked on by now.

Things of course always get more complicated – not easier. Software as a Service (SaaS), cost-cutting by having employees use their own equipment, and the need to share with business partners are an ever increasing inhibitor of centralized controls, and DLP is no exception. Coupled with the cost of acquiring, implementing, and maintaining the solution it does raise the question whether already scarce budgets would be better spent on other controls … or whether the cost of maintaining security in such environments outweighs the cost savings to begin with.

In the end it’s all a matter of risk versus reward. Although I predict a much brighter future for preventive controls such as encryption and rights management, it’s certain that today’s environment – and from the looks of it, tomorrow’s as well – is much more conducive to detective and reactive technologies. Working from the use and abuse cases as a starting point, enterprises should be able to evaluate not only the functionality of DLP solutions, but also be able to make at least an educated guess on their cost effectiveness.