Can we API more than vulnerability scans and change management?

I thought a bit more about Chris Hoff's idea of using something like SCAP to provide a Security Stack API (to be honest, at first pass I thought he was only talking about vulnerability scanning, but it's quite clearly more than that)

At last week's local CloudCamp, Glen Brunette lead a session at which we talked about security for IaaS (Infrastructure as a Service) providers. Initially the session started with validating the micro-kernel/hypervisor - either through review, placing it in hardware or providing some sort of integrity metric - but from there we evolved to something a little more useful.

Regardless of the technique, attesting to the integrity of the hypervisor, providing proof that hypervisor is secure, doesn't mean much in isolation. The hypervisor can be the equivalent of Fort Knox and it won't be secure if I can grab a disk from the storage network, clone the virtual machine or walk the server it was running on out the door.

So, we need more than a way to expose security state of the virtual environment. What you really need is a way to attest on the security processes of the entire organization.

In fact, I think I really don't want my cloud provider to tell anyone how patched or unpatched his platform is. What I want him to tell me is how compliant he is with his published security processes (and what his processes are). Processes like user account lifecycle management, logging, auditing, incident response, physical security and take your pick from your favourite ISO27001 derived compliance standard.

I reread Chris Hoff's article on the security stack (love the diagram), but some of the comments by other readers are bothering me - one concentrates on the technical matters and the other again focuses on the "brain in a jar" problem. A lying API is possible but has a number of issues (audience, cost and risk) that mean you're either focusing on the technical aspects of security assessments (only part of the picture) or aren't willing to settle for anything less that a personal audit of the providers entire operation, which is antithetical to what cloud users want.

Ultimately for the die hard security professionals, they'll have to give up the desire to know 100% for sure about security - your business gave up that right when they decided to save money by heading into the cloud (part of the reduce activities in changing the value curve). There is no perfect and cost-effective method for you to determine that you haven't been tricked, so the API's will give you more transparency (into what is rather opaque right now), but eventually you're going to have to make a reasonable decision to trust and live with the risk of a lie.

Why not? You do it already with your software vendors today.

note: While I think this API would provide results on demand, I don't think it should be expected to deliver real-time results - you can't put sensors on everything. During the session at CloudCamp we got to the need for periodic audits of the providers security processes and that periodic should probably be monthly. If this sounds unreasonable, keep in mind Certificate Authorities can have weekly assessments (they rotate through all the major security domains, with full scale audits happening less frequently). I think major cloud providers are becoming as important as certificate authorities are. Ultimately it's up to the provider to decide the frequency, it's just that we should expect them to reveal the freshness of the audit findings.