NGFW = No Good For Workloads…
So-called Next Generation Firewalls (NGFW) are those that extend “traditional port firewalls” with the added context of policy with application visibility and control to include user identity while enforcing security, compliance and productivity decisions to flows from internal users to the Internet.
NGFW, as defined, is a campus and branch solution. Campus and Branch NGFW solves the “inside-out” problem — applying policy from a number of known/identified users on the “inside” to a potentially infinite number of applications and services “outside” the firewall, generally connected to the Internet. They function generally as forward proxies with various network insertion strategies.
Campus and Branch NGFW is NOT a Data Center NGFW solution.
Data Center NGFW is the inverse of the “inside-out” problem. They solve the “outside-in” problem; applying policy from a potentially infinite number of unknown (or potentially unknown) users/clients on the “outside” to a nominally diminutive number of well-known applications and services “inside” the firewall that are exposed generally to the Internet. They function generally as reverse proxies with various network insertion strategies.
Campus and Branch NGFWs need to provide application visibility and control across potentially tens of thousands of applications, many of which are evasive.
Data Center NGFWs need to provide application visibility and control across a significantly fewer number of well-known managed applications, many of which are bespoke.
There are wholesale differences in performance, scale and complexity between “inside-out” and “outside-in” firewalls. They solve different problems.
The things that make a NGFW supposedly “special” and different from a “traditional port firewall” in a Campus & Branch environment are largely irrelevant in the Data Center. Speaking of which, you’d find it difficult to find solutions today that are simply “traditional port firewalls”; the notion that firewalls integrated with IPS, UTM, ALGs, proxies, integrated user authentication, application identification/granular control (AVC), etc., are somehow incapable of providing the same outcome is now largely a marketing distinction.
While both sets of NGFW solutions share a valid deployment scenario at the “edge” or perimeter of a network (C&B or DC,) a further differentiation in DC NGFW is the notion of deployment in the so-called “core” of a network. The requirements in this scenario mean comparing the deployment scenarios is comparing apples and oranges.
Firstly, the notion of a “core” is quickly becoming an anachronism from the perspective of architectural references, especially given the advent of collapsed network tiers and fabrics as well as the impact of virtualization, cloud and network virtualization (nee SDN) models. Shunting a firewall into these models is often difficult, no matter how many interfaces. Flows are also asynchronous and often times stateless.
Traditional Data Center segmentation strategies are becoming a blended mix of physical isolation (usually for compliance and/or peace of mind o_O) with a virtualized overlay provided in the hypervisor and/or virtual appliances. Shifts in traffic patterns include a majority of machine-to-machine in east-west direction via intra-enclave “pods” are far more common. Dumping all flows through one (or a cluster) of firewalls at the “core” does what, exactly — besides adding latency and often times obscured or unnecessary inspection.
Add to this the complexity of certain verticals in the DC where extreme low-latency “firewalls” are needed with requirements at 5 microseconds or less. The sorts of things people care about enforcing from a policy perspective aren’t exactly “next generation.” Or, then again, how about DC firewalls that work at the mobile service provider eNodeB, mobile packet core or Gi with specific protocol requirements not generally found in the “Enterprise?”
In these scenarios, claims that a Campus & Branch NGFW is tuned to defend against “outside-in” application level attacks against workloads hosted in a Data Center is specious at best. Slapping a bunch of those Campus & Branch firewalls together in a chassis and calling it a Data Center NGFW invokes ROFLcoptr.
Show me how a forward-proxy optimized C&B NGFW deals with a DDoS attack (assuming the pipe isn’t flooded in the first place.) Show me how a forward-proxy optimized C&B NGFW deals with application level attacks manipulating business logic and webapp attack vectors across known-good or unknown inputs.
They don’t. So don’t believe the marketing.
I haven’t even mentioned the operational model and expertise deltas needed to manage the two. Or integration between physical and virtual zoning, or on/off-box automation and visibility to orchestration systems such that policies are more dynamic and “virtualization aware” in nature…
In my opinion, NGFW is being redefined by the addition of functionality that again differentiates C&B from DC based on use case. Here are JUST two of them:
- C&B NGFW is becoming what I call C&B NGFW+, specifically the addition of advanced anti-malware (AAMW) capabilities at the edge to detect and prevent infection as part of the “inside-out” use case. This includes adjacent solutions that include other components and delivery models.
- DC NGFW is becoming DC NGFW+, specifically the addition of (web) application security capabilities and DoS/DDoS capabilities to prevent (generally) externally-originated attacks against internally-hosted (web) applications. This, too, requires the collaboration of other solutions specifically designed to enable security in this use case.
There are hybrid models that often take BOTH solutions to adequately protect against client infection, distribution and exploitation in the C&B to prevent attacks against DC assets connected over the WAN or a VPN.
Pretending both use cases are the same is farcical.
It’s unlikely you’ll see a shift in analyst “Enchanted Dodecahedrons” relative to functionality/definition of NGFW because…strangely…people aren’t generally buying Campus and Branch NGFW for their datacenters because they’re trying to solve different problems. At different levels of scale and performance.
A Campus and Branch NGFW is “No Good For Workloads” in the Data Center.
/Hoff
An epic post, which reminds me of this gem of yours from 2008 http://www.rationalsurvivability.com/presentations/FourHorsemen.pdf. The more things change the more they stay the same.
Shortly after the IPO for a NGFW vendor, I spent a day talking to tech fund managers about the security space. The first question from each person in the room was ‘what do you think of $vendor?’. Much sadness ensued when we said we weren’t buying those silver bullets (and that we really didn’t see what problem they were meant to solve).
There was a broader conversation, that having outsourced our network operations to a service provider we weren’t really in the market for network equipment at all, but even then… cost of ownership was much more important than fancy new features (which made UTM look like a much better idea than NGFW).
Great post. You hit on a lot of the same points I made in a conversation I had with McA^H^H^H Intel recently regarding the value proposition of their NGFW product offering for large enterprises and how they should position themselves (they didn’t listen to me).
I’ll say that Cisco is on the right track post-SF acquisition moving to a single physical architecture (ASA) for both traditional packet-filtering FW and application-layer FW. Their design will give orgs the ability to stay on a single platform/partner and will reduce overall capital expense since it provides a lot of deployment options within a single capital purchase.