How to Choose the Right Web Application Firewall (WAF)

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  


Web Application Firewalls (WAFs) entered the IT security scene about 10 years ago with offerings from start-up companies Perfecto (renamed Sanctum before being acquired by WatchFire in 2004), KaVaDo (acquired by Protegrity in 2005), and NetContinuum (acquired by Barracuda in 2007). The premise was fairly simple: as attacks moved up the IP stack to target application-specific exposures, a need was born to build products that were designed to identify and prevent those attacks. Network firewalls were effective at stopping lower layer attacks, but were not adept at unwinding IP packet layers to analyze higher level protocols; this meant they didn’t have the application awareness required to close vulnerability windows in custom Web applications.

But while the hype and promise of WAFs was high, the experience of end-users was fairly low. Early offerings suffered from high false-positive rates, negative performance impacts on protected applications, and were difficult to manage effectively. In the middle of the decade, larger network-oriented players, including Cisco, Citrix, and F5, acquired or developed Web layer monitoring and WAFs became an accepted layer of perimeter security. Another factor driving WAFs to mainstream adoption status was the introduction of the PCI-DSS, which explicitly called out application-layer-aware firewalls in requirement 6.6 of the standard.

Today, WAFs are an accepted part of the IT security toolbox.  But many enterprises still struggle with the question of which kind of WAF to purchase and how best to integrate them into their Web application risk management portfolio. In this guide, we take a look at some of the major decision factors surrounding a WAF purchase and offer advice on how to ensure they work well within the corporate architecture and network ecosystem.

Architecture and Form Factor

WAFs should fit in with existing architecture and run on a form factor that is accepted and supported by the security operations team.  There are two main architectural considerations related to WAF placement: In-line or tap/span.

·     In-line: In this architecture, also known as an active configuration, the WAF is placed directly in the traffic path between the requestor (for example, a browser client) and the Web application server. The WAF inspects application requests and responses before passing them on.

Within the in-line model, there are a number of choices an organization can make about the specific method the WAF will use to pass traffic. Network options are: router (layer 3), bridge (layer 2) and HTTP reverse-proxy. WAFs can also run directly on the host server where the Web application resides, these are known as host-based or embedded WAFs. Using a WAF in bridge mode probably won’t require network changes, but traffic will have to be directed to a WAF in router or reverse-proxy mode.

To select the best mode, start by reviewing how the Web application is currently set up on the network: is it behind a reverse-proxy already? If so, and the organization wants to continue using the reverse-proxy architecture, look to WAFs that can support that. If the organization requires that the WAF terminate SSL connections to examine the packet content, reverse-proxy is an ideal choice. Terminating a connection (whether SSL or not) before sending it along the path does take processing power though, so this mode needs to be sized and tested to ensure unacceptable latency is not introduced.

In-line WAFs can be configured to actively block requests and traffic that violate the WAF rule-sets. This is a useful feature, but needs to be used judiciously – an in-line WAF that is in over-active blocking mode prevents legitimate traffic from reaching the Web server, making the application unusable. Before setting up any active blocking rules, test them exhaustively to ensure no service interruption surprises happen in production. Alternately, it is possible to run a WAF in-line, but keep it in a monitor-only (or passive) mode.

Another architectural consideration is how many WAFs will be installed and managed. If multiple instances of a WAF are required, consider a solution that supports distributed management or dWAF. In this model, multiple instantiations of the firewall can be managed using a central console. Blanket rules or settings can be applied across all WAFs and individual rule-sets can be applied on a WAF-by-WAF basis depending on which Web application the WAF is protecting. 


Figure 1: Pros and Cons of In-line WAFs

·     Tap/span: This mode is also known as “passive” because the WAF is kept out of the traffic path and monitors traffic from a tap or span port. Tap/span WAFs are often used to collect data for use later in investigatory or forensic analysis. A major benefit of this architectural mode is that it does not interfere with network traffic or throughput because it is not directly in-line. On the other hand, being out-of-line means that these solutions cannot perform the kind of blocking that an active, in-line WAF can. However, some forms of blocking are supported, for example connection resets or by communicating to another system (like a network firewall) and having that system perform the blocking.



Figure 2: Pros and Cons of Tap/Span WAFs

·     Emerging: Two important changes are driving the need for new architectural models in WAFs, these are cloud and virtualization. Cloud-based WAFs intercept traffic before it enters the organization’s network or, for companies that have their Web application in the cloud as well, before it hits the server through the cloud. Virtualized environments present a unique challenge because the VMs running on top of a hypervisor form their own mini-network where traffic is passed from server to server without having to traverse the network. To prevent application attacks intra-VM, a WAF needs to be able to see the traffic. This can be accomplished by using an API or other service to monitor activity via the hypervisor.


·     Form factor: Addresses the question of how the WAF is bundled and sold to the customer. Many WAFs support multiple options, so there should be no need for an organization to go out of policy to buy an appliance if only ISV software is approved. In other words, the form-factor choice depends on what your organization is most comfortable with. The choices are:


o  Software only – with the purchasing organization supplying the hardware

o  Appliance – software is sold on an appliance that has been sized and tuned specifically for the WAF

o  Hardware – WAF intelligence is embedded directly into the hardware itself

o  Host – this is a software option, but the software is installed on the same server that the Web application is running on rather than on a separate box or VM.

Detection Techniques

With the architecture and form factor questions addressed, it’s time to ask: How does the WAF detect vulnerabilities in - and attacks on - the Web application? The purpose of the WAF is to intelligently protect the Web applications, so having granular rules and detection matters. Most WAFs use a blended approach of different techniques to ensure the most accurate detection coverage. In addition to asking the vendor which techniques are in use, ask the vendor to supply proof of false positive/negative rates and any third-party testing results to get a clearer picture of how well the WAF will perform in practice. These techniques (and some questions to ask your short list of product vendors) are:

·     Signatures:  Similar to the signatures built for anti-malware and network intrusion detection systems, WAF signatures match a pre-set string or regular expression (RegEx) to the traffic looking for known attacks.

Does the product ship with a set of signatures?

How often are the signatures updated by the vendor?

·     Rules: Taking the signature concept a step farther, rules can link to together a series of strings with the logical AND operator, add more complex matching using the OR operator, or implement “exclusion” functionality using the NOT operator. Rules can also be set to look for very specific types of strings, like a 16-digit number (for example a credit card number) being sent as a response from the Web server. Some WAFs can dynamically “learn” traffic patterns and look for anomalous behavior based on a set of baseline rules. The “learned” information can be sent to admins as a suggestion for a new rule setting for the WAF or a complimentary protection device like an IDS or network firewall.

Are baseline rules provided by the vendor?

Can the customer add new rules manually?

Is the WAF able to “learn” new rules dynamically?

•    Normalization : A favorite approach of attackers is to evade WAF detection by manipulating an exploit payload to appear as something harmless (for example by URL-encoding portions of the payload).  In order to detect the attacks, the WAF needs to be able to normalize the requests in order to perform its analysis.  A short list of normalizations is below – for a complete list please refer to Section 3.1 in The Web Application Security Consortium’s Web Application Firewall Evaluation Criteria.

Can the WAF normalize escaped or encoded characters (e.g. t, �01, %2C, xAA, uAABB)?

Self-referencing paths (i.e. use of /./ and encoded equivalents)?

Mixed-cases and international character sets?

•    APIs: If an organization wants to build its own custom detection techniques or rules for specialized assessments, such as logic checks, one way to implement this is via APIs. Check with vendors to see if they do have API support and if so, how closely these APIs are integrated with the WAF parsing engine.

    Does the WAF have an API?

   How tightly does the API integrate with the WAF engine?

   What kind of support does the vendor supply for custom plugins?

Other Considerations

•    High availability and Throughput: If the WAF is in a high-traffic environment, it should have the ability to process a significant amount of traffic without slowing down the Web application, especially if it’s in-line. If one WAF or Web application fails or red-lines with usage, the WAF has to support failover and work with load balancers to prevent disruption of service. Some WAFs are tightly integrated with HA devices and run as components of a Web traffic management system. For stand-alone WAFs make sure they meet the company’s HA needs for both performance and architectural conformance.

Can the WAF work with existing HA/load balancing devices?

Does the WAF support failover with no (or limited) loss of traffic?

How much traffic can the WAF support?

Is any latency seen on the performance of the protected application?

Does performance decrease when new/complex rules are added?

•    Logging and Reporting: As the monitor and sentry of the Web application, the WAF is uniquely positioned to log traffic and activity. Some WAFs do a full packet capture of the entire traffic stream (most commonly in tap/span solutions), but all should be logging critical information about the transaction activity to and from the Web application.

Does the WAF keep a full transaction log?

What format does the log use (ex: syslog)?

Is the log stored in a tamper-proof/tamper-evident way on the server?

Can the log be exported off the server in a secure manner?

Does the product come with pre-configured reports for compliance and management?

•    Management of multiple instantiations (dWAF): If the WAF is going to be deployed in a complex, distributed environment, the ability to centralize management will greatly reduce administrative overhead.

Does the WAF work in a multi-use dWAF environment?

Can policies be applied to all WAFs?

Are custom policies supported for individual applications?

•    SSL and Encryption: Encryption protects data in the traffic stream from prying eyes, but it also means that a WAF can’t inspect the data without decrypting it first. The options here are to give the keys to the WAF so the stream and can decrypted or to terminate the SSL connection at the WAF and then, optionally, create a new encrypted tunnel for data transfer from the WAF to the Web server/browser. SSL processing introduces CPU overhead, so size WAFs that are terminating SSL sessions carefully and consider using accelerator boards to off-load some of the processing work.

Does the WAF support SSL decryption?

Is in-line termination supported?

Key sharing for passive decryption?

Are there acceleration options, such as crypto-accelerator boards?

•    Emerging protocols: Normalizing and re-assembling HTTP and HTML is tricky, but in Web 2.0 and beyond there are many emerging protocols and existing media types that can introduce malware or exploits. No WAF is able to parse .swf (Flash) for all exploits, but there should at least be support for image inspection and scripts like Jscript and PHP.

Can the WAF handle dHTML, CSS, XML, and SOAP?

Can the WAF support scanning of Flash? Images (JPG, GIF, PNG)?

•    Integration with Web app scanners: Web application scanners are products that automatically scan a Web application from the outside to emulate the kind of exposures that an attacker could discover. Scanners are complimentary to WAFs because they can discover exposures that admins can mitigate with custom WAF rules. Some Web app scanner and WAF companies have partnered so that the scanner can automatically suggest a customer rule, in the correct WAF syntax, when exposures are discovered during the scan process. This helps to compensate for the exposure quickly and eliminates the administrative overhead of trying to craft the best rule to prevent the attack.

Does the vendor have partnerships with any Web App Scanners?

How tight is the integration between the products?

Can rules be updated automatically or is manual intervention required?


The above questions and considerations are a strong baseline for considerations when buying a WAF product. For additional details and considerations, please take a look at the Web Application Security Consortium’s WAFEC Evaluation Response Matrix . Using the points outlined above and the additional detail in the matrix as a baseline, write out requirements and define essential feature sets before submitting an RFP to vendors for completion. Though the WAF market isn’t as crowded as some others, doing the RFP work up-front will narrow down the products significantly and help to ensure that the organization gets the right tool for the job.

Diana Kelley is a partner at SecurityCurve and frequent contributor to


Loading Comments...