Initial Thoughts on Cloud A6

I'm a little late to this issue, but let me start by saying I read Craig Balding's RSA Europe 2009 Presentation this evening. In it he mentioned something called the A6 Working Group. I learned this is related to several blog posts and a Twitter discussion. In brief:

  • In May, Chris Hoff posted Incomplete Thought: The Crushing Costs of Complying With Cloud Customer “Right To Audit” Clauses, where Chris wrote Cloud providers I have spoken to are being absolutely hammered by customers acting on their “right to audit” clauses in contracts.

  • In June, Craig posted Stop the Madness! Cloud Onboarding Audits - An Open Question... where he wondered Is there an existing system/application/protocol whereby I can transmit my policy requirements to a provider, they can respond in real-time with compliance level and any additional costs, with less structured/known requirements responded to by a human (but transmitted the same way)?

  • Later in June, Craig posted in Vulnerability Scanning and Clouds: An Attempt to Move the Dialog On... where he spoke of the need for customers to conduct vulnerability assessments of cloud providers: A “ScanAuth” API call empowers the customer (or their nominated 3rd party) to scan their hosted Cloud infrastructure confident in the knowledge they won’t fall foul of the providers Terms of Service.

  • In July, Chris extended Craig's idea with Extending the Concept: A Security API for Cloud Stacks, building on the aforementioned Twitter discussions. Chris mentioned The Audit, Assertion, Assessment, and Assurance API (A6) (Title credited to @CSOAndy)... Specifically, let’s take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.

Still with me? In August Network World posted A6 promises a way to check up on public cloud security, which said:

What cloud services users need is a way to verify that the security they expect is being delivered, and there is an effort underway for an interface that would do just that.

Called A6 (Audit, Assertion, Assessment and Assurance API) the proposal is still in the works, driven by two people: Chris Hoff - who came up with the idea and works for Cisco - and the author of the Iron Fog blog who identifies himself as Ben, an information security consultant in Toronto.

The usefulness of the API would be that cloud providers could offer customers a look into certain aspects of the service without compromising the security of other customers’ assets or the security of the cloud provider’s network itself.

Work on a draft of A6 is posted here It’s incomplete, but offers a sound framework for what is ultimately needed.

So let's see what that says:

The A6 API was designed with the following concepts in mind:

  1. The security stack MUST provide external systems with the ability to query a utility computing provider for their security state. Ok, that's pretty generic. We don't know what is meant by "security state," but we're just starting.

  2. The stack MUST provide sufficient information for an evaluation of security state asserted by the provider. Same issue as #1.

  3. The information exposed via public interfaces MUST NOT provide specific information about vulnerabilities or result in detailed security configurations being exposed to third parties or trusted customers. Hmm, I'm lost. I'm supposed to determine "security state" but without "specific information about vulnerabilities"?

  4. The information exposed via public interfaces SHOULD NOT provide third parties or trusted customers with sufficient data as to infer the security state of a specific element within the providers environment. Same issue as #4.

  5. The stack SHOULD reuse existing standards, tools and technologies wherever possible. Neutral, throwaway concern.

That's about it, with the following appearing below:

In classic outsourcing deals these security policies and controls would be incorporated into the procurement contract; with cloud computing providers, the ability to enter in specific contractual obligations for security or allow for third party audits is either limited or non-existent. However, this limitation does not reduce the need for consuming organizations to protect their data.

The A6 API is intended to close this gap by providing consuming organizations with near real-time views into the security of their cloud computing provider. While this does not allow for consuming organizations to enforce their security policies and controls upon the provider, they will have information to allow them to assess their risk exposure.

Before I drop the question you're all waiting for, let me say that I think it is great people are thinking about these problems. Much better to have a discussion than to assume cloud = secure.

However, my question is this: how does this provide "consuming organizations with near real-time views into the security of their cloud computing provider"?

Here is what I think is happening. Craig started this thread because he wanted a way to conduct audit and compliance (remember I highlighted those terms) activities against cloud providers without violating their terms of service. I am sure Craig would agree that compliance != security.

The danger is that someone will believe that complaince = security, thinking one could conceivably determine security state by scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc..

This is like network access control all over again. A good "security state" means you're allowed on the network because your system is configured "properly," the system is "patched," and so on. Never mind that the system is 0wned. Never mind that there is no API for quering 0wnage.

Don't get me wrong, this is a really difficult problem. It is exceptionally difficult to assess true system state by asking the system, since you are at the mercy of the intruder. It could be worse with cloud and virtual infrastructure if the intruder owns the system and the virtual infrastructure. Customer queries the A6 API and the cloud returns a healthy response, despite the reality. Shoot, the cloud could say it IS healthy by the definition of patches or configuration and still be 0wned.

I think there's more thought required here, but that doesn't mean A6 is a waste of time -- if we are clear that it's more about compliance and really nothing about security, or especially trustworthiness of the assets.


Christofer Hoff said…

Methinks the horse is a little bit afar from the cart...

So I'm close to spinning up the next rev. of effort around A6; I've just been so stinking busy. I have two very large cloud providers who are going to be contributing to the project.

You're missing a couple of key elements regarding A6 that quite frankly I am guilty of not supplying.

Quickly, to the point about A6 providing "security" views of a provider -- A6 will go much, much deeper than simply running vulnerability scans.

Specifically, with things like the vCloud API, you get the capability of extracting configuration information regarding all sorts of things: networking, topology, storage, policy, etc...

You can imagine then that beyond "compliance" you can make decisions about policy and enforcement because you gain back visibility...

Your assessment is not out of line given what we've provided and I promise an update soon, but feel free to ping me if you want more information ahead of time.

rdr said…
Very random question, I found you blog when searching for a price list for an item I purchased at auction. Can you please let me know what a 2004 Niksun NetVcr02 might be worth. I tried searching the internet but couldnt find pricing information.

vmcto said…
I think the other issue that this doesn't address at this point (no criticism, as you said it's very early) is reporting of an "incident".

How do I know as a cloud consumer that an "incident" that may have compromised security occurred, was identified, and remediated?

How does that fit into my demonstration of controls for my compliance and risk management?
CyberG said…
I think any security professional that endorses Cloud Computing is clueless. While it might make sense for a large corporation to run their own internal cloud, who in their right mind would think their data would be safe lumped together with other company's data. Can you say massive target? Not to mention, you are being subjected to outsourcing across the board. It might be one vendor your cutting a check to, but the backend storage and HA infrastructure will be farmed out to a bunch of third tier providers you've never heard. That is until your data vanishes overnight, then all the sudden that vendor is a household name (i.e. Choicepoint).

A Ponemon Research report suggests the following:
"As yet more companies own up to large-scale losses of personal data, a survey has found that the risk of confidential data being lost or stolen is 43% higher when it is outsourced rather than held in-house."

I'm also really glad Richard is driving home the point, compliance doesn't equal security. This needs to be hammered into the heads of all the CISOs, CTOs, etc so this insane "Check box" security culture will go away.
Unknown said…
It seems too many orgs can't evaluate their own security and systems, let alone provide not only that, but a sanitized way of displaying that information to the customer in a way that illustrates security (or better yet, just compliance to whatever finite checks there are in this system). Let alone realtime at will...

But still, I think discussion on this is better than throwing up hands.

Maybe this is really just supposed to be a color-coded dashboard or security scorecard. In which case, why would any company not show anything besides green, green, green, at least until something breaks in the media.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics