Can Stateful Inspection Evolve?

One of my many roles as a founder and CTO is to meet with customers and talk about their network security issues. These visits are not only informative, they can be humorous as well. For example, a recent visit to a large, fortune 500 company, they told me that one of our firewall competitors explained that Stateful inspection would evolve to include application visibility and control. As one of the original engineers working on Stateful inspection, I found this statement extremely humorous.

We created Stateful Inspection at a time when applications could be controlled using ports and source / destination IPs because applications were tightly tied to ports and protocols. But today, applications of all types no longer adhere to port and protocol which means they can no longer be controlled, let alone identified by today’s port-based (Stateful Inspection) firewalls.

Today’s applications use either well-known open ports or a variety of evasive tactics to easily bypass firewalls. Sadly, most 11^th graders can go into any corporate network and use any application they want, go anywhere on the internet and do anything they want through the corporate network and there is nothing firewalls can do about this. The fundamental reasons that Stateful inspection can be easily evaded include they rely on fixed ports, they look only at the first packet and they are unable to inspect SSL traffic.

The question then becomes one of whether or not Stateful inspection can evolve in the same manner that the applications have. The answer is no. Stateful inspection is architected to classify traffic based specifically on ports and protocols. The use of port and protocol traffic classification is hard coded - it is arguably the most fundamental component of Stateful inspection because it is used as the basis of the security policy. The allow or deny decisions are based on the port and protocol, so modifying Stateful inspection to replace port and protocol with application identity means a complete re-write of the software, a monumental task, given the foundational importance of traffic classification. Here is why Stateful inspection cannot evolve.

Stateful Inspection firewalls enforce policy decisions for a complete TCP or UDP connection upon receiving the first packet of that connection. Once the policy decision is made, further inspection and associated policy lookup is not required because every packet carries the same port number and the following packets from the same connection are not going to provide any additional information about the connection. This form of classification and policy enforcement cannot control many of the applications we see on enterprise networks.

Classifying traffic based on applications must continuously examine packets and check the policy table in order to determine how to treat a given connection. For example, the first packet might have a destination of port 443. The firewall performs a policy check and determines that the connection should be accepted. After a few more packets, the firewall might learn that this an SSL connection (it could have been non-SSL on port 443). Again, the firewall consults the policy to determine whether to allow the connection and also figure out whether this SSL connection needs to be decrypted. After a few more packets, the firewall might learn that this is HTTP inside SSL on port 443. Again, the policy lookup needs to be performed. Additional inspection might determine that this is Yahoo! Instant Messenger, which again requires a policy look up and an allow or deny decision. The traffic classification and policy lookup process continues in this manner for all traffic across all ports.

During the continuous classification process, firewalls that classify traffic based on applications do more than just multiple policy lookups. They need to determine when to log new information they discover—which is a continual process, given the comparatively dynamic nature of application traffic. In addition to continual policy lookup and logging, the application is used as the basis for route lookups, QoS decisions, threat prevention and so on.

Now, let’s assume a complete rewrite of Stateful inspection is achievable, it is only one of the two components required to deliver an enterprise-class firewall that controls applications. The second component is the hardware required to support application layer inspection across all ports and on all traffic. It is well documented that this level of inspection requires significantly more processing power then mere port-based scanning. For example, in a Stateful inspection firewall, a flow that is established can move to a “fast-path” because it does not requires any more policy lookups. As described above, this is not the case with an application aware firewall. The continual inspection and policy lookup requires appropriate processing be applied to maintain performance. Existing Stateful inspection vendors would therefore be forced to not only re-write the software from scratch—they would need to develop in tandem, a new hardware platform with appropriate processing power.

In short, Stateful inspection, cannot evolve to control applications. A new approach is needed – one that identifies applications as soon as the traffic hits the box, ignoring ports, protocols, evasive tactic or SSL encryption. That is what we created here at Palo Alto Networks.