A leopard can’t change its spots: Why physical security appliances can’t move to the cloud

Palo Alto’s recent introduction of its firewall as a service (FWaaS), GlobalProtect Cloud Service, is the latest example of how firewall appliance vendors are moving to the cloud. Appliances are not aligned with the new shape of business that involves private and public cloud platforms and a mobile workforce needing fast access to business data from anywhere at anytime.

By running security in the cloud, firewall as a service providers can better accommodate these business changes, in theory. Practically, neither the enterprise firewall appliances being adapted for FWaaS nor existing multi-tenant virtual firewall platforms adequately meet the needs of a scalable, reliable FWaaS.  

Enterprise firewall appliances, even ones built for large enterprises, were never designed to serve multiple customers. As a result, scaling, resource segmentation and resource allocation become problematic. Even the multi-tenant firewall platforms currently marketed to providers are limited when it comes to capacity planning, scaling, and upfront capital expenses.

By better understanding the architectural differences between firewall appliances and FWaaS cloud services, IT professionals will be better suited to select the approach that meets their needs today and tomorrow.

The Cloud Is Different

Expecting enterprise firewall appliances to perform like cloud-scale software is like expecting a convertible to have the durability of a tank. Enterprise firewall appliances, like any product, are purpose-built to meet specific requirements. FWaaS, and the cloud in general, have vastly different requirements.

As with any cloud service, a FWaaS is used by multiple organizations, which makes multi-tenancy critical. Downtime becomes particularly pertinent with FWaaS as service outages impact provider revenue. The FWaaS must also be distributed by design so providers can easily expanding into new geographies.

The Multi-tenancy Impact

The obvious effect of supporting multiple customers is the need for greater scaling whether in terms of traffic loads or the sheer number of connections. Cloud platforms can scale to support globally distributed customers each with multi-gigabits of traffic, countless number of connections, and distinct rule sets. Enterprise firewalls were not designed to scale in that way. Scaling, though, is only part of the problem.

Since enterprise firewalls are not designed for multi-tenancy, they do not provide resource segmentation between customers. Enterprise firewalls share all networks, objects, and firewall inspection rules between all functions in the system, and all functions use them for enforcement and inspection. One customer over-utilizing the appliance’s CPUs, memory, or network interfaces will impact other customers sharing those resources.

Sharing the same user space particularly becomes a problem when activating advanced security capabilities. While basic firewall functionality is very efficient, advanced security requires more compute power and reduces the overall performance of the appliance.  Activating a firewall’s intrusion prevention system (IPS), data loss prevention (DLP), TLS inspection, or Quality of Service (QoS) enables user space processes for all traffic through the firewall, even if  a policy does not enforce it or a specific customer did not request the feature.

What’s more, some leading enterprise firewalls optimize memory utilization by keeping a customer’s configuration in memory at run-time. They are able to do this, though, because single customer configuration is often small. With FWaaS servicing hundreds and thousands of customers, maintaining all customer configurations in memory would dramatically increase memory requirements and could degrade overall firewall performance.

Another example, when an application establishes a connection through an enterprise firewall, the firewall scans all of the security rules in its security policy for a match. If no match is found, the firewall’s final rule, the cleanup rule, will drop the connection. With a single enterprise, the number of rules is comparatively limited. However, when enterprise appliances are used to build an FWaaS, all customers share the same security policy. With each customer creating hundreds rules, the firewall ends up having to scan tens of thousands of rules, significantly degrading its performance.

More broadly, enterprise firewalls come with numerous legacy features and capabilities, such as dynamic routing, physical link separation, and integration with third-party services. These features and capabilities were designed for on-premise environments and are irrelevant for FWaaS, or worse, create a performance drag on the appliance.

Management and Upgrades

But it’s not just their performance limitations that make enterprise firewalls ill-suited as platforms for FWaaS offerings. It’s also how they handle administrative activities. Enterprise firewalls were designed for a few administrators making occasional policy changes. FWaaS offerings, though, may be simultaneously updated by hundreds of administrators across organizations. The concurrent policy modifications become a resource-intensive operation, one that was never part of the design of enterprise firewalls. Unexpected delays often occur as the enterprise firewall must implement all changes.

Firewall software updates are also handled differently in the cloud than in the enterprise. FWaaS providers frequently update their services and expect to do so without any downtime or impact on the customer. FWaaS software services are allocated dynamically to customers, ensuring that service quality is not degraded as nodes are upgraded customers.

Enterprise firewalls appliance were not designed to scale or to be managed in quite the same way. Platform-wide upgrades of the multiple systems comprising a firewall are not native to the architecture.  Updates need to be scheduled for maintenance windows. Resources are allocated and locked per customer, preventing efficient usage by multiple customers. In many cases, the compute power of an enterprise firewall is intentionally limited, as it was designed for a price-competitive market.

Virtual Platforms and Cloud Appliances

The logical answer for FWaaS providers would seem to be deliver multi-tenant security solutions, such as Fortinet’s Virtual Domains (VDOM).  These are physical appliances designed to run multiple virtual firewall instances. Providers can instantiate new firewalls easily and quickly for customers while avoiding the power, spacing, and cooling requirements that must be addressed in order to run racks of physical appliances.

However, these multi-tenant solutions fail to create a full virtual environment for each customer system. A customer’s virtual firewall ends up competing with the other virtual firewalls for the memory and compute resources of the underlying appliance, making sizing and capacity planning particularly challenging. Scaling these solutions require large upfront investment. Expanding into new markets requires the installation and deployment of a hardware platform (two for high availability), complicating geographic expansion.

Software Built for the Cloud

To accommodate multiple customers on an enterprise firewall, vendors would need to re-architect the firewall appliance. They would need to adjust both the management and the enforcement points of the appliance. In most cases, the firewall vendor would need to rewrite the core capabilities of the appliance software to avoid policy management collisions between customers and deadlocks between multiple rules configured by different customers. Integration into each customer’s management platform, such as Active Directory or a SIEM, would also need to be upgraded. The enforcement function of firewall will need to adjusted to only apply to only the requisite customer’s traffic not all traffic. Otherwise, one customer enabling a new IPS signature, for example, would end up impacting the traffic of all customers.

In reality, enterprise firewall vendors can’t easily adapt their appliances to become the basis of FWaaS. There are too many issues with core firewall operations that must be changed to meet the cloud’s requirements for multi-tenancy, scalability, and elasticity.  At the same time, existing multi-tenant solutions inefficiently share resources and require large upfront costs. Deploying them to new regions is costly and challenging.

A FWaaS requires a new cloud-scale architecture that can enable the FWaaS provider to deliver  the necessary scalability, elasticity, and rapid deployment capabilities required to support today’s business.