Roman Sakhno - Fotolia

Get started Bring yourself up to speed with our introductory content.

Data security in cloud computing: Data encryption controls

Implementing data encryption controls in a cloud environment can be quite challenging for organizations using those services. Ed Moyle discusses the first two steps to implementing data security in the cloud.

When it comes to data security in the cloud, two things are true: First, more and more sensitive information is going there, and second, traditional data protection controls like encryption of data at rest are unlikely to be applied once it's there.

As a proof point of that statement, consider the recent 2013 Global Trends in Cloud Encryption research report from Ponemon Institute published in April 2014. According to the survey, 53% of organizations have transferred sensitive or confidential data to the cloud. Yet only 39% of data in software as a service (SaaS) applications is encrypted, and that number lowers to 26% when it comes to platform as a service (PaaS) and infrastructure as a service (IaaS) deployments.

It probably goes without saying that there are some good reasons why this is the case. First of all, data protection controls in a cloud context can be challenging to implement architecturally. Recall that in the cloud, the underlying portions of the stack below that which the customer uses are deliberately opaque; the customer (by design) cedes direct control over these layers to the cloud service provider (CSP) from a management standpoint. So, unless the CSP specifically provides data protection features (note that some do), a customer's ability to implement technical data protection controls without additional engineering might be constrained.

Secondly, from a process standpoint, these controls can be challenging to pull off. There might be legitimate reasons why a CSP requires access to enterprise data -- for example, to debug application functionality or in the case that they provide monitoring services to your company. This means that the logistics of who will hold the encryption keys, as well as whether, how and even if the CSP can get access to them for legitimate business purposes requires discussion, planning and well-thought-out procedures established in advance.

On the one hand, data protection controls have implementation challenges. On the other, they are still advantageous, or in some cases even required by regulatory mandates.

This leaves practitioners in a quandary. On the one hand, data protection controls have implementation challenges in the cloud. On the other, they are still advantageous, or in some cases even required by regulatory mandates: Such is the case for cardholder data in a PCI DSS context or PHI under HIPAA. The organization using the cloud service might wish to have safe harbor in the case of a breach, or maybe simply the organizational security policy requires them to implement these controls.

Solving this quandary means getting smart about approaching these controls. Not everyone will be in a position to implement cloud data encryption controls right away, but even so, taking a few steps now lets organizations analyze both the security benefits they'd get and where those benefits are most needed. It will also help companies understand the level of difficulty if and when they do implement, and, if done strategically, can actually make the implementation process that much easier when a business does decide to pull the trigger.

Laying the groundwork

The first of these steps is data classification and service inventorying. This sounds like "eat your vegetables" advice at some level, but the reason why it's important is the sheer volume of cloud services that even a modest-sized organization will have in play. Most organizations have dozens of cloud services in active use; in fact, if you include SaaS applications -- both sanctioned ones and consumer-oriented services employees may use with or without your say-so -- cloud services might number into the hundreds or even thousands.

Not all of those applications will process sensitive or confidential information, so not every one will require encryption of data. Distinguishing which applications are appropriate to apply encryption to from those where it is not is the crux of this first step. Essentially, the goal is to identify and record -- in as granular detail as possible -- where data an enterprise might want to encrypt resides in the cloud. For some situations (i.e., SaaS), "as granular as it gets" might be that the data is held at a certain CSP. For others (i.e., IaaS), it could be that you get down to the level of a certain virtual device or storage container. The point is, your organization should know which applications and environments process the data you care about, versus those which do not, and you should be able to construct a rough idea of where you'd need to apply controls.

If this sounds like a tall order, it can be. Start with a manageable subset and build on it. There are tools that assist in this regard. In a private cloud context or one where your business has a fairly extensive relationship with an IaaS provider, virtualization-aware tools (e.g., Catbird or TrendMicro's Deep Security platform) can assist in the inventorying of specific hypervisors to help determine what's running where. SaaS discovery tools exist as well, but in a pinch some service-level information can be gleaned from examining user traffic (e.g., logs, NetFlow, etc.) To automate the task of keeping track of specific systems and applications, free tools like SpiceWorks or OCS Inventory NG can provide an assist as well to record services and usage as they're identified. The point is, organizations need to establish which data is in which environments so that they can prioritize their efforts.

Evaluating specific usage

After data classification and service inventorying, the next step is where the "rubber meets the road." It's here where your organization must evaluate the specific usage, make the determination about whether it will encrypt, and decide how it will implement encryption.

Note that depending on the cloud computing model or service your organization is using, it may need to select different tools to effect this. For example, if you have a high-sensitivity SaaS application and you want to encrypt data within it, effecting this is very different from encrypting a database within a PaaS or encrypting volume storage in an IaaS.

With an IaaS use case, for example, since you have access to the underlying OS on virtual images within that environment, you might choose to implement a tool that operates at the file-system level. In fact, Microsoft and most Linux distributions natively support encrypted file systems that may be viable options. There are dozens of commercial products that support this as well. For a PaaS, your choices might be more limited; you may need support from the developers actively working in the PaaS to author code that leverages CSP APIs or that leverage specific APIs in the application environment they're working in. And, of course, in a SaaS context, since the entirety of the application stack is managed by the CSP, you may find yourself looking to reverse-proxying tools (e.g., CipherCloud) or a specific SaaS-integrated product (e.g., CloudLock) to accomplish that.

The point is, the tools vary. And these differences should be noted and planned around; if your organization needs to purchase multiple tools to do this, it will need to plan its budget accordingly. Using the inventory and data classification evaluation that you've already done can help prioritize which approach is most valuable and/or urgent.

The upshot of this all is that just because your organization can't encrypt data in the cloud right now -- or doesn't have the time/budget/staff to -- doesn't mean it's a "dead topic." By doing some of the preparation in advance, you can help prioritize future efforts, decide what purchases are most relevant for your business and help move the needle as cloud deployments only start to snowball further down the road.

About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.

Next Steps

Get additional help performing data classification and learn cloud application inventory tracking best practices.

Dig Deeper on Cloud Data Storage, Encryption and Data Protection Best Practices

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is your organization's data in the cloud encrypted? How do you ensure this?
Assuming that a classified data be protected by an encryption key of 256-bit entropy and the program to manage the system be protected by a manager’s password such as P@$$WoRd1234, the chances may well be that the system will have been taken over by the criminals who broke the password rather than those who tried to attack the 256-bit encryption key. It could be emphasized that sufficiently strong passwords are the key for the safe deployment of cryptography.Using a strong password does help a lot even against the attack of cracking the stolen hashed passwords back to the original passwords. The problem is that few of us can firmly remember many such strong passwords.  We cannot run as fast and far as horses however strongly urged we may be. We are not built like horses. At the root of the password headache is the cognitive phenomena called “interference of memory”, by which we cannot firmly remember more than 5 text passwords on average. What worries us is not the password, but the textual password. The textual memory is only a small part of what we remember. We could think of making use of the larger part of our memory that is less subject to interference of memory. More attention could be paid to the efforts of expanding the password system to include images, particularly KNOWN images, as well as conventional texts..
For security reasons there is only one person who should know the encryption key and that the the owner of the data.
It is as simple as that.
Anything else poses a security risk.