CloudAudit API 1.0 submitted as IETF draft

A number of cloud computing experts joined Christofer Hoff, the Director of Cloud & Virtualization Solutions at Cisco, in his project to develop a standard interface to simplify the auditing and the security assessment of cloud computing infrastructures.

Originally called Automated Audit, Assertion, Assessment, and Assurance API (A6), the interface has been later renamed CloudAudit API.

The working group that is developing it includes representatives from Akamai, Amazon, Arcteck, CloudScaling, CSC, enStratus, Google, Microsoft, Orchestratus, Rackspace, Savvis, TELUS, Unisys and VMware.

The team published the API 1.0 as an IETF draft at the beginning of the week:

CloudAudit provides a common interface, naming convention, set of processes and technologies utilizing the HTTP protocol to enable cloud service providers to automate the collection and assertion of operational, security, audit, assessment, and assurance information.
This provides duly authorized and authenticated consumers and brokers of cloud computing services to automate requests for this data and metadata.

CloudAudit supports the notion of requests for both structured and unstructured data and metadata aligned to compliance and audit frameworks.  Specific compliance framework definitions and namespaces ("compliance packs") will be made available incrementally.

The first CloudAudit release is designed to be as simple as possible so as it can be implemented by creating a consistent namespace and directory structure and placement of files to a standard web server that implements HTTP [RFC2616].  Subsequent releases may add the ability to write definitions and assertions, and to request new assertions be generated (e.g. a network scan).  That is, while 1.x versions are read-only, subsequent releases may be read-write.

A duly authorized and authenticated client will typically interrogate the service and verify compliance with local policy before making use of it.  It may do so by checking certain pre-defined parameters (for example, the geographical location of the servers, compliance with prevailing security standards, etc.) or it may enumerate some/all of the information available and present it to an operator for a manual decision.  This process may be fully automated, for example when searching for least cost services or for an alternative service for failover.

As it is impossible to tell in advance what information will be of interest to clients and what service providers will be willing to expose, a safely extensible mechanism has been devised which allows any domain name owner to publish both definitions and assertions…