Many really smart people helped author the Cloud Security Alliance Security Guidance. Many of the original authors posses deep knowledge of security within their domains of expertise, and are widely considered the best in the business. And there are many who have deep practical knowledge of operating in the cloud, and use cloud technologies on a daily basis. Unfortunately very few people have all three – especially the third. And perceptions have changed a lot since 2009 when the guide was originally drafted. Why is that important? After having set up and secured several different cloud instances, then working through the cloud security exercises Rich created, it’s obvious the guidance was drafted before the authors had much experience. It’s based on theoretical knowledge of what we expected, as opposed to what we do encounter in any given environment. Some of the guidance really hits the mark, some of it is awkward, and some of it is just not useful.
For example, Domain 5 of the CSA Guidance is Information Lifecycle Management – a section Rich helped draft. Frankly, it sucks for cloud security. Rich and I have both been using the data centric security lifecycle model for several years, and it works really well as a data security threat model. It’s even better for understanding where and how to deploy Information Centric Security (DRM & DLP) technologies. But for securing cloud installations it has limited practicality. It under-serves identity and access control concerns, fails to account for things like keys instance in instances and security domains, and misses management plane issues entirely. It’s not so much needing a different risk model, but more about understanding the risks we need to plug into the model. The lifecycle teaches where to apply security – it does not capture the essence of cloud security issues.
About a year ago Chris Hoff created 5 Rules Of Cloud Security. After reading that I read through the CSA Guidance and spun up some Amazon EC2 instances and PaaS databases. I then applied the lifecycle where I could – and considered the security issues where I could not feasibly deploy security measures. In that light, the lifecycle made sense. A year later, going through CSA training demos for the first time, the risk areas were totally different than I thought. Worse, I have been writing a series on Dark Reading, and about 3 posts in I started to see flaws in the model. About that time Rich completed the current cloud security training exercises, and I knew my blog series was seriously flawed – the lifecycle is the wrong approach! I’m going to take a mulligan on that series, wrap it by pointing out how the model breaks for databases, and make some suggestions on what to do differently.
The point here is that much of what has been written over the last couple years – specifically the CSA Guidance but other guides as well – needs revision. The advice fails to capture practical issues and needs to keep pace with variations in service and delivery models.
For those of you who consider Securosis comments such as “few understand cloud security” to be ‘boastful’, that means we failed to make our point. It’s an admission that we all have a long way to go, and we occasionally get it wrong. Some of what we know today will be obsolete in 6 months. We have already proven some of what we knew 18 months ago is wrong. Most people have just come to terms with what SaaS is, and are only beginning to learn the practical side of securing SaaS without breaking it. We talk a lot about cloud service models, and many of us suspected a top-down adoption of SaaS to PaaS to IaaS was going to occur. Okay, maybe that was just me, but the focus of cloud security discussions are weighted in that order. Now adoption trends look different. Many early cloud adopters are starting private or community clouds – which are unique derivations of IaaS – to get around the compliance issues of multi-tenancy. Once again, principal security concerns for those cloud delivery models are subtly different – it’s not the same as traditional IT or straight virtualization, and a long way from SaaS.
Comments