Follow-On: The Audit, Assertion, Assessment, and Assurance API (A6)
Update 2/1/10: The A6 effort is in full-swing. You can find out more about it at the Google Groups here.
A few weeks ago I penned a blog discussing an idea I presented at a recent Public Sector Cloud gathering that later inherited the name “Audit, Assertion, Assessment, and Assurance API (A6)”
The case for A6 is straightforward:
…take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS and SaaS offering [Ed: At the API layer of each deployment model] to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.
This way you win two ways: automated audit and security management capability for the customer/consumer and a a streamlined, cost effective, and responsive way of automating the validation of said controls in relation to compliance, SLA and legal requirements for service providers.
Much discussion ensued on Twitter and via email/blogs explaining A6 in better detail and with more specificity.
The idea has since grown legs and I’ve started to have some serious discussions with “people” (*wink wink*) who are very interested in making this a reality, especially in light of business and technical use cases bubbling to the surface of late.
To that end, Ben (@ironfog) has taken the conceptual mumblings and begun work on a RESTful interface for A6. You can find the draft documentation here. You can find his blog and awesome work on making A6 a reality here. Thank you so much, Ben.
NOTE: The documentation/definitions below are conceptual and stale. I’ve left them here because they are important and relevant but are likely not representative of the final work product.
A6 API Documentation – Draft 0.11
I’m thinking of pulling together a more formalized working group for A6 and push hard with some of those “people” above to get better definition around its operational realities as well as understand the best way to create an open and extensible standard going forward.
If you’re interested in participating, please contact me ( choff @ packetfilter . com ) and let’s capitalize on the momentum, need and fortuitous timing to make A6 work.
Thanks,
/Hoff
Related articles by Zemanta
- A6 Workgroup On The Way Soon (cloudave.com)
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
Very cool and very timely. Congrats to you and Ben.
It seems to me that vendors at every layer in the stack will be looking to add new pay per use, on demand services. Why not add various aspects of security to the list? Bring the costs of security monitoring out in the open rather than extort it out of the vendor during contract negotiation.
I really like the idea of a XSRL, a security version of XBRL.
You have commented before about "Right to Audit". That too, should be available as an extra cost option. It seems to me that requiring companies to pay for the amount of assurance they feel they need is the right way to go.
This question rose out of a discussion which started in a (private) mailing list. While this previous posts explain the need for A6, how to query for one etc., what is left out is the actual way in which the results are produced within the beast.
Without some form of verifiable, non-doctorable mechanism to produce these results, wouldn't they be only as useful (or useless) as a white paper from the cloud provider?
If the underlying layer within the beast uses the latest and greatest tamper-proof technology like processor powered (like skinit(AMD)/senter (Intel)) guarantee of externally-verifiable code execution that actually performs the audit/compliance tests, then we are talking something.
@Srijith
That's what the working group with various provider participants aims to address.
/Hoff
Sounds interesting. I'm all full up right now but I like to watch…
Sam
I'm a fan of this idea and fully support it but only as a part of the solution, A6 alone won't solve the problem. In much the same way TV viewers are not the actual customers (the advertisers are) the cloud computing consumers are not going to be the actual users of A6, an intermediary that aggregates information on cloud providers (using A6 and other means) will be the true customer of ideas like A6. The more pressing issue that needs to be addressed is the lack of trusted intermediaries for cloud computing that give consumers the ability to keep watch over their providers and find new services according to terms they define specifically for their business. I coined the term "cloud computing security referee" and talk a little bit about it here: http://silvexis.com/blog/2009/08/24/referee-for-c… I would be interested in what your take is.
I guess I am still fuzzy on how can we trust the provider to implement the API correctly. Maybe I am being pessimistic, but what would keep vendors from crafting fake responses? I wouldn't want a certification process, but would an SLA that says "Yeah, we're good for it" be enough?
Because they are essentially self-certifying, and the current many compliance frameworks have an independent validation requirement. Many authorizing officials aren't going to accept output from A6 as a certification artifact.
Just thinking out loud, is there a consideration for providing the control reference as part of the response? You may have already considered that, but it wasn't discussed and it may conflict with one or more of the design philosophy item 3.