Security Experts:

How to Evaluate Web Application Firewalls

Web Application Firewalls: What Approach Should You Take To Evaluate WAF Solutions?

In my previous column, I focused on various features you should check out when choosing a Web application firewall. Together, these features help improve the accuracy of a WAF.

Once you’ve selected one or more WAFs to evaluate, it’s time to test them and decide which one is the right one for you. But how then do you evaluate a WAF?

Evaluation Criteria #1: Manageability

The first comparison test you need to perform is manageability. If the WAF is difficult to manage and doesn’t provide the policy flexibility you need, you will pay for it later. Although a plug-and-play device may be too much to ask for when you’re talking about customized applications, the initial deployment should not be too challenging. You want to know that with a minimal amount of effort you can have a WAF protecting your apps that doesn’t need to be constantly overseen and fine-tuned.

As mentioned in my previous column, readable alerts and reports are a WAF necessity – these features provide you with information on the WAF’s accuracy and present an overview of the threat landscape while identifying the problem. A complementary aspect for evaluation is the WAF’s usability. This includes a clean GUI which provides a clear dashboard of the threats, with the ability to drill down and review the details of an alert. Ideally, you should also be able generate both pre-configured and customizable reports and easily adjust security policies.

Testing Web Application FirewallsCentralized management is also helpful when you’re dealing with Web application infrastructure that is distributed across the globe. You want to be able to manage the different WAF appliances- without needing to connect to each appliance separately. This also allows organizations to build, maintain, and enforce a unified security policy across their entire organization.

Evaluation Criteria #2:

Performance Performance is key when it comes to a WAF. The deployment of a WAF should not impact the performance of existing infrastructures, including application and network devices. This means that even though the WAF acts as the security proxy to the application, the application continues to transact the data without suffering from a backlog of requests and does not collapse under heavy loads. The application should behave as though no WAF is present.

From the end user perspective, the WAF should be completely transparent. The users should not experience any noticeable delay or hindrance of service.

To avoid performance degradation, you want to make sure that the WAF’s performance matches or exceeds other elements of the application infrastructure.

Evaluation Criteria #3: Minimal false positives

False positives are a major concern. You don’t want a WAF that screams and alerts you on every incoming request. That would be the WAF equivalent of crying wolf, and when a malicious request does eventually come through, the chances it will slip by because of how you’ve loosened the reigns due to false alarms could increase substantially. This problem is exacerbated if you’re in blocking mode. The last thing you want is to block legitimate traffic, which ultimately defeats the purpose of having an online application. Make sure that the WAF you are evaluating suffers from a minimal amount of false positives – up only to handful of them.

Evaluation Criteria #4: Dealing with live attack traffic

The best way to test a WAF is using live traffic. After all, any other testing of this traffic would be synthetic, and inherently, a simulation. By evaluating a WAF in a production setting, you receive two main benefits:

- Testing whether there is any performance degradation (which links well to the previous evaluation criteria)

- Verifying that the WAF really blocks the attack. This is in particular necessary when you want to ensure that the WAF is protecting all the elements that are in the protected application, and testing the dynamic components such as Javascript and XML. In the case where the WAF learns the application – this is all together more important as such a production setting will prove whether the WAF is correctly learning the application traffic. Taking this evaluation criteria one step further, you should also make a change to the application and see that the change is detected by the WAF.

On a side – yet very important– note, a recommended suggestion is performing the complementary setup: put a WAF during application development. Such a deployment helps gather attacker intelligence that you can add to your test cases when building the software. I’ll expand on this theme at a later column.

Evaluation Criteria #5: Incorporation into existing infrastructure

The WAF should require little to no changes to existing infrastructure. This is an important aspect when you take into consideration that Web applications are finely tuned and extremely sensitive to change. Any change to the network, Web server operating system, application software, or back-end databases introduces risk to availability, performance and security. You don’t want to go poking around and breaking what already works just to fit the WAF into place.

As part of the evaluation process you need to ensure that the installation of the WAF is easily performed with zero changes to data center infrastructures. While the WAF is deployed, it should operate transparently to the network, applications and databases.

Evaluation Criteria #6: Integration with existing enterprise systems

A WAF is not an island onto itself. Any device introduced into the network should integrate with existing systems. Important integration points you should check out for are security information event management (SIEM) systems, log retention systems, identity management, incident management, application scanners and code analysis tools. Proper interaction between the WAF and these other elements provides layered and automated security.

If you follow these steps, you will be well on your way to achieving a successful WAF deployment. Good luck!

Disclosure: My employment status has not changed since the latest column- I still work for a company that offers WAFs as part of its offerings. But this also means that I’ve been researching WAFs for several years now.

Subscribe to the SecurityWeek Email Briefing
view counter
Noa is a private consultant specializing in building thought leadership teams within tech companies. She is one of SecurityWeek’s first columnists with previous columns focusing on trends in the threat landscape. Her current interest lie on the business-side of security. Noa has worked for Imperva as a Sr. Security Strategist and before that, as a Sr. Security Researcher. She holds a Masters in Computer Science (specializing in information security) from Tel-Aviv University.