The Four Keys of Cloud Security: Mutual Auditability

June 18, 2013 - by Carlos Cardenas

This is the fourth 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 from The 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 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 the first post, I focused on Key #1: Confidentiality. In the second post, I focused on Key #2: Integrity. In the previous post, I focused on Key #3: Availability. In this post, I’ll talk about the holy grail of cloud security, Key #4: Mutual Auditability.

What is Mutual Auditability?

This is the holy grail of cloud security, and it’s one that many providers are not aware of. What this means is that as an administrator, you can verify to the user that their actions are their actions, and that you didn’t complete any actions yourself. As a user, I can also verify that my actions are my actions -- I can see that I’m the one that performed them. Most importantly, an auditor (or any other 3rd party for that matter) can go in and determine which actions were completed by which parties. This concept in cloud security stemmed from a UC Berkeley Tech Report in 2010.

But before we get to that, let’s review the items that we need in order to provide 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.

    To have mutual auditability, I now want to expand that list to include the following:

  4. For all data I upload to my CSP, I can ensure I have the latest revision of my data. Currently, this can’t happen without much work on either the customer's or the CSP's end.

  5. I can ensure I am charged the correct amount for data at rest and data in motion by my CSP. Currently, there’s no way of doing this.

Using Joyent I have the first three, but what about data fingerprints on my data? And how can I ensure I have the latest version of my data?

There's a technology called Keyless Signature Infrastructure (KSI) developed by Guardtime (Disclaimer: Guardtime is a strategic partner of Joyent). KSI is a system based on the building blocks of MACs, high resolution timestamping, hash chains and hash trees. KSI provides: proof of integrity, proof of time and proof of signing authority. It is considered keyless as it is based entirely on formal methods of hash functions and not cryptographic keys; essentially, key management is thrown out of the window as it's not needed. The best part of KSI is that by the nature of the technology data is tamper-evident, signatures never expire, and it can be used by the user, the CSP and an arbitrary 3rd party (i.e. auditor) to verify both the order of events and that the event hasn't been altered. (For a more in-depth technology overview, see Guardtime's technology overview.)

So if a CSP has Guardtime's KSI technology integrated into their APIs and portions of their subsystems like storage, then not only will each data object have its own signature, but all future revisions of the data will have it as well, ensuring the order of operations (ie., that this rev came before this rev). So now we have #1 - #4 accomplished, how about #5?

To accomplish #5, a CSP will have to extend KSI into every piece of their architecture.

Let’s say that as a CSP, I have incorporated Guardtime into my hypervisor rsyslog and BSM. I can tell that every log event and every event that is audited via BSM occured in the order that they were logged, that they actually occured (no tampering), and who performed the event. I also built all APIs to use Guardtime to log all events (either directly using node-guardtime or using rsyslog). What does that get me?

I now have a system where every event (CSP administrative or user) is independently verifiable by the CSP, the user and any 3rd party. I can show these events to the user at anytime to prove to them we did X, they did Y and at any point where there’s disagreement, we can go to any 3rd party arbitrator for verification. Also, as a CSP, I can now provide all account details for user with 100% certainty, which eliminates over and under charging by the CSP by providing the most accurate billing information.

Mutual auditability was thought to be an unattainable goal just a few years ago. Today, we are closer than ever to realizing it. In previous incarnations of mutual auditability in Cloud Computing, there was a DARPA project based on Attribution-based Architectures where each entity of the system could not forge their actions to provide a near leak proof system. The details of the system were not widely published. However, in the public cloud age, such a system didn't exist, until now. When you combine the latest rsyslog, BSM, and Guardtime, the public cloud provides a higher level of security than anything that can be done in-house.

Sign up Now For
Instant Cloud Access

Get Started