The NGFW is Dead

The NGFW is Dead

Let’s get this out of the way – the next-generation firewall (NGFW) is dead. In ten years, the NGFW will be reduced to a glorified router. The cloud is the prime suspect in the NGFW’s death.

The shroud of death and decay are all around the NGFW products. They are bloated, expensive, and ineffective. They command irrational emotional fetishism among their users who consistently overemphasize their importance.

However, this death is a slow one. You still have time to make arrangements for life after the NGFW.


You Are Not Your NGFW

The NGFW (or UTM if you prefer that parlance) has ruled over security for about 10 years. NGFW grew out of the merging of firewalls, intrusion prevention systems, and web proxies to become the Swiss Army Knife of security. Everybody has a NGFW, and of course the one you bought is the best (insert eye-rolling meme here).

The NGFW is not only the central technology in every security program, for some practitioners the NGFW *is* the security program. It is not uncommon for a CISO, when asked about their security program, to begin their answer with “well, we have Palo Alto’s at the perimeter…” Moreover, many security teams define their entire security posture and incident handling around their NGFW.

Consequently, proclaiming that the NGFW is dead will illicit skepticism among many, and spittle flecked rage among others.

But, as Tyler says, you are not your NGFW (or your khakis for that matter.)


Day of the Dead

Before you fly off the handle, or any other car part for that matter, let’s explore the four reasons the NGFW is dying:

  1. The network perimeter is gone
  2. NGFW’s are not designed for cloud architectures
  3. Cloud providers are (or will) offer the same capabilities at a fraction of the cost
  4. The NGFW is no longer relevant

These reasons are borne out of observations of trends, specifically where the cloud is concerned.

Vanishing Boundaries

Modern organizations have, at best, a flimsy network perimeter. As companies move more data and workloads into the cloud, the company “perimeter” extends to those cloud providers. Moreover, when you add a remote worker pool into the mix, whatever soft perimeter existed before, becomes completely ephemeral. Without a clear perimeter, each individual laptop, phone, and IoT device is a perimeter. Likewise, the classic core data center is disappearing as well, for all the same reasons.

This is the driving force behind cloud endpoint companies, like Zscaler. At RSA a few years ago, Zscaler had a supremely entertaining booth where you could take a sledgehammer to NGFW hardware like Palo Altos and CheckPoints. I ashamed to admit, but I whacked a few Cisco ASAs.

At the time, I thought this was merely a marketing gimmick. However, Zscaler was having a Howard Beale moment : hardware is meaningless when your workforce, data, and systems are distributed throughout the cloud, homes, and coffee shops.

Zscaler represents this shift from large racks of network gear, to a cloud provider that aggregates connections and data in the cloud, and provides all the security scanning, filtering, and protections you need. When you have critical business systems in the cloud or SaaS providers, that giant Palo Alto or Checkpoint you bought is utterly meaningless to their security. The on premise NGFW is relegated to a basic connectivity device at the office.


Cloud Natives

When you move data and workloads into the cloud, the whole concept of networking mutates. Cloud providers, like AWS and Azure, are software-defined networks. All traffic and connectivity are virtualized and abstracted from the actual wires and routers. This is even more pronounced with SaaS providers, where there is no network at all.

Furthermore, software-based networking does not have the constraints of traditional networks. Traditional “three tier” networks aggregated and concentrated access because it was efficient. However, it is constraining. All traffic must go back to central routes and NGFWs for access.

In the cloud, this is unnecessary. Traffic goes directly where it must go. For example, if you have application servers and database servers, you do not connect them through a router, rather you peer them together. Since you do not control the underlying physical connectivity, there is no reason to route back to a central point.

Peering provides extremely granular and dynamic access control. Not only can you control network, application, and user-level access but that access can be granted and revoked in an automated manner based on specific conditions or triggers. Using cloud management solutions, you can constantly audit those controls, and revoke them if any access violates company policies. This level of control is nearly impossible in a traditional, hardware network.

Moreover, when native cloud services are used, such as AWS’s identity and access management (IAM) or Azure’s hosted Active Directory, there is no actual server to connect to. Rather, you peer your VPCs or hosts to the service itself.

Peering simplifies the network, without reducing any of the access control. In a sense, you do not need to network at all.

It is clumsy (and even impossible in some cases) to put a NGFW between cloud hosted systems and native services. While all of the NGFW makers offer cloud versions of their products, more often than not, these are relegated to VPN connectors. Whatever security functions they provide are easily supplanted with other capabilities.

Consequently, the lack of NGFWs in the cloud has seen a subsequent rise in host-based security solutions. Companies like Trend Micro understood this years ago, and began releasing cloud-centric versions of their products that offer all the NGFW capabilities, on a host-based platform. Furthermore, when you automate the deployment and configuration of those endpoints (which is exactly what we do in our Sherlock Managed Detection and Response services) then you can uniformly enforce security on every host in the environment.


On Guard Duty

Cloud platforms, namely AWS and Azure, offer (or will offer soon) NGFW capabilities. No large piece of equipment (or virtual image) necessary.

With the release of Guard Duty from AWS, it is blatantly obvious where AWS is headed. AWS wants to own not only your compute workloads, but all the infrastructure as well.

Guard Duty is a native AWS application that offers intrusion detection monitoring Traditional intrusion detection (prevention) systems (IDS/IPS) are nearly impossible to deploy into cloud networks because you cannot see the full network packet. The abstraction of the network, also means you cannot sniff traffic.

In the next few years, AWS and Azure will, in some manner, offer all the capabilities of a NGFW as native products. This is a logical maturation for any Infrastructure as a Service provider. Also, as adoption of native NGFW capabilities increases, cost will plummet. This will further erode the value of the traditional NGFW.

Epic Fail

The final reason the NGFW is dying is perhaps the most obvious – NGFWs are ineffective. Every organization that has reported a megabreach had a NGFW. And those NGFWs did nothing (or little) to stop the breach.

In all fairness, it is not the NGFW technology that is the root cause here. Rather, it is a cumulative set of architectural and organizational issues that conspire to further diminish the value of a NGFW. These issues include:

  1. There are numerous ways to get around NGFWs, using mobile networks or physical devices
  2. Trusted third parties who demand unrestricted access often bypass all NGFW security
  3. The people managing the NGFW lack the authority to enforce rules or their concerns are routinely dismissed

Practices to monitor the NGFW for alerts are ignored because…

  1. SIEM technologies are complex and time consuming to administer
  2. Organizations lack qualified staff
  3. There is organizational pressure to avoid reporting an incident, since it will invite scrutiny
  4. There are too many alerts

Even if it was reported, it is easier for IT teams to argue the alert, than actually fix anything.

Any one of these issues can lead to a breach and devalues the NGFW.

However, the reluctance to report alerts is perhaps the most distructive (and widespread.) Large organizations often cultivate a culture of passive aggression and conflict avoidance. Leaders exacerbate this when they demand responsibility, but refuse authority. In other words, they demand that security teams are completely responsible for keeping the company secure, but routinely deny them the authority to enforce security.

In these places, the NGFW becomes and expensive network speed bump. A technology whose sole purpose it is to control access and detect malicious behavior is at the mercy of people who are unable to actually do that.


You Can Have My NGFW When You Pry it from my Cold, Dead Rack

About now, you are either depressed, because you agree with my assessment of the NGFW, or you are angry and figuring out what personal flaws I have so you can attack me.

Here, I will help you with some flaws I have: I am angry, fat, and swear a lot. I also spend way too much money on cars, and routinely say insulting things to people.

There, I am sure you can belittle me with one or all of those.

However, before you go rip that Fortinet from its FortiBolts, chill out. The NGFW is not dying a quick death. All that money you spent is not immediately going to waste. This death is slow, and not complete. The NGFW will not disappear, rather it will mature.

In five to ten years, the NGFW will be more of a cloud connectivity appliance. It will continue to control access. You will manage it more like you manage a SaaS subscription. And secure, controlled connectivity to AWS, Azure, Salesforce will be baked right into the entire platform.

Also, AWS and Azure will have their own NGFW-like services, meaning you can ditch your on-premise NGFW entirely, and use inexpensive routers. Moreover, services like Zscaler will make more sense, than a big iron box of wires.

The bigger movement happening here is the growing irrelevance of on-premise anything. NGFW is really part of a much larger trend. As companies move more and more workloads into the cloud, all those racks of gear become less and less relevant.

In 2012, people were fighting to keep their Exchange services on-premise. Here it is 6 years later and the notion of having an on-premise Exchange server is almost laughable. In 6-10 years, the notion of having a giant, $100,000 core NGFW will seem laughable.


Prepare for the End

If you want to prepare for the demise of the NGFW, the answer is all over your Azure or AWS console. While this is not a comprehensive list of things you can do to prepare, it will get you going down the path.

  • Refocus on endpoint security, specifically solutions that offer NGFW functions at the endpoint
  • If you have a distributed workforce, then you should have companies like Zscaler on your radar
  • Move those workloads into the cloud
  • Cloud security is not the same as on-premise security. This topic is outside the scope of this blog, but suffice to say, you cannot just forklift all your on-premise gear into the cloud and expect it all to work
  • Risk management and personal development should be at the core of your security program, not technology SIEM technology is more important in the cloud. You need data to drive decisions. This too is a whole different blog.

As you can see, once you open the doorway of a post-NGFW world, things change, significantly. The more cloud-focused your team the better suited you will be for this change.


In 2003, when Richard Stiennon declared IDS was dead, he was hounded for years. It is normal for people to react to a new idea with score, anger, and childish harassment. Stiennon was correct, of course. The IDS was a dying tech. Those of us who watch the security industry night and day, these trends are obvious. Look around, the cloud is gobbling up everything, and like it or not, the NGFW is its next victim.

Not only is the NGFW on the way out, the “human firewall” isn’t doing so well either – read more here.


The post The NGFW is Dead appeared first on Anitian.

*** This is a Security Bloggers Network syndicated blog from Anitian authored by Andrew Plato. Read the original post at: