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.

Public cloud vendors provide native network security controls which work at a basic network level; in order to gain any application and user awareness, or do any network-based threat prevention, you’ll need to introduce a next-generation firewall capability
In a traditional data centre, you would purchase a pair of firewalls (for resiliency, fault tolerance, maintenance) and size them for the peak expected load over the next 5 years or so; in the public cloud you can start with a single firewall, but ultimately build it into a set which auto-scales in order to manage peaks and troughs in demand - think scale out, not scale up
Where your traditional data centre had very few Internet ingress/egress points and perimeters, your public cloud footprint might be better served if each application or service stack had its own Internet ingress/egress point with its own auto-scaling next-generation firewall set; a large set of micro-perimeters managed from a single management console may be more suitable to public cloud for scalability and resiliency
Micro-perimeters for each application also means the security capability is portable enough to move with the application, rather then relying on a single central or shared security capability in the cloud environment; this also redcues the blast radius of faults, and reduces the scope for change control
Considering the maintenance scenario where in a traditional data centre you may have had two firewalls in a pair, with live traffic on one firewall while the other is taken down for maintenance or upgrade; more appropriate thinking in public cloud is to treat infrastructure as cattle not pets, so simply spin up a new firewall with the upgraded configuration and turn off the old one, no capex lost
Auto-scaling and treating instances as cattle not pets is facilitated by load balancing within the public cloud infrastructure; cloud-native thinking includes expecting failures and building infrastructure which is resilient and spans across availability zones, fault domains, update domains, and any other constructs your public cloud provider uses to create resiliency and scale

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