Consortium hopes to lift Web application firewall confusion
By
Tim Greene
,
NetworkWorld.com
, 01/13/2006
- Share/Email
- Tweet This
- Print
Web application firewall is a simple term, but understanding what it means is proving so difficult for customers that an industry
consortium is publishing advice on how to make a choice among the many devices that fall into this category.
On Monday, a 20-page document called Web Application Firewall Evaluation Criteria is being published by the Web Application Security Consortium, a group formed a year ago from vendors, consultants and end
users. The document will be available here.
Broadly, Web application firewalls examine HTTP and HTTPS traffic at the application layer, looking for attacks masquerading
as legitimate application traffic. They defend against attempts to tap sensitive information stored on Web application servers,
such as credit card and social security numbers as well as proprietary corporate information.
There are such a wealth and variety of methods for accomplishing this goal that it is difficult for potential customers to
figure out what product best suits their needs, says Mark Kraynak, director of product marketing for WAF vendor Imperva who
served on the Web Application Security Consortium committee that wrote the document. Other vendors include Citrix, F5 Networks,
NetContinuum and Protegrity among others.
"There's too much functionality and only one name for the products," says Kraynak. "A lot of our customers don't know what
criteria they should be evaluating. There's confusion."
No single WAF device is appropriate for all networks, says Ivan Ristic, who headed the evaluation effort for the consortium.
He also runs Thinking Stone, a Web application security consulting firm. "You need to look at your security requirements and
business goals. Create a short list of features you need, and use that to sort products."
For example, a business that needs to document all HTTP transactions for regulatory purposes may need a WAF with very few
features, Ristic says. Or a business with a single Web server might need no separate WAF, but only application firewall software
that can run on the server itself, he says.
The range of features is broad. A WAF can deal with SSL traffic, for example, by terminating it, examining it and passing
it on or capturing it and decrypting it but not terminating sessions. Similarly, if the WAF needs to block traffic, it can
terminate network-protocol connections and not pass on malicious traffic or it can sever suspicious connections altogether.
Also, individual products can support more or fewer versions of HTTP, encryption and authentication. These devices may or
may not support filtering of outgoing traffic as well.
"It's not like every Web application firewall needs all these features," Ristic says.
"Three years ago, there wasn't anything like this (evaluation criteria)," says a senior network executive at a mid-West financial
services firm that uses Citrix gear. The firm would not allow its name to be used in this story. "We had to hire a third party
to do attack and penetration testing for us."
Comment