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.
Centralized 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)
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.