When transferring a workload to a public cloud or deploying it there, IT and network security face numerous challenges of Cloud security. Each side must comprehend how the current difficulties came about in order to solve them in today’s complex environments. As someone who has lived on both sides, I share stories and advice for cloud security professionals today from both sides.

The IT and network security DMZ has always been difficult to reconcile. It has always been difficult to strike a balance between budget, cost, app performance, app time-to-market, system stability, and other factors. Not to mention the ever-evolving threat landscape, in which criminal activity pays off and the bad guys acquire all the latest weapons first. In addition, for many, a significant setback can serve as a “resume generating event.”

However, despite all of these obstacles, the industry had stabilized into a mature and effective space by the beginning of the 2010s thanks to factors like virtualization, vendor maturity, Moore’s law, and enterprise-grade cryptography. The DMZ was the king back then. Access to the internet was simple to control, critical applications and infrastructure were tightly secured, uniform policy had a solid foundation, and centralized visibility was almost always guaranteed.

The industry flourished under the DMZ’s iron shield, and people finally trusted the internet as the best way to conduct business. E-commerce and mobile commerce also exploded. The internet entered its golden age. While cybercrime was on the rise and hackers were present, a well-designed DMZ was able to withstand all but the most sophisticated attacks.IT security was one of the most popular careers, and the future was bright.

Another revolution was brewing, unnoticed by the euphoria and digital gold rush of the early 2000s.Soon, people in my inner IT circles started talking about how the influx of investment, talent, and technology that seemed to be everywhere was changing and growing service delivery. They referred to it as “the cloud.” On-request figure, driven by code and charge cards. storage on a day-by-day basis. services that are complete and work in your browser or on your smartphone.

I was working at F5 Networks at the time, and many people were skeptical. Not at all. At the time, Microsoft was a devoted client of mine, and their unique fleet of load balancers was utilized by a brand-new business unit called Azure. The Azure control plane kept tipping over our boxes, as I recall. Management CPU is pinned, and management interface is flapping.

We had never seen something like this; Through change control, it appeared as though they were committing self-inflicted denial of service. Microsoft was clearly on to something here. It was revolutionary to automate the entire platform as well as the network. Additionally, it was unfortunate that they were tipping our boxes. Very poor. It indicated that we were not prepared for this kind of thing.

I recall a team member saying, “No, man, look how many calls are coming in, this is insane. “There is no need to implement so many changes so quickly. Are they not capable of managing a data center?

The thing was there. The jarring paradigm shift that occurred between the new revolution of infrastructure as code, which would eventually shape the entire industry, and a decade of networking best practices.

Is this the first public disagreement regarding infra-as-code versus traditional networking?Although unlikely, it was definitely a sign of a much bigger problem that many people would face when they moved to the cloud years later.

In 2010, the majority of industry professionals were unable to comprehend why anyone would want to switch networks so frequently. At the time, networks were meant to last forever and never change.

Additionally, your network security model was dependent on this solid foundation. The DMZ would be constantly in danger if the structure of the network were altered on a daily or even hourly basis. Twice a year, in the middle of the night, everyone sweating while dressed in surgical gear, the production firewall was changed. Changing the firewall consistently? It seemed impossible.

The central idea of our first lesson on network security is as follows: In the cloud, the DMZ’s outdated model is a failure.

Networks in the cloud are always evolving. Occasionally, daily Traditional cloud management of your virtual firewall results in a high-touch environment, the possibility of configuration errors, and legacy rule bloat.

ACLs for the firewall network do not always correspond to actual or active actors; compartments, PaaS, and SaaS jobs are named-based. Cloud apps and workloads can be categorized and controlled with the help of cloud-native tags.

When at all possible, cloud-native security stacks or, even better, an effective orchestrator for them are preferable. This is because they are distributed, free, close to each VM, programmable, and agile with the right approach.

Concentrate on cloud-native stacks for traffic within a VPC or VNet. Avoid putting traffic from within a VPC or VNet into a virtual firewall. Keep in mind that VPCs and VNets are logical structures. Distance physical (read: availability zones and proximity placement groups, not membership in a VPC or VNet, influence latency between VMs. Use only interspoke East-West and/or North-South traffic through your virtual firewall. If designed correctly, the VPC/VNet spoke, where the majority of network changes occur, can shield your firewall from constant configuration changes.

Build only a few VPC/VNet spokes. Make an effort to make them big enough to handle a whole LOB or application. Between application tiers, make use of subnets and security groups at the subnet level. Break an application tier off to its own VPC/VNet only if you need to inspect firewalls between the tiers, which is against cloud practice.

Avoid impulsively forcing your default internet route back to your on-premises DMZ. This adds latency, can make VM-to-PaaS/SaaS architectures more difficult, and can overflow private pipes. The world’s largest private network is now cloud networks. Apply them.

In order to construct a virtual DMZ, flawless route control is required. In the cloud, routes are your VLANs. Look for cloud-based platforms that automate routing to your firewalls and offer comprehensive route control. If you have to make static route changes each time a VPC or VNet is created, you will never be able to keep up with the cloud or the industry.
Up until your first IP overlap with a B2B partner, your first M&A event, or your first multi-cloud deployment, static route summarization to the virtual DMZ will work well. Look for cloud-based platforms that scale Enterprise NAT support. Your cloud security design may suffer from IP overlap.

Best-practice design in the cloud is not well-prepared for the majority of IT security professionals. They’re doing what works best for them and has worked well for years: They are making things up. This results in design-driven hit-or-miss situations that may come back to haunt them.

There is precious little talent available in cloud network design, and even the existing courses and certifications for cloud networking are time-consuming, expensive, and do not cover all cases. The typical experience will be a “trial by fire” situation until skill gaps are filled.

At Microsoft Azure in the late 2010s, I witnessed this firsthand. On a large global client’s virtual firewalls, there were always rolling outages. Their firewall CPUs were fine, hovering around 40%.However, the virtual NICs’ flow tables were full and dropping packets, leaving the customer confused and frustrated.

It turned out that the customer was unaware that all virtual NICs in Azure run the same code, which meant that Azure flow tables—the NIC’s connection tracking mechanism—share the same flow limits. The behavior of flow tables is uniform worldwide.

Because the control plane cannot tolerate stack variations at hyperscale, it must be. All of the native security, routing, and connection processing is carried out by cloud NICs, which are intelligent. However, the hypervisor beneath each NIC has limitations.

What then do we do? The customer inquired, We tried creating larger virtual machines, but it didn’t work!

The issue lay therein. Building more VMs rather than larger ones was the solution. Dainty and wide. Flows must be distributed across numerous virtual instances of a medium size. The issue here is that their vendor provides support for VM scale sets. Each firewall had to be built individually.

This is a time-consuming and unsustainable model. The severe incongruity that one of the bosses of modern computerization doesn’t robotize their cloud security struck me first as entertaining, then as a significant disclosure that has stayed with me until the end of time.

This is how cloud scales, but that customer had a hard time accepting it. Rarely do the right thing and the easy thing coexist. The fact that cloud was supposed to be simple was frustrating for that customer and many others.

Securing the cloud: beyond the design of older firewalls, and the underlying principle of our second and third IT network security lessons is as follows: In the cloud, the legacy firewall design model is a failure, and few people know how to do it right.

Your cloud-based virtual firewalls are completely unaware of this. They have the impression that they are linked to wires. Not at all. They are associated with a SDN stack which may be nearly just about as brilliant as your firewall.
The tier of your firewall needs to be coordinated. Make sure you build a pipeline around a platform that lets you orchestrate firewalls. A few stages will do both for you in the engine.

Accept being thin and wide. Prepare to scale horizontally and resist the temptation to scale vertically unless you are attempting to solve for fat flows, which are massive data streams that are hostile to cloud VMs.

You may hear from some vendors that the cloud necessitates the use of multiple firewalls for various functions. You do not, technically speaking:

As long as they are of the same type, there is no difference in performance between one set of four virtual machines and two sets of two virtual machines. With programmatic routing control in the cloud, your firewall can be both North/South and East/West simultaneously. Keep in mind the preceding points. Wide and thin. Vertical scale. Cores are cores. Now everything is software.

Be sure to have a good plan in place for policy management and Day 2 operations if you decide to create multiple firewall instances to address various use cases or locations.

In the cloud, you’ll be creating a lot of network data; will your firewall see everything? Should it see everything? This is difficult. So that your firewall does not become a data hog and a single point of failure for your network’s eyes and ears, look for platforms that collect data both within and across the entire network.

Consider the possibility that the network itself, with its distributed, programmatic, low-cost, and ever-expanding capabilities, will eventually become the best cloud firewall. However, a few significant obstacles remain:

App-layer security is not very secure on cloud networks.
Orchestrating cloud networks on a medium to large scale is difficult.
The major vendors offer vastly different cloud networks and security groups.
Because they are part of a large multi-tenant platform, cloud networks have some limitations.

To get the best of both worlds, look for solutions that assist in overcoming these shortcomings by incorporating native SDN security stacks. App-layer awareness, effective multicloud orchestration, and a straightforward policy model that abstracts CSP differences should be included in these solutions.

A story can gain new meaning when placed in its historical context. I hope these backstories can set the stage for your organization and offer a fresh point of view to get you started on your cloud security journey. Good luck and have fun hunting!