Outside our posts on ROI and ALE, nothing has prompted as much impassioned debate as Web Application Firewalls (WAFs). Every time someone on the Securosis team writes about Web App Firewalls, we create a mini firestorm. The catcalls come from all sides: “WAFs Suck”, “WAFs are useless”, and “WAFs are just a compliance checkbox product.” Usually this feedback comes from pen testers who easily navigate around the WAF during their engagements. The people we poll who manage WAFs – both employees and third party service providers – acknowledge the difficulty of managing WAF rules and the challenges of working closely with application developers. But at the same time, we constantly engage with dozens of companies dedicated to leveraging WAFs to protect applications. These folks get how WAFs impact their overall application security approach, and are looking for more value from their investment by optimizing their WAFs to reduce application compromises and risks to their systems.

A research series on Web Application Firewalls has been near the top of our research calendar for almost three years now. Every time we started the research, we found a fractured market solving a limited set of customer use cases, and our conversations with many security practitioners brought up strong arguments, both for and against the technology. WAFs have been available for many years and are widely deployed, but their capability to detect threats varies widely, along with customer satisfaction.

Rather than our typical “Understanding and Selecting” approach research papers, which are designed to educate customers on emerging technologies, we will focus this series on how to effectively use WAF. So we are kicking off a new series on Web Application Firewalls, called “Pragmatic WAF Management.”

Our goal is to provide guidance on use of Web Application Firewalls. What you need to do in order to make WAFs effective for countering web-borne threats, and how a WAF helps mitigate application vulnerabilities. This series will dig into the reasons for the wide disparity in opinions on the usefulness of these platforms. This debate really frames WAF management issues – sometimes disappointment with WAF due to the quality of one specific vendor’s platform, but far more often the problems are due to mismanagement of the product.

So let’s get going, delve into WAF management, and document what’s required to get the most for your WAF.

Defining WAF

Before we go any farther, let’s make sure everyone is on the same page for what we are describing. We define Web Application Firewalls as follows:

A Web Application Firewall (WAF) monitors requests to, and responses from, web based applications or services. Rather than general network or system activity, a WAF focuses on application-specific communications and protocols – such as HTTP, XML, and SOAP. WAFs look for threats to application – such as injection attacks and malicious inputs, tampering with protocol or session data, business logic attacks, or scraping information from the site. All WAFs can be configured purely to monitor activity, but most are used to block malicious requests before they reach the application; sometimes they are even used to return altered results to the requestor.

WAF is essentially a peer of the application, augmenting its behavior and providing security when and where the application cannot.

Why Buy

For the last three years WAFs have been selling at a brisk pace. Why? Three words: Get. Compliant. Fast. The Payment Card Industry’s Data Security Standard (PCI-DSS) prescribes WAF as an appropriate protection for applications that process credit card data. The standard offers a couple options: build security into your application, or protecting it with a WAF. The validation requirements for WAF deployments are far less rigorous than for secure code development, so most companies opt for WAFs. Plug it in and get your stamp. WAF has simply been the fastest and most cost-effective way to satisfy the PCI-DSS standard.

The reasons WAFs existed in the first place, and these days the second most common reason customers purchase them, is that Intrusion Detection Systems (IDS) and general-purpose network firewalls are ineffective for application security. They are both poorly suited to protecting the application layer. In order to detect application misuse and fraud, a device must understand the dialogue between the application and the end user. WAFs were designed to fill this need, and they ‘speak’ application protocols so they can identify when an application is under attack.

But our research shows a change over the last year: more and more firms want to get more value out of their WAF investment. The fundamental change is motivated by companies which need to reign in the costs of securing legacy applications under continuing budget pressure. These large enterprises have hundreds or thousands of applications, built before anyone considered ‘hacking’ a threat. You know, those legacy applications that really don’t have any business being on the Internet, but are now “business critical” and exposed to every attackers on the net. The cost to retroactively address these applications’ exposures within the applications themselves are often greater than the worth of the applications, and the time to fix them is measured in years – or even decades. Deep code-level fixes are not an option – so once again WAFs are seen as a simpler, faster, and cheaper way to bolt security on rather than patching all the old stuff.

This is why firms which originally deployed WAFs to “Get compliant fast!” are now trying to make their WAFs “Secure legacy apps for less!”

Series Outline

We plan 5 more posts, broken up as follows:

• The Trouble with WAFs: First we will address the perceived effectiveness of WAF solutions head-on. We will talk about why security professionals and application developers are suspicious of WAFs today, and the history behind those perceptions. We will discuss the “compliance mindset” that drove early WAF implementations, and how compliance buyers can leverage their investment to protect web applications from general threats. We will address the missed promises of heuristics, and close with a discussion of how companies which want to “build security in” (the long term goal) need to balance the efficiency of fixing problems within the development cycle against the need to quickly respond to immediate threats to production Web applications.
• The WAF Management Process: To provide a framework for solving the problems identified in this post, we will present a high-level process map for pragmatically managing the WAF environment. It will start with steps to manage policies, highlight integration points with the existing application development lifecycle, and finally address securing the WAF.
• Policy Management: Despite many companies’ hopes, WAF is not a “set and forget” tool – instead it’s a security platform which requires adjustment to new and evolving threats. In order to block threats, keep unwanted requests and malware from hitting your applications, and virtually patch known vulnerabilities in the application stack, WAFs must be regularly tuned. We will discuss how those responsible for WAF management need to work with security to understand common application threats, and what catalysts or events should prompt you to update policies. We will discuss the need to periodically check with the WAF vendor for new policies and capabilities, as well as with CERT/Mitre and other sources for new vulnerability data, and the need to continually revisit the ‘negative’ security model (blocking the bad). We’ll discuss the good, the bad, and the ugly aspects of heuristics for managing policy sets. Finally, we will cover the need to periodically deprecate policies, re-examine deployment options (in-line, bridge, plug-in, out-of-band) and acknowledge that different applications dictate different deployment models.
• Application Lifecycle Integration: Keeping WAF rule sets current in the face of web application development cycles which push new code weekly – if not daily – can present the biggest difficulty in WAF management. While most WAFs leverage a ‘positive’ security model (block everything which is not explicitly authorized) that does not mean the application activity is static. URLs and features change, and new capabilities are added constantly – all of which inherently impact the WAF ruleset. We will discuss how the WAF management process must be both cognizant of and integrated into the application development methodology to understand what new functions are on the horizon, when new releases will be pushed live, how best to engage with development teams, and how to test rules prior to production release.
• Securing the WAF: Like most applications, WAFs themselves are subject to manipulation, attacks, and evasion. We will examine how a WAF presents targets of opportunity to attackers and look at the more esoteric aspects of WAF security, including SSL interception, data leakage, and evasion techniques employed by attackers. We will also discuss the benefits of different deployment models and how they affect security and scalability, as well as cloud and hybrid services, to help you understand the requirements for protecting the WAF. We will talk about how pen testing the WAF, in conjunction with your applications, reveals deficiencies in WAF deployments and increases the security of any organization. Finally, we will review ways to automate WAF management and make your job easier.

Next up: The trouble with WAFs, coming tomorrow afternoon.