The Evolution of the Firewall Part I - Help Me Find Unicorns at RSA

Allow Anyone on the Inside to Get Out

Assuming the first firewall policy ever written was: “Allow anyone on the inside to get out, but keep everything out there from getting in”, this firewall would have been from the late 1980’s and deployed as a router with filtering rules. I would argue that the first widespread use of firewalls was an unintentional one, through the use of NAT, whose very nature allowed connections from the inside without much configuration, but required a very manual setup to allow addresses from the outside to communicate with a select group of hosts on the inside. The first NAT device was the PIX firewall, circa 1994, followed by everyone else. This “byproduct firewalling” made itself available to those who were “fortunate” enough to not have a publicly routable netblock assigned to them, for use on internal hosts. I remember the days when those netblocks were readily available, and the increasing number of hoops you had to jump through to obtain one as the years rolled by. Everything old is new again, you can say that with IPv6 routable address space and no NAT.  

Which State are you In?

The evolution of the firewall beyond filtering and NAT took place in 1994 with the introduction of Check Point Software’s FireWall-1 product. Stateful firewalls soon became the norm, where the state of a connection is tracked in a state-table, allowing the firewall to make intelligent decisions about the legitimacy and nature of a packet. What is interesting is that deep packet inspection, or application awareness arose early on in the firewall evolution, even before stateful inspection was introduced. The TIS Firewall Toolkit or FWTK was made freely available in 1993, but was not widely deployed due to expensive hardware requirements at the time. It is also obvious that the perceived need would have been low, and non-existent outside of the usual suspects of DARPA, government, military and their close associates. Interesting to note, DPI arrived on the scene as a marketing term 10 years after the introduction of FWTK, with its code making its way into commercial products including Gauntlet and Sidewinder.

Early firewall requirements including the “first firewall policy” stated above were simple, supporting simple applications including remote terminal access, FTP (when it actually worked, remember passive FTP settings anyone?), and email. These requirements did not stay simple for long as applications and services evolved into the data encryption, voice, video, web and IoT we have now. Naming those few, I am sure there are firewall admins out there that think about the department-by-department dissection of Facebook and its associated services into a laundry list of firewall rules allowing video for marketing and no access for shipping and receiving. Complexity arrived and exponentiated. Some firewalls ground to a halt, and in came the vertical box pushers until the horsepower game changed.

The Control Plane

The first time I experienced the separation of the control plane from the data plane on a firewall was with Palo Alto Networks PA-4000 and PA-5000 series firewalls. I can’t say for sure that they were the first to do this in 2010, but I did know what it was like for my clients to lose management access to their Check Point and Cisco solutions. I also knew that turning up features such as IPS/IDS, NBAR (Network-Based Application Recognition), increasing rule-set complexity and/or length, had a performance impact on firewall throughput heavily dependent on average packet length. Spec sheets were prayer sheets and everything was either over provisioned or under provisioned depending on who you spoke to. It was really difficult to size a firewall deployment across the enterprise without digging deep into the CFO’s pockets for a good dose of CYA (Cover Your Ass).

Palo Alto changed this multivariant and unpredictable meandering from the spec sheet to a simple one line understanding that brought joy in my lab with the PA-4050, as I was unable to bring it below spec, I could not crush it the same way I could on an ASA. You had a 10 Gbps firewall with App-Id enabled, and 5 Gbps with one or all of the threat prevention features enabled, which was a long-list of DPI functionality including the ground-breaking App-ID feature with 1000’s of signatures that you could customize and contribute to the community, compared with less that 150 Cisco NBAR signatures that only Cisco could provide, if they decided. The visibility into the network that Palo Alto spearheaded with was groundbreaking, often overlooked and now taken for granted. All vendors worth their weight in salt now include similar capabilities. IPS/IDS, malware and other DPI functionality without throughput sacrifice was made the norm by Palo Alto.

Help Me Find Unicorns at RSA

To think that this was just 10 years ago, and that there were only a handful of evolutionary stakes stuck in the ground in the 25 year period prior brings me into a state of awe and awareness. My gears are turning in my desire to identify the evolutionary changes that are taking place on what seems to be a daily basis in our current time. It’s not for the lack of need. Gaps still exist, hosts are still vulnerable, devices are still exploitable and defense in depth is almost a family discussion at the kitchen table. I am really looking forward to meeting a Unicorn at RSA next week. Where would you place your bet, would that Unicorn be walking the crowd, sitting in a 10x10 in the back, or would it be an acquisition by one of the giants at the entrance with multiple 20x30’s? The firewall has and must continue to evolve, Krebs on Security is a daily reminder. God bless the firewall, it’s history and its continued evolution in all forms across our networks, hosts and devices.