The Four Keys of Cloud Security: Integrity

This is the second in a series of blog posts on cloud security by Carlos Cardenas, our Director of Solutions Engineering. Carlos is a security expert who came to Joyent fromThe Institute for Cyber Security ICS at the University of Texas, San Antonio. While at ICS, Carlos worked under Ravi Sandhu, PhD, one of the leading security experts in the world.

In the previous post, I focused on Key #1: Confidentiality. In this post, I will focus on Key #2: Integrity.

I ended my previous post with an open question about having the ability to store data, unencrypted, at rest with a CSP and being able to guarantee that data hasn't been altered.

Before I get there, let’s go over what integrity is and how it’s used to build a foundation of trust between a CSP and their users.

Integrity, in it's original definition for information security purposes, is maintaining and assuring the accuracy of data over its entire life-cycle and its provenance. You can stretch this definition to include authenticity, validation of all parties and non-repudiation (meaning a transaction occurred once and only once.)

Typically, MAC (Message Authentication Codes) and HMAC (Hash Message Authentication Codes) are used as a signature for a file in order to provide integrity for the data. They also preserve its authenticity by allowing others to perform the same MAC calculation on the data in question to determine if it has changed. This can be done with data in motion in a HTTP Request/Response such as HTTP Signature as well as with other protocols and even some filesystems, such as ZFS, which uses MACs as a method to perform data authenticity in the form of protection against bit-rot.

So let's review what we’d like to see when it comes to providing integrity in the cloud:

1) All communication, SSH and HTTP(s) using HTTP Signature, is verified as accurate/legitimate.

2) For all data I upload to my CSP, I can attach a signature (MAC) to verify if the contents have changed.

3) For all data I upload to my CSP, I am sure it will be the same in the future.

Number one and number two are standard, but number three is only true if the cloud provider is using ZFS or some erasure encoded (Reed-Solomon error correction) storage system.

What Can Be Done Today

Two out of three isn't bad, but in an ideal world, we’d like to have three out of three. Here are some steps you can take to have certainty that your data will be the same in the future.

  • Ensure your CSP uses only SSH and HTTP(s) with additional authentication schemes on their API endpoints. Joyent uses and recommends using HTTP Signature .
  • Ensure your CSP uses either ZFS or another erasure encoded filesystem for storage (simple block replication does not suffice). (Joyent uses ZFS for everything.)
  • Attach a signature (hash) for every file you upload to ensure its integrity.

However, that last one will require some work on the behalf of the user unless a CSP provides this capability.

Now, we have our data protected in motion and at rest with file signatures and bit rot protection with ZFS. Let’s see if we can survive different degrees of failures and still maintain integrity.

Dead disk: Check, ZFS has got your back.

Dead Array: Check, but only if the CSP has backups and/or your data is in another location.

Dead Storage Service: Well, that’s a question that’s best answered in another post.

In my next post, I'll talk about Key #3: Availability, and why it doesn't matter what kind of encryption algorithms or authentication methods are used if you cannot access your data.



Post written by Carlos Cardenas