In the same post, I also pointed out an elegant solution by Craig where he suggested an API call offered by cloud providers that a customer can call with parameters for conveying source IP address(es) that will perform the scanning, and optionally a subset of their Cloud hosted IP addresses, scan start time and/or duration.
Sometime in late June, I wrote a post about a dilemma faced by customers of Cloud based services and pointed out to an elegant solution by Craig Balding of CloudSecurity.org. Unlike the traditional on-premise hosting, where it is possible to conduct external vulnerability scanning to check the security state of the computing environment, the Cloud based on-demand hosting offers an unique dilemma due to the multi-tenant nature of the Clouds.
multi-tenancy is fast becoming the important keyword. In this new era
of shared resources, businesses are increasingly facing the dilemma of
not being able to do the scan. They can’t do the penetration testing to
make sure that their environment is secure. In fact, most of the Cloud
providers explicitly prohibit such a scan through their terms because
any scan employed by a business has the potential to disrupt the
services for other customers.
Christofer Hoff, building on Craig Balding’s idea, suggested that such an API, along with the vulnerability scanning, should provide a standardized way to do configuration management, asset management, patch remediation, compliance, etc.. He concluded that He named it “The Audit, Assertion, Assessment, and Assurance API (A6)” taking some help from his colleagues on Twitter. Slowly, the idea gained some traction. He, along with few other security gurus including Ben from Canada, started working on a RESTful interface for accessing the A6 API.
In short, the A6 API is a security stack designed to provide Audit, Assertion, Assessment, and Assurance capabilities. The A6 API is designed to provide end-user organizations with the ability to query cloud computing service providers (regardless of classification as a Infrastructure as a Service, Platform as a Service or Software as a Service) about the security state of the provider’s environment.
The A6 API was developed with the intent to ensure the following core issues.
- The security stack MUST provide external systems with the ability to query a utility computing provider for their security state
- The stack MUST provide sufficient information for an evaluation of security state asserted by the provider.
- 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.
- 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. - The stack SHOULD reuse existing standards, tools and technologies wherever possible.
The API uses RESTful architecture to access the following security functions from the Cloud service providers
- Audit
- Assertion
- Assessment
- Assurance
Ben, a security guru based in Canada, was responsible for putting together the RESTful expressipon. He has also completely documented his work in every step of the way in his blog. The net result is the release of an early version draft of A6 API Documentation.
So, the natural question will be “Is this the ultimate magic potion for cloud security”. Hell, NO. It is not the cure all miracle pill which everyone dream off. There is no way this will make the Clouds most secure. In fact, the only way to make your data really secure is to lock them up in a secure bunker inside your corporate office area and surround it with double the magnitude of security as Gitmo. Even then, we can’t be sure that the data will be secure. This is just the first step in establishing a protocol to develop some kind of trust between the cloud vendors and their customers.
Update: If you are a security guru with interests in Clouds and want to contribute to A6 Working Group, please contact Christofer Hoff. If you are a Cloud Vendor interested in playing a role in working out the details, you should be contacting him too.
