Can You Still Protect Your Most Sensitive Data?

An article in The Washington Post called “A Shift Away From Big Data” chronicled several corporations that are actually deleting their most sensitive data files rather than saving them. This is counterintuitive to today’s data-heavy landscape; after all, one of the tenets of the big data movement is to store everything — even data that you feel could compromise your customers or proprietary information that you wouldn’t want to fall into competitor hands.

Handling Sensitive Data

“In Silicon Valley, there’s a new emphasis on putting up barriers to government requests for data,” The Washington Post reported. Firms are trying to place their customer information beyond the reach of law enforcement requests, should they be necessary.

But far from being a shift away from big data, this trend is more about firms becoming more adept at saving their data. It helps that many IT managers are more educated about how encryption works. They understand who holds the keys to their most sensitive data and how it is kept by each enterprise. This is a good thing, mainly because for too long IT managers have tried to educate others in the C-suite about these issues with little success.

Even a few years ago, IT specialists had to do all the encryption key management on their own, which was daunting to say the least. Modern products do a better job of handling this, thankfully, although encryption is still not a cakewalk. But we are more sensitive to how we manage our key infrastructure.

The Most Pressing Data Trends

There are several components to this trend that can be identified as going beyond just growing paranoia. First is that enterprises are looking to own their encryption keys so that even if encrypted data falls into others hands, it can’t be decrypted. Cloudera and Box, among email providers such as Proton Mail and Mailpile, now do this as part of their normal operations.

Similarly, DataMotion can be set up with an option so that no decrypted messages are ever stored locally. Email messages or documents are encrypted at their source before they make their way to the cloud, and the vendor can’t ever decrypt them. There was the case of Lavabit, an email encryption provider. The service closed its doors in 2013 rather than provide its keys to the U.S. government.

Second is a need for metadata privacy. While encryption protocols such as PGP work well at encrypting message bodies, they don’t usually touch the subject lines or addressees, especially when email is read by HTML-compatible services. But a new breed of vendors is more sensitive to metadata collection. This need has driven programmers to work on initiatives such as the Dark Mail Technical Alliance, which offers end-to-end encryption services to the public.

Third, protecting sensitive data is not the same as providing anonymous communication. Most people think they are the victim of a spammer when they receive an anonymous email. Today’s services are more focused on data protection than the anonymizers of earlier eras. Some vendors, such as Mailpile, have gone to great lengths to document how they address their users’ privacy.

Finally, there has been a growing concern that American-based companies are more vulnerable to government requests than businesses operating their infrastructure offshore. Whether or not that is true, a number of international vendors have sprung up with claims that their servers aren’t subject to seizure by the U.S. legal system. For example, Silent Circle and Proton Mail’s servers are based in Switzerland, and Mailfence has its servers based in Belgium.

Where will this lead? Certainly, there will be other legal battles over law enforcement access to encrypted data, but in the interim there are tools that can help protect a corporation’s sensitive data — that is, if those enterprises decide that information is worth keeping at all.

Contributor'photo

David Strom

Security Evangelist

David is an award-winning writer, speaker, editor, video blogger, and online communications professional who also...