Is the cloud lulling us into security complacency?

The recent CapitalOne breach has certainly made lots of headlines in less than a day since the story broke out. And sadly, it has already thrust the $700M settlement that was reached from the largest ever data breach – the Equifax one – onto the sidelines just days after the news of that settlement broke out.

But going back to CapitalOne, there are lots of lessons to be learned there certainly. I want to focus on where CapitalOne’s data centers were and what that means for the rest of the planet from a security perspective. CapitalOne has been one of the most vocal AWS customers. They have appeared at numerous AWS events and touted how they have completely shuttered all their data centers and run exclusively on Amazon. And to be fair, they have also shared their best practices and use of AWS services.

And then this happens.

So, the question is: if one of the savviest AWS customers can suffer such a large and embarrassing data breach, then every AWS (and non-AWS) customer should be concerned…and taking proactive steps to address what cloud security means and what it does not mean.

Put another way, is reliance on the cloud lulling us into security complacency?

1. From rack and stack to spin up on a whim

In the days when every mid to large enterprise had one or more dedicated data centers and setting up a new server or rack involved wiring, power, cooling as well as extensive network and security reconfigurations. And it could literally take weeks. And that time would allow to ask the basic and not-so-basic security questions. Today, compute, storage, serverless…everything is on-demand. And cloud bursting and data hoarding is inexpensive and quick. Everything has been accelerated many times over. So, unless security is in the process blueprint or the cloud provider offers it as a default setting (e.g. AWS by default now encrypts its S3 buckets after many an incident of unsecured data stores was reported) it can easily get lost in the noise.

2. The shared responsibility model is pretty descriptive except that it can relegate to distant memory

When AWS came up with the Shared Responsibility Model, it got great kudos for explaining clearly what they are responsible for – “security of the cloud” and what the customer is responsible for “security in the cloud.” But the pace at which AWS releases features, it is so easy to get caught up with the catchy names – Greengrass, Lambda, Control Tower – and delve into them without remembering the “of” the cloud and “in” the cloud responsibility distinction. And that oversight can prove to be very costly.

3. No two clouds are the same, and doing multi-cloud requires extra effort and care

While multi-cloud has a bevy of advantages – better pricing, redundancy, bleeding edge feature rollout etc., it also puts a burden on the teams using multi-cloud. The investment to keep up with the latest and greatest and then know how to use it. But from a security perspective the challenge is far greater. Why? Because while inherently the shared responsibility model should apply to all clouds – AWS, Azure, Google, etc. – the implementation and the risk attribution could be very different.

For instance, can an infrastructure administrator gone rogue have the ability to steal a Virtual Machine. Or if a data store is encrypted, does the end customer alone have the master key or does the cloud provider hold the key as well? And the answers could and usually are very different from cloud to cloud. And so, the shared responsibility model is also cloud specific.

These are three challenges as it relates to cloud security that makes this journey not such an obvious one when seen from the lens of security and privacy. So, what does a business do then? Slow down or stop cloud adoption. The answer to that is obvious. No, that ship has sailed.

Instead, ask yourself these questions periodically:

1. Have I identified recently all the sanctioned and unsanctioned cloud workloads across all major public clouds for my enterprise (there are tools that do this kind of discovery)?
2. Remind yourself and your team of the “shared responsibility model” and for all the cloud workloads ask what “in the cloud” security means. The answer could be very different for a cloud connected IoT sensor to a serverless compute engine.
3. And finally, develop experts within your organization or engage a trusted third-party to educate constantly on the multi-cloud differences for the features you are working with from a security and privacy angle. Costly and Time consuming? Yes. Critical? Absolutely.

Over the course of the coming weeks and months, we will learn more about the CapitalOne breach. But to borrow a marketing tagline from them ask yourself this question constantly “What’s in your cloud”?