Follow-On: The 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.
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.
Related articles by Zemanta
- A6 Workgroup On The Way Soon (cloudave.com)