BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
BYOE, or bring your own encryption, is a cloud computing security model that allows cloud services customers to use their own encryption software and manage their own encryption keys. It works by allowing customers to deploy a virtualized instance of their own encryption software alongside the business application they are hosting in the cloud. The business application is configured so that all its data is processed by the encryption application, which then writes the ciphertext version of the data to the cloud service provider's physical data store.
In this Ask the Expert, James Staten, an analyst at Cambridge, Mass.-based Forrester Research Inc., discusses with SearchCIO Senior Features Writer Karen Goulart why this model is important for enterprises today, the skills required to employ BYOE and when the trend will peak.
One of the reasons why encryption is such a big topic right now is because what we used to take for granted is no longer the case -- that if you put data in a data center, it was secure, even from the government. Now the assumption is the government gets access to all of it. Companies that are concerned about that risk need to take control of their own destiny and that is where bring your own encryption is so important.
If a company encrypts the data, that means it also has the keys to decrypt it. And if the government is going to come and ask for the data from [the company's provider] AT&T, for example, AT&T doesn't have the keys, so AT&T can only give encrypted data to the government. Arguably, the government could decrypt through other means, but, by default, AT&T is not circumventing your security.
It's in the best interest of large enterprises that this data would be a candidate for bring your own encryption. Note that this is for the data they have extreme concerns about -- and it's definitely not going to be about all the data, otherwise they'll drive themselves nuts.
And there are multiple ways to handle encryption. You can bring the type of blanket encryption that encrypts the entire volume. You can bring encryption that retains the structure of the data. And you can bring what they call tokenization, in which the integrity of the data is maintained, which is really necessary to consume the data and for different applications to do stuff with it, but which obscures the true identity of the data.
A good example of tokenization is what's called field-level encryption. If in your data set, for example, you have social security numbers, you will encrypt the social security number but it will still look like a social security number to anyone who reads the data.
Here's how that's done: If the first three digits of a social security number are 550, they will be replaced with, say, the digits 301. But the encryption technology understands how to remap 301 to the actual number. This is a really valuable mechanism for encryption because it doesn't affect any other applications. So if the applications have to see this seven-digit number and know it's a social security number in order to tie certain data to a person, the social security number itself never has to be revealed and, therefore, neither does the identity of the person being acted on. We're finding lots of clever ways to make sure the data is protected but usable at the same time.
This is going to be at the top of the security list for 2014 because of the whole NSA/Snowden data leak. We also expect in 2014 that other governments are going to get caught doing this [collecting data] too. It will shift from being "U.S.A., your government is bad" to "Oh, my government is bad too." More and more companies will say, "Hmm, I know I can't trust a U.S. service provider. I thought I could trust my home country's service providers, but now I don't trust them either." So [companies will realize that] the idea of running to the safest spot won't be the way to protect their data. The better way is to protect it yourself.
We do think the trend will peak in 2014, because even some of the most sophisticated encryption technologies still require you to be very good at encryption key management. If you're not very good at encryption key management, you might encrypt your data and never be able to read it again, which would be quite bad. Key management is not a core competency for all companies, and they're going to quickly learn that a good way to do key management is to not do it everywhere, [but] to do it in pockets where they really need it. And they're going to start realizing this is something that they need to use, but not all of the time.
As told to Karen Goulart, senior features writer.