In November of 2021, a team of security researchers at Alibaba announced a massive discovery. Log4J, one of the most popular libraries in the 2nd most popular programming language, had an extremely simple Remote Code Execution vulnerability. They nicknamed it “Log4Shell.” This, like several Apache Struts vulnerabilities before it, was a 5-alarm fire for many security teams.   

 

Before enterprise applications migrated to the cloud, the response to this would have been relatively straightforward: check your firewall vendor’s threat blog for instructions, make sure your signatures are updated, apply any additional recommended controls, and breathe a little bit easier because you are generally protected. After that, proceed with patching the affected applications. The patching process is challenging and requires coordination between security teams, application teams, and often includes 3rd party vendors and software. Great network security is a critical control that buys time to complete the necessary hygiene work. 

 

However, the landscape has changed significantly over the past five years due to the increasing migration of applications to the cloud. With that migration, one very important part of enterprise security was abandoned – the perimeter firewall. According to LookingGlass, a security research firm, within days over 20,000 internet accessible systems were discovered to be vulnerable AND exploitable. Many of the apps in the cloud are now business critical, have sensitive data, and can often be used as pivot points for access to the corporate network. 

 

Throwing Fuel on the Fire(wall) 

 

 How enterprises landed on a “look the other way” strategy for cloud network security is an interesting story.

 

Cloud providers have done an incredible job of building infrastructure that enables developers to rapidly innovate. I would argue that the biggest benefit of cloud is speed. Unfortunately, security has a bad history of slowing things down. Adding security often adds complexity to networking, and on top of that, networking is not a typical strength for application teams. Standard practices to strike a balance include using native security group constructs – basic, IP-based stateful inspection. By default in most cloud providers, all outbound traffic is allowed.  This maintains the primary speed, but basic security often isn’t enough for enterprises, and exposing an application to the Internet is as easy as a couple lines of code!

 

I regularly hear a desire from customers to get better control of their security groups, but unfortunately if security teams try to lock systems down, they often run into operational or even technical scale limitations.

 

In our connected world, modern applications need to work with other applications such as partner APIs, code repositories, PaaS offerings, and performance monitoring solutions. Some cloud providers allow Internet access without any configuration, and some require NAT gateways, but in both cases, the default connectivity mechanisms lack visibility and control and may come with significant added cost.

 

Cloud firewall offerings, which are more capable of securing the perimeter, can be expensive and require complex networking changes to add to an environment. Best practice architectures are similar to the legacy firewall vendors, which incentivize centralized instead of distributed deployments. Ultimately, the mitigation for Log4J is simple (blocking outbound LDAP connections or restricting communications to approved domains – it doesn’t even require advanced IPS), yet security teams were left scrambling because those controls are typically absent.

 

A Brief Overview of Cloud Security Approaches 

 

To mitigate this problem, four solutions arose and fueled a massive “Cloud Security” startup boom: 

 

1. Move Security to the Endpoint: Endpoint security products have become significantly more advanced and were one of the best security controls on-prem. Unfortunately, an endpoint can’t be trusted after it has been compromised and thus it’s an incomplete solution by itself. In addition, as cloud matures, the adoption of containers, PaaS, and serverless workloads mean that agents cover a smaller percentage of the application environment. The crown jewel applications like databases and Active Directory are often the first applications to be migrated to PaaS, and this lack of coverage creates significant exposure. 

 

2. Shift Left: Try to get ahead of vulnerabilities by integrating vulnerability scanning into code pipelines. The big problem is that this is only applicable when an enterprise owns their code – which might be a small subset of the application footprint. 

 

3. Cloud Security Posture Management (CSPM): If you can’t control the perimeter, you need to at least understand the perimeter and the risks that it exposes you to. This inevitably leads to alert fatigue as every single workload can now be considered a risk. Even as this has evolved by integrating vulnerability management and risk-based alerting, it’s still like treating the symptom and not the disease. Duct tape. 

 

4. Virtual Firewalls: Addressing the issue head-on, we could consider rebuilding the perimeter. However, “last-generation firewall” vendors (formerly known as next-gen firewall vendors) have merely ported their software to the cloud without fully grasping its dynamics. This has led to the persistence of an outdated, centralized architecture. Ironically, even the PaaS firewalls follow these architectural paradigms. The centralized architecture increases complexity with specialized load-balancers, complex routing to hairpin traffic, and a different design in each cloud.   

 

Migrating to these architectures in a brownfield can be very challenging. The Aviatrix FireNet solution has been incredibly successful at simplifying this, but it’s still limited by the firewalls themselves. Coupled with IP-centric policy models, these firewalls fail to adapt to new dynamic applications. Many of these systems have bolted-on APIs and limited support for industry-standard infrastructure as code (IaC). Application layer encryption and the challenge of scaling software decryption means many customers are only using a small percentage of the features. The result? Increasing costs, performance bottlenecks, overly permissive policies that are primarily operating at Layer 4, and the return of the 10-day firewall change request. In the end, the perimeter remains uncontrolled. 

 

What’s Next After Next-Gen Firewalls?  

 

No one would say that the best way to move an application to the cloud is to lift-and-shift it, yet that’s what the firewall vendors did to try to solve the perimeter problem. What the firewall really needs is to be refactored to take advantage of all the things that cloud is good at. It should have: 

 

• Distributed Enforcement Embedded into Natural Cloud Traffic Flow – Inspection and policy enforcement are embedded into the native cloud infrastructure and natural application communication flows, so all traffic is seen. Traffic does not have to be redirected to centralized inspection points, thereby eliminating bottlenecks and automatically scaling with application environments. 

 

• Centralized Abstracted Policy Creation – Cloud aware policy creation uses dynamic cloud native application workload identity – cloud-native tags and attributes – instead of (or in addition to) static IP addresses, abstracting how and where policies are enforced. Next, a single, programmable interface should push anywhere across any multicloud infrastructure, based on dynamic knowledge of tags and attributes. When this cloud-native programmable interface is combined with distributed inspection and enforcement, the system will appear and function as a single large firewall. 

 

• Cloud Operational Model – A distributed cloud firewall must be enterprise owned and operated, delivering full visibility and control, plus elastic auto-scaling to match application requirements. It is fully programmable with industry standard infrastructure as code (IaC) automation and included in DevSecOps CI/CD pipelines. It should leverage small, burstable compute instances.   

 

• Native Cloud Network and Security Orchestration Consistent Across Multicloud Environments – Distributed Cloud Firewall supports native cloud APIs for both cloud network and cloud security orchestration to abstract underlying cloud infrastructure complexities, thus creating consistent networking and security policies across cloud service providers to ensure corporate and regulatory compliance and avoid conflicts between networking and security configurations.  

 

• Advanced Security Services Consolidation – More than traditional, commoditized features (L7 decryption and inspection, full traffic visibility, and audit reporting) Distributed Cloud Firewall supports support microsegmentation, network isolation, automated threat detection and mitigation, anomaly detection, vulnerability scanning, and cloud workload risk scoring – all with the same distributed architecture and central policy creation. When the architecture is distributed, services like man-in-the-middle decryption become more achievable as the load is no longer concentrated. These capabilities maintain a separation between networking and security duties through role-based access control, all embedded into native cloud infrastructure and operations. 

 

To effectively deliver this, you can’t simply refactor firewall software, you have to embed security into the network. At Aviatrix, we have been working over the last several years to solve this problem. And now that solution is generally available. 

 

The Aviatrix Distributed Cloud Firewall  

 

The Aviatrix Distributed Cloud Firewall is a converged networking and network security product that brings cost-effective, high-performance, distributed security to existing application environments. It is optimized for application environments and works across all major cloud providers. 

 

The Aviatrix Distributed Cloud Firewall leverages many of the advancements pioneered with software-defined networking. A centralized control plane is tied tightly into the cloud APIs and manages a fleet of software-defined gateways as if they were a single virtual firewall. The gateways are managed like PaaS, with autoscaling and hitless software upgrades. They are optimized for cloud – deployed on small, burstable compute instances. Importantly, the security is deployed in the natural flow of traffic of your cloud environment,  and doesn’t require sending traffic out to a 3rd party (which can add latency, reduce performance, and increase data transfer costs). 

 

Obviously, advanced network security is table stakes. With ThreatIQ, Aviatrix has provided reputation-based blocking and geoblocking for over a year. With software release 7.1 last week, the Aviatrix Distributed Cloud Firewall now supports advanced URL filtering, man-in-the-middle decryption, and the Suricata Intrusion Detection engine. The distributed architecture makes decryption more achievable as the compute load isn’t centralized. 

 

The security world is moving away from IP address-based policy and towards identity-based policies, and that is as important in public cloud as it is for users. Unlike users, however, workloads aren’t members of an Active Directory group. Their identity isn’t “HR” or “Finance”. Instead, they’re defined by the applications they support, the roles played, the compliance requirements they’re subject to, etc. In the cloud, we can use tags as a form of identity. The Aviatrix Distributed Cloud Firewall leverages a concept called SmartGroups, which make policy for workloads and applications dynamic. Applications can scale and automatically inherit the appropriate permissions without having to make any configuration changes to the firewall policy. When defining this dynamic policy, the administrator does not have to decide where the policy is enforced. The controller understands the context of the network and automatically pushes to the correct gateways. The irony is that when security is embedded into the network, security teams can think less about the network. 

 

Beginning Your Distributed Cloud Firewall Journey 

 

The easiest way to get started with the Distributed Cloud Firewall is to solve one of the most common security gaps – egress control. Aviatrix gateways can be deployed as a one-for-one replacement of cloud native NAT gateways – eliminating cost and enhancing security posture. The Aviatrix controller can manage the routing tables in the cloud to ensure compliance and automate failover, no complex load-balancers required. A distributed architecture minimizes the costs of data transfers while maintaining macro-segmentation VPC boundaries and allowing application teams to maintain autonomy. The Aviatrix Distributed Cloud Firewall comes with a learning mode to help detect which domains are in use, and quickly achieve a zero-trust posture for outbound Internet access. 

 

After securing the Internet, the Aviatrix Distributed Cloud Firewall can expand to support East-West control, both between VPC/VNets and within a VPC/VNet.  By attaching the existing egress security gateways to an Aviatrix Transit Gateway, the Distributed Cloud Firewall begins to control traffic between private networks. This has the side-benefit of eliminating costs associated with cloud-native transit solutions.  

 

Lastly, by enabling “microsegmentation,” the Aviatrix controller can orchestrate cloud-native controls such as Security Groups (AWS) and Network Security Groups (Azure) to create a single network security policy that enforces policy across multiple different controls and cloud service providers (CSPs). 

 

I am incredibly excited to be leading this project at Aviatrix as we help security teams regain control of the network perimeter with a Distributed Cloud Firewall. And when the next Log4Shell comes, this time you will have the kill switch. 

 

Still looking for more? Listen to our Tech Talk focused on the benefits of the Distributed Cloud Firewall.