I would like to formally retract the statements I made about NSS Labs and extend a formal apology. After learning more about their services offerings, I now realize that NSS Labs is a well-known, independent security and testing lab that performs comprehensive security validation using real-world traffic and usage conditions. My statements are untrue and I feel that the nature of their testing is indeed unbiased and invaluable to both us and our customers.  My company, Palo Alto Networks, is working with NSS Labs and we have found them to be completely transparent and honest.  NSS Labs has helped us to better tune our IPS functionality. We have full confidence in NSS Labs and will continue to work with them as a primary source for independent IPS testing.

Sincerely,

Nir

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.

This is absolutely true. You will never see Fortinet, which describes itself as the “worldwide leader in UTM”, winning an enterprise deal on the merits of an individual component of their appliances. I have never seen Fortinet invited to participate in IPS shootouts alongside the market leaders, as their IPS is not enterprise grade but rather a lame version of Snort. Fortinet, despite being the first vendor to add anti-virus to a firewall, never replaces enterprise anti-virus gateways due to their ridiculously low catch rates. They offer database security but would never be considered by enterprise alongside Imperva and F5. They offer WAN optimization but would never win a deal against Riverbed or Cisco. UTM is a jack of all trades but master of none, or as my good friend Laurent Daudre-Vignier puts it, UTM, and Fortinet specifically, is like a duck. It can fly, swim, walk, dive, tweet and lay eggs but cannot do any of these very well… Fortinet, by the way, is not alone. Check Point’s UTM products will also never win a deal on the merits of an individual UTM component.

There are, however, multifunction devices that have best of breed components in them. Juniper has integrated security devices which have a world-class firewall and a best-of-breed IPS (I built both…). Palo Alto Networks, my current company, is winning IPS deals, gateway Anti-Virus and Anti-Spyware deals as well as content filtering deals in major enterprises, surpassing in features, quality and performance vendors that focus just on these individual components.

So, was Greg wrong by comparing enterprise UTM to Unicorns and Pixies? No, he wasn’t—but perhaps he should add a duck to his list of animals. Unified Threat Management, as the name suggests, unifies multiple point products into one device. I view it as consolidating the network security mess into one messy appliance.

Nir.

But this time, Richard, I have to disagree with you. Putting a firewall and an IPS on the same box is not innovation. I did it as the CTO of NetScreen more than 6 years ago so it’s certainly not new. And even then it was not innovative. Even in U.S. patent law, which sets the bar quite low on what can be patented (as in Sealed Crustless Sandwich), the mere action of putting two things together does not create something that is patentable. But above all that, putting firewall helpers, such as an IPS, on the same box as the firewall, does not make a better firewall. To make a better firewall, one needs to change the firewall itself. Check out my video response to learn more…

My prediction? Like a smart co-worker of mine says, in these situations physics does not apply and two rocks tied together sink faster than one.

This whole thing also got me thinking about proxies and their role in network security. If you think about it, proxies are not a natural choice when it comes to networking. They are slow, they add significant latency, and they break all applications for which they are not specifically designed to support. Proxies have traditionally supported very few applications due to the need to pretty much redevelop an entire application – both client and server – to support it. So why are proxies being positioned as a network security tool?

I have heard many reasons throughout the years why proxies are better than traditional packet-based firewalls. But the reality is that proxies have never dominated the security market, and proxy companies have generally not done very well. This includes TIS, which ended up being McAfee’s firewall, then got sold to Secure Computing, but is now returning back to McAfee (yes, my head is spinning just reading it). This also includes Secure Computing’s Sidewinder, Raptor (which was killed by Symantec), and other minor, irrelevant players you probably have not heard about.

At one point, TIS excused its proxy’s limited market acceptance by saying Check Point had a better GUI and was easier to manage. I have a different perspective: Proxies have failed because they are hard to use and not because they are hard to manage. Putting a proxy on the network puts unnecessary restrictions on the business, as to what the Internet can be used for. With a proxy, the business is limited to using only the applications that the proxy supports. Consequently, a proxy limits the business instead of enabling it!

Anyway, back to the arguments of why proxies are supposedly better than packet-based firewalls. All these arguments are centered on a single point – proxies are better than packet filtering firewalls because they are more secure. The evidence for this claim ranges from borderline ridiculous (such as that terminating a TCP connection and opening a new one while merely copying the data makes the connection more secure) to the more reasonable arguments (proxies perform protocol validation which can prevent some exploits against servers). This last argument is pretty much the only reasonable argument I have heard about why proxies are better than packet-based firewalls. Of course, all modern Intrusion Prevention Systems do the same without the drawbacks of a proxy thus rendering the need for a proxy questionable.

With all that said how come McAfee paid so much money for a proxy? And why is BlueCoat still selling a lot of their proxies? The answer IMHO (well, scrap the H) is that enterprises are facing a new security challenge that traditional packet-based firewalls cannot address. I have previously talked about this need in my blog – the need to control users and applications. Proxies can provide 20% of the solution, but that means 80% of applications cannot be controlled by a proxy (again, this places restrictions on the ability of a business to leverage the Internet). Even worse, there are also proxy-bypass applications out there that will run everything through a proxy. But even with these limitations, there are still some customers that continue using proxies because they feel an urgent need to control users and applications.

However, I am seeing a trend of enterprises trying to find a better solution for controlling applications than a proxy. Even BlueCoat recognizes this and is now moving from security towards application acceleration. This trend is a result of two things – awareness of how proxies can’t really control applications (proxy bypass programs, non port-80 applications, etc) and more importantly, more and more applications cannot work through a proxy. In the end, all of this exacerbates the need for a security solution that is genuinely effectively in controlling all users and applications.

Nir.

There is a slightly more subtle implication, but to me a far more important one. Google and the likes of Google are establishing a direct relationship with the enterprise end user, bypassing the traditional IT-department controls over which applications are used and who can use them. The IT department only needs to provide the pipes. Google will take care of the rest. And speaking of pipes – that DS3 link you have isn’t big enough. It needs to be upgraded – quickly! Google needs you to have more bandwidth. With everything coming in on ports 80 and 443 to the browser, QoS doesn’t work. So, more bandwidth please.

The migration of applications from the enterprise data center to Google and Salesforce.com, accompanied by the corresponding shift of information from the data center to the Internet is slowly changing the IT department’s role. It also changes the security risks that need to be resolved. When users have the ability to choose the applications they use, when data resides outside the corporate network, and when everyone can use any application and access data wherever they are in the world – we are dealing with a completely different beast than we are used to!

So, what can the IT department do about it? First they need to go through the five stages of grief –

1) Denial (our users are using these applications? Nah!);
2) Anger (our users are using these applications? WTF!);
3) Bargaining (hey, if you stop using these applications we will upgrade your computer);
4) Depression (I can’t believe our users are using these applicationsL);
5) Acceptance (fine, are users really using these applications – let’s deal with it).

At that point, just deal with it. Put controls in place to allow you to determine who can use which application and put security measures in place to protect the use of these applications. How to do it? Sorry. I cannot promote my company’s products in my blog so I cannot answer this question…

Nir.

So I am asking myself, how come we are still spending so much money – estimated to be $5B/year – on 15 years old firewalls? What makes us avoid innovative technologies? And why is it that we do not demand innovation from our firewall vendors?

Actually, these questions are somewhat easy to answer. Why are we still buying firewalls? Because everybody knows they need a firewall and there is no better alternative – or is there? Why are we avoiding innovative technologies? Because we are tired of the appliance fatigue caused by the number of appliances we need to buy, install, manage and support to achieve our network security goals. And why aren’t we demanding more innovation from our firewall vendors? Because we know they cannot innovate -they are big and slow and they haven’t read the Innovator Dilemma. Which basically means that they believe that if they pump R&D money into innovating their stock price will be punished…

So what do we do? As we all need firewalls and none of us want to purchase additional security appliances, my conclusion is; network security innovation must be in the firewall. And the Innovator Dilemma leads to me conclude that a new firewall will come from small and innovative companies. Not from our existing firewall vendors…

More on that later…

Nir.