In May, Christofer Hoff wrote a very interesting post about one of the unintended consequences of enterprise use of cloud services ... the serious and costly impact of right to audit clauses in the service contracts and their impact on *aaS. He posits that the enterprise customer now does make much heavier use of the RTA. So distinctly different is the level of use, that it's generating exceptionally high costs for the *aaS provider.
The sense I get (from Hoff, the comments, and from speaking directly to cloud service providers) is that the RTA clauses have been just that... clauses in a contract, with very little actual planning and preparation by the individual service provider. Thus, every invocation of the right ends up being a one-off project, distracting the provider, and diverting precious engineering and operations resources. (At the time, I commented that it sounds like a commercial opportunity. )
Yesterday, Hoff posted an extension to the concept, suggesting a security API for Cloud Stacks. I was 'off the grid' most of the day, but discovered when I reconnected that it generated a huge volume of twitter traffic. The post posits a sensible consideration: compliance structure commonality suggests that they could be 'built in' to a security control model. The result would be open API(s), which would be (voluntarily) implemented by the providers of *aaS stacks. This would provide for an open architecture for scanning a provider's offering for network vulnerabilities, as well as configuration management, asset management, ...
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.
I haven't yet waded through the resulting twitterstorm, but it's formidable. It also gets into some strongly held, loudly presented 'religious' positions from a number of the security twitterati, which I don't pretend to follow comprehend.
This is a brilliant suggestion that's operationally difficult to get implemented over the broad range of *aaS providers. The pragmatics of getting this kind of adoption starts with getting agreement on a security automation regimen (such as SCAP). Having once figured which flavor of security automation, it seems that there will be a requirement for a trusted (open) third party -- a community effort or a vetted commercial ecosystem -- that prosecutes this through the 'cloud community.'
I expect some substantive discussions within the CSA community, and look forward to it as an interested observer and (potential) beneficiary. I'm really interested to see who picks up the mantle. Given the importance of BOTH the necessity of improved cloud audit and an open security management regimen, I hope that the Feds jump into this as a constituency with a real, economic need. If the government's production use of *aaS is as important as they seem to indicate, this should be given big-time attention by the country's CIO.
Comments