[BreachExchange] Is the cloud lulling us into security complacency?

[Destry Winant]

https://www.csoonline.com/article/3412006/is-the-cloud-lulling-us-into-security-complacency.html

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”?