Data Loss Prevention: What's The Use?

For years I’ve heard arguments as to why data loss prevention (DLP) tools can’t prevent all incidents of sensitive data leakage. These arguments have been delivered by a variety of customers, analysts, vendors, and just about anyone who likes to take a contrarian view, even if only to stoke the fires of debate.

After the new article "Stealing Documents Through Social Media Image-Sharing" gets a bit of circulation, I'm sure to start hearing this new argument as additional proof of why DLP technologies won't work. The article references SNScat, a newly developed software tool that proves it is possible to exfiltrate sensitive data using steganography, a method of making data appear to be something else, so only the intended recipient is aware of the hidden data. The developers explain that SNScat breaks the subject data into pieces that are, in turn, embedded into the data of image files and uploaded to social media sites. The intended recipient then downloads the image files, uses SNScat to reconstruct the subject data, and voila! The whole effort results in the acquisition of the subject data while leaving no trace of the theft.

The developers of this new tool are not interested in using their software for malicious purposes, of course. They are sharing their efforts with the hope that the marketplace will recognize the need to research and challenge this method of data theft.

Steganography is not new; the method has been around for hundreds of years, but the new twist is in leveraging social media sites as data mules for packing out the hidden data in the images. It's a logical and compelling approach that, unfortunately for data owners, appears to work as long as image sharing is available to end users. It has the potential to make malicious efforts of data exfiltration harder to detect -- and prevent.

With this new development, I expect to hear the DLP cynic's argument to go something like this: "What's the use of deploying data loss prevention technologies when a user can simply use SNScat [or insert any other method du jour here] to covertly steal sensitive data?" This flawed logic says that if a network security technology is not 100 percent effective, it's not worth the cost or effort to deploy.

I cringe every time I encounter this defeatist attitude, especially among information security professionals. If we all followed this same logic in other areas of network security, then we would never deploy any security technologies. We would mitigate exactly zero risk, leaving our networks -- and our sensitive data -- completely open to theft.

If we accept the fact (and we must) that there will always be some way to circumvent some security measures to steal sensitive data, then we must also accept our overarching objective as being the identification and mitigation of as much risk as possible.

As for protecting against the likes of SNScat, companies must weigh the risk associated with allowing users access to social media sites (as well as a long list of other sites) with the benefits. There is a simple solution: Restrict access to Facebook, Twitter, and YouTube to all but those who may need these services in the performance of their job duties. No doubt it will be an unpopular decision among employees and maybe even executives. But as we all know, desperate times call for desperate measures. Is the security of your organization's sensitive data more or less valuable than company morale?

I have visited companies where I was forced to surrender my camera phone and put electrical tape over my laptop webcam or surrender the device entirely. Thankfully for most of us, this is the exception and not the rule. One thing is certain: If a malicious insider is hell-bent on extracting confidential data from an organization, then there are certainly easier -- albeit less sophisticated and cool -- ways to do it than steganography.

Jared Thorkelson is founder and president of DLP Experts, a vendor-agnostic VAR and consulting practice focused exclusively on data protection. He can be reached at [email protected].