Cloud configuration

It may not be glamorous, but Davey Winder explains how cloud settings may be all that stands between you and a data disaster

This sounds like a boring topic. Do we really need to talk about it?

Cloud configuration does indeed sound boring, which is probably why it doesn’t get a lot of attention. Yet that’s exactly why we need to talk about it: recent research suggests that configuration errors have contributed to more than 200 data breaches in the past few years, exposing 30 billion items of private information. Indeed, a shocking 91% of deployments analysed by cloud specialist Accurics were compromised by at least one major misconfiguration exposure.

Wait, what exactly do you mean by a misconfiguration exposure?

Simply put, we’re talking about real or potential data leaks that are made possible by inappropriate security settings or practices. Obvious examples might include allowing open access to a sensitive database, using hard-coded or default passwords, leaving administrative back doors open and failing to use encryption.

Isn’t configuration the responsibility of the service provider?

Only to a extent. Your cloud provider may well be responsible for securing and maintaining the infrastructure – but when it comes to setting the right access controls for your internal resources, that’s on you. In the event of a data leak, claiming “I thought someone else would deal with that” won’t get you off the GDPR hook. And it goes without saying that if you’re hit by a destructive attack – such as the recent “Meow” bot exploits, which have trashed thousands of databases around the world by overwriting exposed indexes with the word “meow” – pointing fingers won’t undo the damage. You need to take responsibility for devising and correctly implementing suitable security policies before a breach happens.

That doesn’t sound too difficult, so why is misconfiguration so common?

It’s easier than you might think to get caught out. Default settings can trip you up, and one common scenario involves database security being temporarily disabled or downgraded as part of a maintenance task. Even if this state of affairs is short-lived, it can be quickly spotted and exploited by automated hacking tools that are designed to scan for such things. In fact, you might characterise this sort of attack as data mining rather than hacking, as the data is just sitting there waiting to be extracted.

What can I do to avoid becoming a victim of cloud misconfiguration?

It’s a good idea to start with the basics and, in this case, that means your base configuration setti ngs. Security policy updates should always be propagated into your base settings to ensure you’re learning from past mistakes, rather than repeating them. You should also regularly review the configurations of your cloud servers and applications, and ensure that they remain secure. Configuration compliance must be part of policy compliance before provisioning, before deployment.

Anything else?

As with most security issues, the solution is multilayered. Apply the principle of least privilege to identity and access management, and carry out regular audits to ensure not only that your cloud resources are secure, but that they remain so throughout their lifecycle. Automation can be your friend here too: you can even use the same tools that attackers do to find accessible databases, such as the Shodan discovery engine. Finally, bear in mind that misconfiguration cases most commonly boil down to human error – so training and awareness have a role to play.

“In the event of a data leak, claiming ‘I thought someone else would deal with that’ won’t get you off the GDPR hook”