Security When "Lifting and Shifting" to Public Cloud

There’s been a lot written about the “lift and shift” mentality when migrating to public cloud. It ranges from commentary that it won’t work, through to it being sub-optimal, over to it being an anti-pattern, and it being one that won’t achieve any expected cost efficiencies. Lift and shift between traditional data centre spaces has enough risk, so lift and shift into a different infrastructure paradigm like public cloud could be viewed as even riskier. There are as many opinions on this subject as there are definitions for “cloud-native” and “DevOps”, and that won’t stop a large number of organisations migrating to cloud with a lift and shift approach. Some of those will succeed in their objectives, others will not.

If you move to public cloud, does the threat to your applications, services and data rise or fall? In many cases your adversary doesn’t care where you host your organisation’s infrastructure, though it might slightly change how they enumerate and attack, and may open some extra targets for them. This means you still need all the same visibility and control you’ve become accustomed to in your traditional data centre environment; application awareness and control, user context, reduction of attack surface, preventing known and previously unknown threats, along with reporting and analytics for all of the above. What does change is how you implement this visibility and control. In the same way that lift and shift for applications and services probably means missing out on most of the benefits of moving to public cloud, lift and shift for security will also lead to a sub-optimal capability.

As with all design and architecture conversations, there’s no one-size-fits-all solution, but there are certainly some things you should be thinking about when considering your security in public cloud.

Understand that cloud provider infrastructure is never the finished product; new and improved features are being rolled out at a very fast rate, and a perceived limitation of a cloud provider’s infrastructure today may not be there tomorrow, which leads into my final thought…

The design patterns you create today are not final; building traditional data centres meant a 5+ year investment into a large amount of tin, bought for a predicted and amount demand, which may not be easily configured into a different design pattern later down the line, especially not without significant downtime. You may find you need to scale and grow, use cases may change, changes in the business’ strategy mean different requirements, or cloud providers may introduce new features. All of those scenarios could mean different design patterns, and public cloud allows you to choose a design pattern today, and change very easily to a new one tomorrow withouth losing a lot of capital expenditure. Simply spin up a new infrastructure stack in a new design pattern alongside the existing infrastructure, seamlessly switch over your load-balanced services, then burn down (turn off) the old infrastructure; you’re not tied into a decision made today for 5+ years any more

This all means your next-generation firewalls need to have features which you may not have considered when purchasing traditional data centre devices. They'll need to play nicely with the cloud provider load balancers, you’ll need them to auto-scale as demand peaks and troughs, which in turn means you need them to be spun up, deployed and configured automatically through API calls from the cloud provider triggers. To ensure consistency of security policy, you’ll need them to inherit the latest configuration from a central management console as well. Ideally, you'll also be able to deploy, configure and orchestrate them with toolsets like Terraform and Ansible.

For infrastructure and the security around it, lift and shift to public cloud may work out and be efficient for a small set of use cases. The majority of enterprises will, however, gain the benefits (agility, automation, cost efficiencies) of public cloud if they think more cloud-native when they make the move, and this means we need to think differently about how we deploy security.

--- home --- twitter --- linkedin ---