This is the first in a series of blog posts by Carlos Cardenas, our Director of Solutions Engineering. Carlos is a security expert who came to Joyent from The Institute for Cyber Security ICS at the University of Texas, San Antonio. While at ICS, Carlos worked underRavi Sandhu, PhD, one of the leading security expertsin the world.

In my first post, The Four Keys of Cloud Security, I talked about the four security issues that are important for Cloud Service Providers (CSPs) and their customers. In this post, I will focus on Key #1: Confidentiality.

Current State of Keeping Your Data: For Your Eyes Only

Today, no CSP can guarantee that your data will be secured “For YourEyes Only.” Encryption algorithms and compliance policies can onlyachieve so much. Let’s start by looking at current best practices.

From the CSP perspective, we have to take reasonable measures to ensurecustomer data is not used in any way by the provider that is unintendedby the customer. As a way to mitigate exposure of customer data,some CSPs encrypt data at rest using encrypted hard drives orencrypted file systems. The other part of the equation for riskmitigation is proper device destruction either logically,using an appropriate method of sanitization like DoD 5220.22-M or physically DSS Clearing and Sanitization Matrix and Special Publication 800-88: Guidelines for Media Sanitization.

And then, there are the backups. CSPs manage several copies of datato prevent total failure in both onsite and offsite facilities, and morethan likely, the data stored on tape or other hdds is encrypted.

Once you have encrypted drives and encrypted backups, you have to deal with a little problem called key management. This turns out to be a problem because some CSPs use only a handful (if that many) of encryption keys that are known to a select few of the systemadministrators in charge of ops and compliance. That begs the question: If a system administrator leaves (on their own free will or not), are thekeys changed? More than likely, yes. But what about the backups? How long is the time window during which the now departed administrator can accesscustomer data? I usually hear crickets when I ask this question of CSPs - even those with plenty of acronyms and certifications behind their name.

From the customer perspective, I don't want any of my data readable byanyone except me. If my CSP encrypts my data when it's at rest,I want to make sure no one can access it in other ways, such as from a backupmy CSP performs regularly. What this means to me is, before data leavesmy control and into my CSP, all data must be encrypted using standardencryption algorithms and key(s) that I manage.

In the following example, I'm assuming S3 is a HDFS-like entity made upof NameNodes and DataNodes.

Currently, Amazon offers Service Side Encryption (SSE) for S3. When datais put into S3, a process blocks your data (into X MB chunks) where eachblock of data is encrypted by a key chosen from this process. Every file has aseparate key and after T amount of time, the file is re-encrypted with a new key.

Sounds awesome, except that we don’t know where the keys are stored. Are there backups of the keys for disaster recovery and high availability purposes (think of HDFS NameNodes)? We are back in the same conundrum where we started with encrypted backups.

What Can Be Done Today

Today, customers have two options based on their tolerance for risk:

• Leave data unencrypted at rest and trust the CSP
• Encrypt all data before it is sent to the CSP

In this post, I wanted to bring out the issues with confidential customer datain the cloud, as this is not a solved problem. Encryption is only meant to providesome assurance that no one other than key holders can view the data.

But what if there was another way? What if I could store my data, unencrypted,at rest with the CSP and guarantee my data hasn't been altered? In my next post,I'll talk about Key #2: Integrity, and how we can use it to build trust inCloud Computing.