Lift & Shift: cloud security strategy

Intro #

When companies move their infrastructures into the cloud, provisioning resources and configuring them to emulate their initial infrastructure — a practice called “lift and shift” — or migrate the existing solutions from one platform to another, something inevitably migrates together with all the code and assets: their security assumptions .

The security assumptions affect the major security bottleneck — security team’s time and priorities. And the on-premises threat model and security priorities are very different from cloud-based.

What exactly do you shift with your “lift and shift”? #

The cloud is already someone else’s computer so there’s a set of risks you’re facing regardless of your choice of architecture, be it cloud-native or “lift and shift”. But when you build cloud-native designs, they offer plenty of security benefits, unless your threat model is protecting state secrets or other high-value / high-risk data.

The benefit analysis of lift & shift usually focuses on cost changes, change of CAPEX vs OPEX proportion, and lowered operational risks. Experienced people also look into the staffing / hiring risks because Ops engineers who can re-engineer apps to cloud-native and maintain them are expensive and hard to find, while lift and shift approach implies retaining most of the existing employees. Security gets either overlooked or approached with “not invented here” mentality. But let’s attempt — for a second — to consider the security implications of lift and shift before actually doing it.

Duplicating the cloud provider’s work #

When you lift and shift, you don’t trust the cloud provider with doing everything (and even less so with doing everything correctly): monitoring, orchestration of security events, patching, keeping the components up-to-date, managing administrative and maintenance access, meaning you keep doing it yourself . You push your assets to cloud compute/storage and treat it as your own hardware in terms of system’s design.

And here is something for you to consider:

• How likely is it that your engineers will misconfigure your typical service versus the odds of vendor’s engineers bulk-misconfiguring it for everyone?

• Are you sure that your limited security budget will be best spent on maintaining replicas of cloud provider’s services and patching them, spreading yourself thin between L2-L7 networking when most of it is cloud vendor’s responsibility?

Attack vectors are the same #

There are 4 large attack vector groups specific for a cloud provider:

• Cloud provider insiders;

• Adversaries targeting cloud providers;

• Your credentials for management of your cloud resources;

• Adversaries targeting your cloud deployment specifically.

The first two are a rare event, least likely to do any real damage (but it doesn’t mean that’s totally impossible either — for instance, take CapitalOne, which was hacked by an ex-AWS employee ). The third one basically equates lift and shift to cloud-native development. It’s only the fourth vector that draws a real distinction between lift and shift and cloud-native. In our experience, cloud-native deployments have a better chance to withstand an attack.

There is also one thing missing: a targeted attack on your cloud provider to compromise you, executed by an advanced adversary. If you are the target of such risks and you are aware of that, reading this article will not be enough — you’ve got a lot of work to do, especially if you’ve done nothing about it yet.

Supply chain risks #

When you lift and shift, you retain the illusion of managing at least a part of the supply chain. In reality, your cloud vendor’s supply chain necessary to run a custom auto-balancing PostgreSQL service can be extremely tricky and might use hundreds of open-source components you’re unaware of.

But this is only valid as an argument in a Twitter discussion. For most people, it’s far from being relevant.

What really happens is:

• You’re losing a bit of security posture by trusting 3rd party supply chain only in one case — if it was 100% clean to begin with. Did you vet each line of code that runs in your production? Did you at least have the processes to vet, monitor, replace components, justify their business needs before getting your code into a potentially poisonous component? Then yes, you’re losing something and it’s a real point to reflect on.

• When you think you’re only using the cloud for compute power, there are still numerous open-source and closed-sourced components involved you’ve no idea about. You also have no way of knowing, how well the cloud provider invested the time to secure them.

In our experience, most organisations lose nothing in terms of supply chain control.

The real question is — should you trust your cloud provider that much?

It always depends on the balance between the risks and the available resources, and the ability to make the correct decision. As famous asymmetry idea suggests, defenders need to get many things right to build secure and sound defences, while the attackers only need to get just a few things right to reach their goals.

Bearing this in mind, consider the probability that you’ve got most of the things under your control right and you can get most of the cloud platform-related elements to work better than cloud provider’s engineers. If you think that’s the case, okay, you can continue doing their jobs.

Refocusing is key #

Sometimes, cloud migration is only about the cost and predictability of OPEX and the way cloud providers price their higher-order services makes lift and shift a viable option. But quite often, when your security budget is reasonable as well as your cloud infra one, you might get better ROI by not repeating other people’s work and instead focusing on:

• Properly securing your unique applications and doing all the things you’ve had an excuse not to do for ages because of firewalls, patching, versions, accesses, key distribution, etc. For instance, encrypting data during the whole dataflow.

• Investing into IaaC, deterministic builds: it’s as much a security concern as it is helpful to get modern cloud operations right.

• Maintaining proper risk/threat model instead of chasing CVEs.

• … and, most importantly, cooperating with developers and regular Ops engineers to decrease the complexity and general attack surface of your app.

Because we have a strong conviction that this is what is going to matter most during the next breach.