In my last column, I introduced the Web application firewall and recommended that it’s time to consider adding this measure to your Web security portfolio. (See It's Time to Consider a Web App Firewall.)
In this column, I’ve prepared a checklist you can use to inquire about prospective Web application firewall (WAF) products. Since a list is just a list, I’ll try to explain why the questions I’ve chosen are important and what homework you may need to do to prepare an RFP or review a vendor proposal as well.
The Web Application Security Consortium ’s "Firewall Evaluation Criteria" provides an exhaustive list of requirements that your organization can use as the basis for evaluation. While I encourage you to review this and any other criteria you might find, these are the areas I think are important for most organizations to consider:
1. Deployment. How the inclusion of Web application firewalls affects other systems and software in your Web and network topology is critical. A poor choice can add complexity, adversely affect performance, limit functionality, or impose frustrating constraints. WAFs can be deployed using software or hardware, so when considering software solutions, check that the product is supported on the OS and hardware you use in your shop.
Similarly, when considering hardware, confirm that the appliance supports the mode of operation you’ll require to incorporate the system into your topology (e.g., bridged, routed, proxy). Ask how SSL traffic is processed. Understanding whether the WAF terminates SSL connections, passively decrypts traffic, or takes no action will help you scope the amount of change the WAF will impose on your existing environment. Confirm that the WAF supports any authentication methods you employ to validate users or customers.
2. Connection handling. WAFs differ in the way they block traffic; for example, some reset TCP connections, others drop traffic, and still others strip objectionable content. Some combine these techniques. Do some homework to decide which of these modes works best for your organization.
3. Traffic processing. Every Website is supported by a unique combination of applications, protocols, data, and dynamic content. Check that the WAF can inspect all the meta-languages, encoding types, and non-HTTP application traffic you publish from your Website (or accept as submitted data). Check that the WAF blocks protocols, URLs, and cookies that do not strictly conform to standards. Many WAFs are able to enforce validation policies at the object or parameter level. Ask what degree of policy granularity the WAF provides and whether policies can be enforced based on user, origin IP address, time of day, and so on.
4. Detection techniques. WAFs differ in the ways they detect and block the many kinds of evasion or obfuscation techniques that attackers use to slip past security measures, and they often use signatures as the bases for blocking known attack traffic patterns. Ask for a description of the vendor’s normalization techniques and signature database; ask how the database is updated, and whether an API is available to customize or extend the vendor’s detection functionality.
5. Protection techniques. Websites may be vulnerable to a wide range of threats and attacks, and vendors often include specific countermeasures to mitigate certain classes of attack. Ask about measures the WAF provides to protect against or mitigate cookie-based attacks, brute-force attacks, session or denial-of-service attacks, or any other specific countermeasures and mitigation techniques the product supports.
And don't forget to check for the essentials and basics: logging and reporting (local/remote, formats supported), event notification and delivery method, high availability, secure administration. And of course, consider vendor reputation and quality of technical support, complexity and suitability of administration tools, performance, scalability, initial cost, and recurring subscription costs.