The Evolving Firewall: WAFs Look at Applications, Not Ports

Carl Weinschenk

Network firewalls are focusing more on applications than the ports that they are using. To use a moat analogy, attention is shifting from the bridges over the rivers of burning oil and focusing instead on the nature of the men and beasts attempting to cross them. Today, eWeek reports on the introduction of PAN-OS 2.0 from Palo Alto Networks. The new product, the story says, can scan on many criteria, including risk level and the nature of the networking protocol being used. The point, according to a Palo Alto Networks' executive, is that the landscape has shifted from the point a few years ago when knowing what port an application was using was enough. Today, it's vital to dig deeper to gain the intelligence necessary to quell and danger.

 

The change that Palo Alto is addressing was alluded to in an IT Business Edge interview two weeks ago with Jim Reavis, principal of Reavis Consulting Group and keeper of the blog Risk Bloggers. Said Reavis:

I think we're figuring out a little more about what the pain points are right now than the solutions. If you go back 16 years to when I started, fundamentally the firewall hasn't changed. It uses ports and IP addresses, but a port doesn't mean an application like it used to. An IP address is no longer a user or a location.

In this post, Ivan Ristic introduces a series he intends to offer on Web application firewalls (WAFs). He first offers a brief explanation of why he is writing the series. The list of posts he plans serves as a good introduction to the important elements of a WAF. Ristic breaks the issues into six categories: Use cases; deployment models; data models; analysis models; traffic logging and special protection techniques.

 

The interest being generated by WAFs is apparent in this white paper from Verizon Business' ICSA. Though the paper deals with a number of security technologies, the focus is on WAFs. The writer says that, as their name implies, WAFs deal with HTTP and HTTPS. They are hardware- or software-based and most include protocol enforcement and negative signature detection.

 

The piece provides a detailed listing of the ways in which WAFs offer protection. Among other points, WAFs ride herd over Web-based elements and functions such as Web objects, form field and application session logic. The last of these is the most important, the writer says, and it is described in a bit more detail. The piece also offers a chart that looks at four types of security: protocol-enforcing network firewalls, intrusion prevention systems, content filtering gateways and WAFs. The chart assesses their primary purpose, primary mechanism of operation, scope and application enhanced functionality.

 


WAFs are not panaceas. This post says that a recent clarification to the PCI certification process makes it appear that installing a WAF satisfies requirement for protecting Web-facing applications against known attacks. The vehemence of the reaction of the blogger -- Nate McFeters, a senior security advistor for Ernst & Young's Advanced Security Center in Chicago -- is interesting. McFeters says that WAFs "struggle" against cross-site scripting and SQL injection, which are the most common Web-based attacks. He then lists nine known attacks against which he says that WAFs offer no protection. The 10th item in his list simply is "etc."

 

The point McFeters is making is one that is important for the WAF category overall: This is a valuable approach, but one that is young and clearly in its formulative stages.



Add Comment      Leave a comment on this blog post
Apr 30, 2008 3:33 AM Ivan Ristic Ivan Ristic  says:
Your readers might also be interested in the Web Application Firewall Evaluation Criteria (WAFEC) project, at http://www.webappsec.org/projects/wafec/, which offers detailed guidance to help evaluate WAFs. ICSA also have their WAF criteria (http://www.icsa.net/icsa/docs/html/communities/Wafcriteria.pdf), which they use to certify WAFs.Regarding Nate's comments: as with any other technology, it is important to understand what WAFs can and cannot do. People are not deploying tools and using techniques for the things they cannot do. Quite the opposite, they are using them for what they CAN do. I would argue that many things on Nate's list are not meant to be protected from by web application firewalls. Take business logic faults, for example. Would anyone argue that static code analysis tools need to find such problems in code? Of course not. But similar arguments are frequently made for web application firewalls.I only care that people know enough about web application firewalls to allow them to make educated decisions about using them. Reply
Jul 29, 2008 12:26 PM Nate McFeters Nate McFeters  says:
Ah but if only I weren't so young in the blogosphere, I might have known of this post much earlier. To Ivan's comments on my comments:Ivan says, "I would argue that many things on Nates list are not meant to be protected from by web application firewalls. Take business logic faults, for example. Would anyone argue that static code analysis tools need to find such problems in code? Of course not."Ivan, you won't find me arguing in the pro for static code analysis tools. Of course they won't find business logic flaws, and that is the biggest problem. When the PCI standard suggests that the use of a WAF is sufficient, it provides the wrong message, suggesting that all issues are solved by a WAF. They are not.Ivan says, "I only care that people know enough about web application firewalls to allow them to make educated decisions about using them."I completely agree Ivan; however, I think where you educate people on the how useful they can be, I choose to educate on how little they can truly provide. Until the PCI standard makes it explicitly clear that more detailed assessments are required, and that a WAF alone is not a feasible solution, I will continue to educate on what WAFs cannot do.This is despite the fact that I do believe in time they can become part of a good defense in depth program.-Nate Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.