Having a Web application firewall in place can mean the difference between scrambling to fix a vulnerability --...
taking an application offline and paying emergency overtime fees for developers and QA staff -- or having the breathing room to repair the vulnerability on your own schedule.
That's a tangible return on investment, said Mark Kraynak, director of product marketing at Imperva Inc. in Foster City, Calif., and contributor to the recently released Web Application Firewall Evaluation Criteria (WAFEC) from the Web Application Security Consortium (WASC).
Web application firewalls (WAFs) are an emerging category of firewall, defined by the consortium as "an intermediary device, sitting between a Web client and a Web server, analyzing OSI (Open Systems Interconncection) Layer 7 messages for violations in the programmed security policy. A Web application firewall is used as a security device protecting the Web server from attack."
The goal of the WAFEC project is to help organizations evaluate WAFs, said project leader Ivan Ristic, founder of Web application security company Thinking Stone Ltd. in London. The project group, which is made up of WAF vendors, security professionals and WAF users, spent most of 2005 debating the various requirements. The result was version 1.0 of the WAFEC document.
According to the consortium, a WAF does not require modification of source code. A WAF can use a proxy-based architecture, a deep packet inspection-based architecture -- or both. The WAFEC does not specify an architecture.
The intent, said Jeremiah Grossman, a project contributor and founder and chief technology officer of WhiteHat Security in Santa Clara, Calif., is not to recommend certain features, but rather to "give someone a way to compare one firewall to another." The document is also not meant to imply that all the criteria listed are must-haves. Organizations can use the criteria to form their own shorter lists, depending on their requirements. "You can't implement all the things in the document," Ristic said. "A lot the requirements are in way contradictory," meaning, he said, they are either/or decisions.
Categories covered in the document include deployment architecture, HTTP and HTML support, detection techniques, protection techniques, logging, reporting, management, performance and XML.
WAFs target the application layer, not the network
WAFs address different issues than network firewalls, which defend the perimeter of a network, Kraynak said. "A standard network firewall is not parsing cookies. It doesn't understand the parameters of a URL -- it was built for a different problem."
Ristic stressed the importance of a layered security model -- having different security controls at different layers. "With a Web application firewall in place, you can observe, monitor and look for signs of intrusion. If you don't have a Web application firewall in front of the application, you don't know what's happening and you're not in control," he said.
Still, Ristic said a WAF is not a panacea. "Applications need to be secure to start with, which is difficult to do. Web applications will never be 100% secure. You have to have a strategy and practice a layered defense."
Grossman added: "We've had network firewalls for many years, and nobody claims they stop everything. The same is true for Web application firewalls. You won't be able to block all vulnerabilities. You still have to be diligent."
WAFs haven't taken hold
Boston-based Yankee Group has labeled the WAF market "mature" but says it has not really gained traction. In 2005, the WAF market was $40 million, growing at 10%. In comparison, the overall security market has grown at a 20% to 30% pace during the past five years, according to Yankee Group.
Yankee Group predicts that the WAF market as it exists today will be subsumed in a few years by a larger market: application assurance platforms, which will combine WAFs, database security, XML security gateways and application traffic management segments.
For organizations debating whether they need a WAF today, Cambridge, Mass-based Forrester Group has three recommendations:
- Calculate the value of assets that need protecting and the expected cost of a breach.
- Get evaluation copies of products and deploy them in a test environment.
- Put on your shortlist only products that meet/exceed current and medium-term requirements.
Dig Deeper on Building security into the SDLC (Software development life cycle)