When it comes to data security in the cloud, two things are true: First, more and more sensitive information is...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
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.