The “cloud” term remains badly overloaded.   Facebook is cloud.  Amazon Web Services is cloud. is cloud.  Your virtualised data centre is now a private cloud.  There is no common understanding that not all cloud services 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.   It really is a little more nuanced than that…  and failure to recognise those nuances can leave you badly exposed.

So, how do we establish the necessary common understanding? The most widely accepted definition of cloud computing is that put forward by the National Institute of Standards and Technology in the US (NIST).   The NIST definition of cloud includes a series of essential characteristics, a set of service models and a set of deployment models.  The service models are the familiar terms of Software as a Service, Platform as a Service and Infrastructure as a Service.   Lots of people jumped on the “as a Service” bandwagon so that you can also get Security as a Service, Messaging as a Service, Business Process as a Service etc etc.  Cloud washing isn’t actually a part of the NIST definition but you may quite often see some random term followed by “as a Service”.  

The deployment models refer to how the cloud is made available to its consumers – available to all (public), available to a single organisation (private), available to a group of like-minded organisations (community) or some combination of these three approaches (hybrid).

Why does this matter?  Well, the problem with seeing the cloud as “just a set of computers on the Internet” is that each combination of the different service and deployment models actually gives you a different set of security questions to answer.   For example, if you run on a Software as a Service cloud, then you don’t have to worry about patching your operating systems or applications any more – it’s all part of the service.  Happy days! 

However, if you’re running on an infrastructure as a service cloud, you, as the consumer, must still bear the pain of patching your operating systems and applications.  Even on a Platform as a Service cloud, you’ll still have to worry about maintaining the applications that you have developed yourselves.   In fact, with Infrastructure as a Service, most of the operational security responsibilities remain very much with the consumer; you get the freedom to put more or less what you like on there, but with that freedom comes responsibility.      This also means that you have to be extremely careful when choosing your magic technology solutions to secure your cloud (spot the future blog post) – you need to consider from the outset whether those tools are applicable and appropriate to your particular combination of service and deployment model.

So, to the point: there is no single “cloud” for you to secure.   There are lots of individual cloud services, each with their own security characteristics and it’s vital to your security that you understand where the primary delivery responsibility sits for each aspect of security – with you, or with your provider.   Trust me, you do not want to end up in a situation where you end up with unpatched, unmanaged server images exposed to the Internet just because you failed to understand where the “Service” in IaaS ends and your responsibilities begin.