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.
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.
Installation concerns
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."