Introduction

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. 

InLineGraphic.JPG

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.

SpanGraphic.JPG

 

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.