Web application firewalls have overcome some of their early performance issues, and they may get a boost from the recently updated Payment Card Industry (PCI) Data Security Standard, which recommends them as one of two "best practices" for protecting Web-facing applications from attacks. But Burton Group analyst Diana Kelley cautions that Web application firewalls are not "fire and forget solutions," and organisations should weigh potential security risk against performance latency and the time required for tuning them.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In her recent report -- Web Application Firewalls Are Dead! Long Live Web Application Firewall Functionality -- Kelley, vice president and service director at Midvale, Utah-based Burton Group, says that in addition to improving performance, Web application firewalls have moved beyond the domain of niche start-up vendors.
Kelley identifies two major categories in her report: "network savvy" products from optimisation platform vendors such as Citrix Systems in Fort Lauderdale, Fla., and F5 Networks Inc. in Seattle and network perimeter vendors such as Check Point Software Technologies. She also notes application- and database-aware hybrids that protect the Web application and the database. Vendors in this category include Protegrity Corp. in Stamford, Conn., and Imperva Inc. in Foster City, Calif. A future direction, according to the report, is convergence with XML security gateways.
Kelley also says the "classic" Web application firewall vendors, such as Breach Security Inc. in Carlsbad, Calif., and NetContinuum Inc. in Santa Clara, Calif., have made their standalone offerings more robust.
While the market has matured, the decision to install a Web application firewall still isn't an easy one for organisations. "When doing research for that report, a lot of companies were still questioning: Do I need it, and if so what's the most effective way to deploy it? It's not a solution that every company easily says yes to. It's not like a standard network perimeter firewall," Kelley said.
Among those interviewed, Kelley said she "found some concern about how to deploy Web app firewalls most effectively." Early Web application firewalls had issues with performance and tuning, she said. "They weren't working as expected. Web apps change frequently, so a global rule may not apply. To really tune them properly, you needed extra time involved, and some companies were saying they did not want to put the time in."
But since the early products, Kelley said performance has definitely improved, and the architectures of the systems are created to be more performance-aware.
Unlike network perimeter firewalls, which Kelley said make coarse-grained decisions -- such as, is it OK for access to come in? And if so, which ports should allow it? -- Web application firewalls make finer-grained decisions based on rule sets. They also have extra intelligence and the ability to learn.
With that granularity, though, there will still be some performance latency despite the improvements. How much depends on the product and how it's configured, Kelley said.
"It's critical for companies to do testing to make sure they understand the performance hit. The more you inspect, the more rules, and the longer it will take that packet to pass through. They've got to make sure they size the solution properly so they have enough horsepower to inspect packets and still pass through in a timely manner," she explained.
How much delay is acceptable depends on what is being protected, Kelley said.
"Some applications are incapable of having latency, like phones or VoIP. If you have latency, it would cause jitter," she said. "With email or a Web site, you're used to a moderate delay. So it depends on the application, and how that application is interacting with the back-end database. Many companies that have successfully deployed Web application firewalls said the delay was minor enough that it was more than acceptable."
Needs vs. functionality required
In choosing a Web application firewall, organisations have to weigh their needs and the functionality required. She noted that the wording of the updated PCI standard, for instance, leaves that choice somewhat open. Requirement 6.6 of the standard, in using the wording "application layer firewall" indicates "a firewall with some level of awareness of what's going on in the application," but not specifically a Web application firewall with intelligence and learning, Kelley said.
For organisations that consider speed, growth and scalability most important in choosing a Web application firewall, they may want to look to the optimisation platforms, Kelley said. And for companies more interested in looking at the whole Web application, how it interacts with the database, and understanding the intelligence across the transaction stream, they may want to consider the application- and database-aware hybrids, she said.
"I don't think one or another is a better approach or will win," Kelley said. "In general, operations folks are focused on keeping it fast and secure, and auditors are more interested in tying in with intelligence and what's happening with the database."
The bottom line, though, is that installing a Web application firewall "makes sense if you're willing to spend time tuning and understanding the rules," Kelley said. While Web application firewalls may come with some default rule sets, "customers said they got the biggest bang when they understood their Web applications and how they worked."
And a final caveat: "Web application firewalls come at the end," Kelley emphasised. "Blending security into the software development life cycle is incredibly important for any Web application."