Why cloud first is not a security problem

A common way of looking at the 'traditional vs cloud' question is: ‘pets versus cattle’.

Traditional computer systems have servers that are like individuals: they're all different, they're kept as long as possible, and they require a lot of maintenance, much like a pet. They may even have a name! With modern computer systems such as clouds, servers are just commodities, resources to be added or removed as required. This makes them more like cattle.

This is a good analogy, but I think it can be a little misleading, as people don’t keep pets and cattle for the same reason.

I prefer ‘private cars versus hire cars’. Here's why:

• We use both types of car for broadly similar reasons: going from A to B.
• We personalise our own cars. We sometimes customise them too. We may name them. We change them reluctantly. We pay a high upfront cost, and then pay for regular maintenance.
• We choose hire cars based on broad categories (for example, how much space they provide, and whether they're manual or automatic). The car that we’re given is a commodity, from a pool of similar vehicles, and the hire car company maintains it for us. If our requirements change, we get a new one from the car hire company. We pay while we have access to the hire car, but not when we don’t need it and it’s been returned to the company.
• With both private and hire cars, we’re responsible for parking safely and locking the doors.

No analogy is perfect, but I think this drives home (sorry!) the key to thinking about the cloud: it is rentable computing power.

Being rentable, the cloud comes with restrictions, but it allows easy scaling to suit demand, and much of the computer support is outsourced to the cloud provider. And, as with the need to lock a hire car and look after the keys, we need to secure our code and data in the cloud. The commodity computing aspect can be turned into an advantage with the right security model.

With a little background, we can now see that there's a problem with simply asking, 'Is the cloud secure?' The question is misleading because, without context, it can't be answered.

We tend to talk about computers being ‘secure’ or ‘insecure’, but those terms are meaningless by themselves. A computer is secure or insecure against specific attacks by specific attackers.

It is always possible to imagine a ‘what if?’ scenario that leads to a successful attack, and this is easier if you don’t have control of the computer in question. In that case, your imagination can run wild.

There’s a temptation to try and control as much of your IT as possible, in the belief that the associated vulnerabilities and security are known and understood.

Making sensible security decisions about public cloud services means not succumbing to this temptation, acknowledging that having control of a computer is (sadly!) not the same as securing it, and recognising that another company may be able to help.

Giving up control feels uncomfortable, but the cloud provider is better placed to manage its own services. Letting them manage as much as possible means you can concentrate your security effort on the features they don’t offer.

You have to trust your public cloud provider. If the only thing that mattered for security was the number of people that needed to be trusted, the cloud would offer poorer security than an on-premises system. However, that ignores the security benefits brought by the cloud: patching, logging & monitoring, DDoS protection, easily duplicating systems across multiple regions, and so on.

Obsessing about one element of security to the exclusion of everything else is a bad idea that leads to security weaknesses.

To return to the analogy, do you trust the hire car company? To get the hire car, you need to pass over a lot of personal information, including driving license details. You then rely on the company to control access to its copy of the car key, and trust that the car is mechanically sound and hasn’t been stolen.

So, it is sensible to research a cloud provider’s background and security. If, after this 'due diligence', you can't trust them to handle your data, don't use them. Depending on the nature of your data and your risk appetite, this may be a reasonable decision, provided it is evidence-based and rational.

This research will also show how this cloud provider divides security responsibilities between the customer and themselves (called the 'shared responsibility model'). While they are all broadly similar — for example, access control is under the control of the customer, whereas physical security of the data centre is under the control of the cloud provider - each provider differs slightly in the details.

There is ongoing research into ways of keeping the benefits of the cloud while reducing the need to trust the provider, but this remains complicated and, currently, more likely to introduce security problems than fix them.

Previous NCSC blog-posts have dealt with how we approach getting trust in a cloud provider, and may be of help here: ‘Brightening the outlook for security in the cloud’, ‘Cloudy with a chance of transparency’, ‘NCSC IT: how the NCSC chose its cloud services.' And most recently, 'NCSC IT: There's confidence and then there's SaaS'.

When moving a system to the cloud, there are big gains to be made by redesigning it to take full advantage of the features on offer. Both managed services and serverless functions pass much of the maintenance burden, including the security burden, to the cloud provider.

Commodity servers can be patched by replacing them with a new server that's already patched. This is simpler and easier to test than trying to patch a running server. Think of the hire car analogy again: if a hire car develops a fault, we replace it rather than trying to fix it.

There's no point in pretending the nightmare scenario I mentioned earlier can never happen. One day, a public cloud provider may draw the short straw and suffer a security catastrophe. But, to put this in its correct perspective: so will companies not using the cloud, since nothing about the nightmare scenario is truly unique to the cloud.

Public cloud providers pay a lot of attention to the nightmare scenario, since it would also be a catastrophe for them. It’s one of the unusual cases where commercial interests support computer security rather than being at odds with it.

Cloud providers often have early access to vulnerability information, so they can patch a vulnerability before it’s publicly announced. They publish the details of many of their security procedures to reassure their customers. It is worthwhile reading these if you have doubts.

You would need to match the security of a cloud provider merely to keep pace with the risk. Fail to do so, and you are more likely to suffer a catastrophe than the provider.

Catastrophic-but-rare risks are best treated as disasters and incorporated into disaster recovery plans.

Instead, concentrate your security effort on making sure your data is secure. In our experience, data breaches in the cloud mostly come from the customer failing to protect their own data. Leaving your data insecure and hoping no-one will find it is like leaving the car unlocked and hoping no-one will steal it.

There are always limits on the security resources available, and these are better spent securing your data than worrying about the nightmare scenario.

Nigel C.
Platform Security Research
NCSC