Skip to main content

The Number One Reason to Migrate Legacy Workloads to Azure

Author by Nathan Lasnoski

We know that the cloud is a foregone conclusion for new workload deployment for the majority of use cases, but I am frequently challenged about legacy workloads by curious companies. There are a multitude of reasons to migrate legacy workloads, from flexibility, to control, to infrastructure-as-code, to management modernization, but today I want to focus on what I believe is the most important reason to migrate legacy workloads to Azure, which is to implement micro-network segmentation in the datacenter. Let’s talk about why…

The reality of legacy datacenter

For the last twenty years or so we’ve been building networks largely the same way… with highly connected workstation to server environments. These environments allow workstations to talk to workstations, servers to talk to servers, and lateral movement very easy, because that is how we built the environment to function. The problem is that the legacy network environment is very susceptible to security compromise via that same lateral movement. A few times a year a company comes to me with an emergency… a workstation has been compromised, which was used to move to another workstation, where ransomware was deployed and then used to compromise a significant portion of the datacenter environment. This has happened to organizations of not just hundreds of servers, but thousands of servers. I’ve had organizations come to me with almost 99% of their datacenter compromised, even the data domain backup environment. The question is… “why does this keep happening”? Even after the event, with customers “recovered” the IT organization (if they haven’t been fired already), convey to executive leadership they’ve “fixed” it and have deployed new technology. The problem isn’t a technology issue, it’s an architectural issue and it needs to get addressed.

This is what we’re dealing with:

Why we haven’t addressed it on-premise (and won’t)

The reason we haven’t addressed it on-premise is because it is hard. Teams have difficulty reconciling the challenge with value… that is until they’ve been taken advantage of in a security incident. Implementing micro-network segmentation on-premise requires high alignment between application, network, server, storage, and identity teams. This alignment requires infrastructure knowledge, application knowledge, and political coordination. Don’t give me any interference about fancy network capabilities you’re supposedly implementing on-premise. The “upcoming plan” to implement micro-network segmentation in the legacy environment has been a pipe dream of network engineers forever, but no matter the advanced technology, the blockers have been insurmountable to achieve meaningful progress. Even if we were to assign the necessary resources to address this problem on-premise, maintaining the environment would be very difficult because of the manual nature of how we deploy on-premise infrastructure. We wouldn’t solve the legacy working boundaries and we’d instead implement a temporary solution that is not maintainable. Think of all the teams who need to work work together without proper process or tools to build and maintain this…

How to address the problem of lateral movement

To mitigate lateral movement many security professionals fall back on security tooling for detection purposes or trying to prevent devices from being compromised in the first place. This is all well and good, but it’s like designing a building where after making it through the front door (or the back door), all inside offices and your datacenter are left unlocked. A thief will take the easiest way to compromise your application and data. The front door (your application) is likely the hardest surface to find a flaw and the back door (your network) is the easiest way to get in and find the open office to execute the grab. So, what do we do? The answer is architecture.

There are two major components of implementing a micro-network segmented environment, one on the datacenter and the other at the client side:

  • Modern Desktop. The implementation of a Modern Desktop environment where devices are fully moved onto a “guest” type network by being Azure AD joined (vs. Windows Active Directory joined), Intune managed, app proxy delivered, etc. This is part of the picture and it addresses getting devices off the corp-net and segmented also from each other. This is an important part of the story because it creates barriers between the threat and the target.
  • Micro-Network Segmentation. The implementation of micro-network segmentation around every application. The goal of micro-network segmentation is to limit the movement between devices and application environments and between application environments.

Why the Cloud?

The migration of legacy workloads to the cloud brings along with it the the technology, team alignment & org, and catalyst to implement security controls. All of the reasons we didn’t execute on it on-premise are reconciled in a cloud migration because you have to do it anyway to be successful. Think about what you’re doing when you prepare to move legacy workloads to the cloud:

  • Application name
  • What the application talks to (tooling helps with this)
  • Moving to infrastructure-as-code
  • Merging team skills to create cloud engineering
  • Working with application teams closely
  • Optimizing management and monitoring
  • Segmenting applications based on cost
  • Implementing RBAC around application groups
  • NSG design for implementing controls
  • JIT for enabling RDP access only when needed
  • Understanding what data is transferred between what servers

All of these attributes facilitate the creation of a cloud environment that significantly mitigates lateral movement. It doesn’t eliminate it, but it does make it a lot harder. Here is a shot at what this looks like in an Azure environment, implemented through infrastructure-as-code, with the whole team working together.

Remember that this is difficult to implement manually. If you try to use a migration to the cloud to implement segmentation but you don’t also implement infrastructure-as-code, you’ll find it near impossible to manage. Instead, pair the deployment of segmentation with infrastructure-as-code, where all teams are collaborating on what “good” is and have a stake in it being maintained and released appropriately. This has a side affect of improving the working relationship between teams and skilling up your teams for the cloud. This is what you should be targeting:

Next Steps

So… agree with me… let’s rock and roll. Leverage the opportunity to move to the cloud as a catalyst to measurably decrease the attack surface of the environment. This is one of many attack surfaces to worry about, but it is a huge one and an opportunity that security professionals, developers, and application owners alike should not miss. I’ll make the statement that “a company should move to the cloud just to do this”… and I stand by it. Yes it isn’t everything, but it’s huge. Let’s get it done.

Want to argue with me? Please do… let’s chat.

Nathan Lasnoski


Nathan Lasnoski

Chief Technology Officer