But definitional maturity doesn't necessarily mean technological maturity, and is always a far cry from security maturity. While we now understand the different flavors and components of the cloud, and even have some relatively good ideas of potential security controls, the diversity of real world offerings and the traditional lack of security prioritization bring all the usual security challenges. The cloud is a collection of various proprietary technologies (mostly) from diverse vendors (mostly), all with different ways of doing things (mostly). Not that I'm complaining: if you work in security and don't enjoy these kinds of challenges, you should probably consider a different career path.
There are really only two reliable security controls -- our service level agreements (SLAs) and personal education and knowledge of the cloud implementation.
Even when clouds are deployed and managed internally, there's usually some level of contract or SLAs involved. These spell out specifically what you can expect from your cloud provider, and if there aren't security SLAs, you have no guaranteed level of security. For a security SLA to be effective, it needs to be written, specific (granular), measurable, and enforceable. If it isn't on a signed piece of paper with clear metrics and penalties for non-compliance, it isn't an SLA. Phrases like, "we will make every reasonable effort to protect your data" are useless. SLAs that require all monitoring of all users and administrators access to sensitive data, with financial penalties for inappropriate access to your data on a per-record basis, are far more useful (and hard to find).
While I don't have room here to cover all potential security SLAs, some things to look for include authentication and provisioning requirements (for your provider and their administrators), specific security controls (e.g. network security), auditing and monitoring requirements, encryption (including how keys are managed), your ability to audit the security controls, change management, and ongoing security assessment reporting requirements.
The next tool at your disposal is your ability to understand and educate yourself on the cloud in question. I don't mean user education, I mean your personal education as the security manager for the project. Security documentation for various cloud offerings is often pretty poor, and personal investigation may be the only way to understand the risks involved. While you can't necessarily manage all the risks, it's absolutely critical to understand -- and then effectively communicate them -- to the business.
What are the potential security controls? What's the architecture (and security architecture) or the platform/service? What does your threat modeling tell you? Which external security controls can you apply/integrate? Don't just trust a one- to three-page security report. Dig in, investigate, and understand how it all works.
While we expect to see a lot of cloud security advances over the coming years, when it comes down to it, today you can only rely on your own brain, and well-written contracts.
Rich Mogull is founder of Securosis LLC and a former security industry analyst for Gartner Inc. Special to Dark Reading.