Research

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. Share:

I was somewhat captivated by Lenny Zeltser’s recent post on a Protean Information Security Architecture. His idea is that another set of controls can be based on confusing the attacker. If you open/close different potential attack vectors, you can somewhat obscure the real payload you are trying to protect. Of course, Lenny nails that complexity cuts both ways: An environment that often changes may be harder to attack, but it is also hard to manage. In fact, many vulnerabilities seem to be associated with our inability to securely and timely implement changes, such as deploying security updates or disabling unnecessary services. But I think the concept is solid. It’s basically a more sophisticated approach to honeypots. But this time the objective isn’t necessarily to catch the bad guys in the honeypot – instead it’s to make their lives harder. And we all know that most attackers take the path of least resistance. So if they get confused, or their automated reconnaissance scripts miss stuff or dead-end, most will move on to the next target. But I’m very sensitive to the complexity issue. At scale, far too many organizations can barely manage their devices and network configurations (and I’m being kind). So as Lenny says, we need to make sure we don’t add even more management overhead and create a situation that inadvertently creates exposures due to operational failure. Lenny lays out a couple tactics that could confuse attackers, like opening/closing perimeter firewall ports, tarpitting inbound packets, building fake Internet servers, etc. All these are interesting concepts, but again create significant management overhead to provision and de-provision with enough variation to not be obvious obfuscation. And then it hit me. A lot of these operational tactics could be scripted and deployed in a private cloud, perhaps within your DMZ. Scripts could be built with varying attributes ti make the desired changes (likely on a second set of devices, to avoid messing with production/operational security) without requiring a lot of overhead. Basically you would build a sophisticated honeynet in a private cloud. A “HoneyCloud” of sorts. Sure, there are clear risks to this approach. Do it wrong and you could create holes large enough to drive a truck through. You would need to revisit the patterns & scripts every so often to change things up. You would have to invest in additional infrastructure to run this stuff. So it’s probably not for everyone, or even for most. But as Lenny says: “a protean approach to defense isn’t foolproof–it is one of the elements we may be able to incorporate into an information security architecture to strengthen our resistance to attacks.” I don’t know. I’m not sure if it’s just interesting as a shiny object, or if there is more there. Whether it’s operationally practical or economically feasible. We know this wouldn’t deter a persistent attacker for long. It doesn’t address targeted client-side attacks either. But at least it’s an interesting intellectual exercise. What say you? Is there anything to this Proteus stuff, or am I smoking seaweed? Share: