Lee Newcombe: Securing cloud services: when theory meets practice
Tue 20 May 2014
There‘s plenty of received wisdom about cloud security – for a start, that there is indeed a “cloud” to secure and it is inherently insecure… Lee Newcombe, chief information risk advisor, at Capgemini challenges the theories with practical experience
“In theory there is no difference between theory and practice. In practice there is.”
This is a favourite quote of mine, and it seems incredibly relevant to the current state of cloud computing security.
There is a lot of guidance out there around how to do cloud computing securely. “Avoid US-based services so that you avoid the NSA”; “negotiate your security requirements into your contracts with your cloud providers”; “make sure you encrypt everything you put in the cloud”… the list goes on.
But, in practice, are these controls effective? Are they actually implementable? And are they even desired? Much of the time, theory is churned out with little consideration of how – or even whether – it will work in practice, and challenging the most common security mantras is something I spoke about at Cloud Expo Europe.
The first misconception that needs addressing is fairly basic, but it is at the heart of so many security issues – “cloud is just cloud, right, just a set of computers in someone else’s datacentre?” Facebook is cloud. Amazon Web Services is cloud. Salesforce.com is cloud. Your virtualised data centre is now a private cloud. There is no general understanding that not all clouds are the same. I often come across clients whose initial impression of cloud is that it’s simply a set of computers on the internet in someone else’s data centre.
The problem with this is that each combination of the different service and deployment models actually gives you a different set of security questions to answer. There are lots of individual cloud services, each with their own traits (including security services), and it’s vital to your security that you understand where the responsibility sits for each aspect of security – with you or with your provider.
One of the perceived benefits of the cloud model is the speed with which you can get a service up and running, after all “you just need a credit card and an Internet connection and away you go.” If you’re doing this on a personal basis then yes, it really is very easy to sign up with, and start using a cloud service, but if you’re looking to procure a service more formally for a large enterprise then in reality it is not that easy.
Procurement teams often do not get the cloud model. They are not used to going to the market and seeing what is already available (and compromising on their original requirements) rather than just purchasing bespoke solutions. There is a more cloud-friendly approach to procuring services, but it does rely on the procuring organisation having an agreed set of logical security services – or at least an understanding of the services that they want to buy at an adequately granular level. There’s also a need for increased flexibility and the ability to understand where an organisation can compromise, including on the standard security requirements, in order to obtain the wider benefits offered by cloud adoption.
The next security mantra I want to challenge is that “cloud is insecure, by default.” The idea that cloud is less secure than an existing data centre, infrastructure or application seems to be based on the flawed assumption that we always do everything much better ourselves. Unfortunately the statistics do not tend to back up this confidence. The PwC Information Security Breaches Survey 2013, conducted on behalf of the Department for Business Innovation & Skills, last year found that around 80% of respondents stated that they used cloud services, but only 4% reported a breach in their cloud services. Compare this with 36% who reported a breach due to human error, and a further 10% by deliberately malicious activities by their users. You get these pesky user creatures both on-premise and in the cloud by the way. All is not rosy in the on-premises garden; consumers need to be honest about current state prior to disparaging cloud-based equivalents.
The next guidance I want to challenge is along the lines of “identify your security requirements and ensure you negotiate them into the terms and conditions of the contracts with your service providers”. This really does miss the point. Most of the well-known public cloud providers do not negotiate specific security terms and conditions with individual clients – it’s an off the shelf service. There may be exceptions, but, in general, the providers offer a shared service with commoditised levels of security described in an off-the-shelf set of T&Cs and you can take it or leave it. Alternatively, you can implement your own private cloud to meet your specific requirements but then you bear the cost of these requirements and you lose some of the scalability benefits offered by the public cloud model. There is no illusion of infinite resource with a private cloud.
Of course, cloud is not the only disruptive wind of change blowing through IT departments. Agile development methodologies such as Scrum are currently fashionable, driven by the perceived increase in speed to operation and decreased cost of development. One of the principles of the ‘Agile Manifesto’ is that the best architectures emerge from self-organising teams. So I often hear – “surely a combination of cloud and Agile means that we can get rid of those expensive architects?”
The problem with this belief is that it confuses the scopes of the various roles and activities. Sure, the development team is probably best placed to decide how the application that they are coding should be architected. However, the boundaries and scope of each development need to be well understood so as to take account of existing constraints or requirements across the wider organisation. In addition, Product Owners are not omniscient; it’s often useful for them to have architects around for wider advice and guidance on cross-enterprise dependencies, requirements and constraints.
In summary, there are still a lot of misconceptions about “the cloud”. It means different things to different people, particularly when those people range from developers, architects, operations, line of business personnel and procurement. A lot of the existing guidance about securing the cloud is naïve, or simply out of date, and much of the early guidance written on the subject of cloud computing was written by those who have never had to deliver ICT in an enterprise context.
As with many security issues, securing cloud services is really a question of education, experience, awareness and communication. Security architecture is my preferred mechanism for establishing a common understanding across the wider enterprise and then tracing that understanding through to technical solutions – be those on-premises or on-cloud. You can adopt cloud services in a risk-managed manner. Does that make cloud secure? No, it just means that you operate within a well-defined risk tolerance. Much like we’re used to doing on-premises… aren’t we?
