The term “firewall” has a history of over 30 years in the context of network security. In that time, the spaces it safeguards have evolved beyond recognition, the threats it needs to counter have increased in complexity and scale, and the technical mechanisms available for deploying it have proliferated across multiple layers of the network stack. Change its name through all that? No thank you.
This represents a challenge for IT professionals. A term that originally referred to a limited functionality (a packet filter functioning at the boundary between a private network and the public Internet) now encompasses implementations that differ in several dimensions: depth of inspection, architecture, and breadth of protection. If you are responsible for making network security decisions, you need to learn how the firewall concept has evolved, and what it means at each point along that evolution.
Security practitioners looking for a comprehensive reference grounded in current capability can explore firewall definition for IT professionals as a starting point for understanding both where the concept has come from and what modern platforms are expected to deliver.
The foundation of modern-day firewalls:
Back in the first days of network security, when the word firewall was used it meant a system that checked packets against a static set of rules. These rules defined what combinations of source address, destination address, port, and protocol were allowed or denied through the network seams. Each packet was assessed on its own without any information taking into account the connection it belonged to or what had come before.
This initial generation of firewall technology was called out for a very particular and pressing need. With organizations networked internally before the internet itself, that exposure was immediate and urgent. You had a major reduction in attack surface at a time when basically none of that kind of control existed on the edge, by having a boundary control filtering out packets targeting publicly accessible services, but not those public, or packets from sources that should never have been talking to anything internal.
Packet filtering behavior was fast, deterministic, and relatively easy to implement. This was also its obvious limitation: It looked at headers not content and had no understanding of the connection context where each packet arrived. An attacker could generate packets whose header values met criteria for passing through, and rules controlling individual packets were unable to distinguish genuine return traffic from unsolicited incoming connections that also used the same port.
The Shift to Stateful Inspection
Stateful inspection was introduced to address the single most significant structural weakness of packet filtering. Rather than inspecting packets independently, a stateful firewall tracked connections in a session table and analyzed each packet in the context of its session. This enabled the firewall to differentiate between traffic that was a legitimate response for an initiated connection from inside the protected network and inbound traffic without a corresponding session entry.
From the mid-to-late, stateful inspection became the baseline standard for enterprise firewall deployments and remained the dominant architecture through the 2000s. It was a reasonable and effective control for the threat environment of that time period. Back in the day, without the myriad protocols employed and the web applications that would come to saturate traffic, the Internet had a much simpler traffic mix, far more predictable in its distribution, with a focus on packet-level attack techniques where application behaviors were not yet common targets.
As web-based application traffic multiplied it soon became apparent a limitation stateful inspection could never resolve. Because most internet traffic flows over port 80 and port 443 (the standard HTTP and HTTPS ports) a traditional firewall that analyzes connection states has little reason to differentiate between good web traffic and bad payloads travelling through the same channels. The port that used to signal what service is being run had turned into a well-known route for anything; threats included.
Application-Layer Visibility
Another major evolution of the firewall concept was the extension of inspection into the application layer. Unlike packet filtering which looked at headers, and stateful inspection which analyzed connection context, application-layer inspection inspected traffic content – that is what the payload actually contained and whether it matched up with typical acceptable use of the protocol in use to carry it.
This ability to inspect the application-level traffic made it possible for firewalls to recognize specific applications irrespective of port, discover attacks embedded in otherwise allowed flows of traffic, enforce content-based policies for data capture and detect protocol misuse where an attacker abuses a legitimate protocol as a covert channel. For example you see the HTTP connection containing a SQL injection or an encrypted session being used for data exfiltration, meaning it was detectable by the firewall rather than invisible to it.
The practical and technical dimensions of how traditional stateful inspection firewalls gave way to next-generation platforms including how the shift to application-layer traffic drove demand for deeper inspection capabilities and what IT professionals evaluating this technology need to understand about the architectural differences, are examined in depth in the practitioner analysis of next-generation firewall evolution available through CDW security editorial coverage.
The Integration of Control and Next-Generation Firewalls
“Next-generation firewall” is a term that originated in the late 2000s to describe network security platforms that not only had application-layer inspection (similar to deep packet inspection), but also new capabilities for stateful firewalls: user identity awareness, integrated intrusion prevention, SSL/TLS inspection, and threat intelligence integration. The advantage of next-generation platforms was that they brought these capabilities together into a unified processing architecture, where, instead of deploying them as separate appliances that required individual management and correlation, you could apply multiple analytical functions in a single inspection pass.
This joining of capabilities had a much more tangible impact. With application identification, user identity and intrusion prevention running in the same inspection pipeline, there is an opportunity for collaboration. An application that is as a particular web service releases an information context, rendering the intrusion prevention module analysis more specific. A user identity with certain role-based access gives you the context to make application-level policy enforcement finer-grained. The total of integrated capabilities is greater than operating any of the same functions in isolation.
The Perimeter’s Transformation
The advancement of firewall technology has been a vertical change that is not taken in isolation, but instead follows and propels the evolution of the network landscape it serves to protect. On-premises enterprise networks once possessed a clearly defined network perimeter with trusted interior and untrusted exterior, separated by a single control point; now the idea that most enterprise networks still conform to this model is essentially over as organizations have wrapped up cloud platforms, remote workforces, SaaS applications, and microservices architectures that function across inherent boundaries no perimeter firewall can completely encapsulate.
That did not render the firewall concept dead, but actually changed how that answer must be applied. The enterprise network has many boundaries now, across cloud environments, between internal network segments, at the edge of remote access infrastructure and at the endpoint of application service meshes; no longer a single perimeter. Those edges need their access control logic, which is specific to the traffic that traverses them and their associated threats.
The implications of this shift for how organizations approach network security including how traditional perimeter-based security appliances have evolved as point solutions and how modern frameworks such as zero trust network access and secure access service edge have emerged to address boundaries that traditional approaches could not reach are documented in the federal guidance published by NIST through the enterprise network landscape guidance covering the modern enterprise security environment.
What the Evolved Definition Signals for IT Professionals
The evolving concept of the firewall has a practical implication for IT professionals; you cannot take the term at face value without context. What a vendor refers to as a firewall or what the compliance framework defines to be firewall deployment or how the security policy describes that firewalls are expected at the various network boundaries, well that can vary based on what those terms mean in context.
Although a packet filter is technically a firewall, it will fulfill nearly zero modern security or compliance criteria that were drafted in-line with the currently deployed threat landscape. A stateful inspection firewall allows for useful network and transport layer access control but provides no awareness of the application-layer threats that now make up most attack traffic. While a next-generation firewall providing application inspection, user identity awareness and SSL/TLS decryption is a solution that meets the current threat landscape, it also may result in features needing to be manually tuned and integrated with adjacent controls over time.
The evolution of the term shows how the problem has evolved. In assessing any particular implementation of the firewall concept, you need to know which generation you are dealing with and whether the generation is appropriate for the environment and threat landscape it addresses.
Frequently Asked Questions
The concept of a firewall has evolved from the time it was conceived.
Over the years, I have seen three major phases of evolution of the firewall concept. Early packet-filtering firewalls analyzed packets against a set of static rules (such as IP and ports). Adding connection-awareness to the original form of packet filtering, stateful inspection allowed firewalls to analyze traffic relative to the sessions it belonged to. The next-generation platform extended inspection to the content and context of traffic, rather than just at its headers and connection state; they also added application-layer inspection, user identity awareness, and integrated threat intelligence.
What prompted the need for an application-layer inspection?
The port-based filtering model that earlier firewalls optimized for was less and less useful as web-based traffic overtook internet communications. A firewall capable of differentiating traffic solely by port may not have much of a foundation to classify what that traffic actually is, if nearly all information flows over the same standard web ports. Application-layer inspection provided deeper insight into what traffic this application was creating, whether the content of that traffic resembled expected use of the protocol in question, and whether suspicious patterns consistent with known attack techniques were present, thus enabling the firewall to make security decisions about web-based traffic far more effectively.
Evolution of firewall technology rendered older implementations obsolete?
Legacy firewall generations can be justified in spaces where the feature set meets the need. Packet filtering and stateful inspection still make sense at the internal network boundary where only coarse-grained access control is required, or in environments where the traffic mix and threat landscape do not justify application-layer visibility. It is not that earlier generations have become ineffective, rather they merely fall short when serving as the primary security control of boundaries exposed to contemporary application traffic and exploitation techniques.