How to Choose the Right Web Application Firewall (WAF): Page 2
With the architecture and form factor questions addressed, its time to ask: How does the WAF detect vulnerabilities in - and attacks on - the Web application? The purpose of the WAF is to intelligently protect the Web applications, so having granular rules and detection matters. Most WAFs use a blended approach of different techniques to ensure the most accurate detection coverage. In addition to asking the vendor which techniques are in use, ask the vendor to supply proof of false positive/negative rates and any third-party testing results to get a clearer picture of how well the WAF will perform in practice. These techniques (and some questions to ask your short list of product vendors) are:
· Signatures: Similar to the signatures built for anti-malware and network intrusion detection systems, WAF signatures match a pre-set string or regular expression (RegEx) to the traffic looking for known attacks.
Does the product ship with a set of signatures?
· Rules: Taking the signature concept a step farther, rules can link to together a series of strings with the logical AND operator, add more complex matching using the OR operator, or implement exclusion functionality using the NOT operator. Rules can also be set to look for very specific types of strings, like a 16-digit number (for example a credit card number) being sent as a response from the Web server. Some WAFs can dynamically learn traffic patterns and look for anomalous behavior based on a set of baseline rules. The learned information can be sent to admins as a suggestion for a new rule setting for the WAF or a complimentary protection device like an IDS or network firewall.
Are baseline rules provided by the vendor?
Can the customer add new rules manually?
Is the WAF able to learn new rules dynamically?
Normalization : A favorite approach of attackers is to evade WAF detection by manipulating an exploit payload to appear as something harmless (for example by URL-encoding portions of the payload). In order to detect the attacks, the WAF needs to be able to normalize the requests in order to perform its analysis. A short list of normalizations is below for a complete list please refer to Section 3.1 in The Web Application Security Consortiums Web Application Firewall Evaluation Criteria.
Can the WAF normalize escaped or encoded characters (e.g. t, �01, %2C, xAA, uAABB)?
Self-referencing paths (i.e. use of /./ and encoded equivalents)?
Mixed-cases and international character sets?
APIs: If an organization wants to build its own custom detection techniques or rules for specialized assessments, such as logic checks, one way to implement this is via APIs. Check with vendors to see if they do have API support and if so, how closely these APIs are integrated with the WAF parsing engine.
Does the WAF have an API?
How tightly does the API integrate with the WAF engine?
What kind of support does the vendor supply for custom plugins?
High availability and Throughput: If the WAF is in a high-traffic environment, it should have the ability to process a significant amount of traffic without slowing down the Web application, especially if its in-line. If one WAF or Web application fails or red-lines with usage, the WAF has to support failover and work with load balancers to prevent disruption of service. Some WAFs are tightly integrated with HA devices and run as components of a Web traffic management system. For stand-alone WAFs make sure they meet the companys HA needs for both performance and architectural conformance.
Can the WAF work with existing HA/load balancing devices?
Does the WAF support failover with no (or limited) loss of traffic?
How much traffic can the WAF support?
Is any latency seen on the performance of the protected application?
Does performance decrease when new/complex rules are added?
Logging and Reporting: As the monitor and sentry of the Web application, the WAF is uniquely positioned to log traffic and activity. Some WAFs do a full packet capture of the entire traffic stream (most commonly in tap/span solutions), but all should be logging critical information about the transaction activity to and from the Web application.
Does the WAF keep a full transaction log?
What format does the log use (ex: syslog)?
Is the log stored in a tamper-proof/tamper-evident way on the server?
Can the log be exported off the server in a secure manner?
Does the product come with pre-configured reports for compliance and management?
Management of multiple instantiations (dWAF): If the WAF is going to be deployed in a complex, distributed environment, the ability to centralize management will greatly reduce administrative overhead.
Does the WAF work in a multi-use dWAF environment?
Can policies be applied to all WAFs?
Are custom policies supported for individual applications?
SSL and Encryption: Encryption protects data in the traffic stream from prying eyes, but it also means that a WAF cant inspect the data without decrypting it first. The options here are to give the keys to the WAF so the stream and can decrypted or to terminate the SSL connection at the WAF and then, optionally, create a new encrypted tunnel for data transfer from the WAF to the Web server/browser. SSL processing introduces CPU overhead, so size WAFs that are terminating SSL sessions carefully and consider using accelerator boards to off-load some of the processing work.
Does the WAF support SSL decryption?
Is in-line termination supported?
Key sharing for passive decryption?
Are there acceleration options, such as crypto-accelerator boards?
Emerging protocols: Normalizing and re-assembling HTTP and HTML is tricky, but in Web 2.0 and beyond there are many emerging protocols and existing media types that can introduce malware or exploits. No WAF is able to parse .swf (Flash) for all exploits, but there should at least be support for image inspection and scripts like Jscript and PHP.
Can the WAF handle dHTML, CSS, XML, and SOAP?
Can the WAF support scanning of Flash? Images (JPG, GIF, PNG)?
Integration with Web app scanners: Web application scanners are products that automatically scan a Web application from the outside to emulate the kind of exposures that an attacker could discover. Scanners are complimentary to WAFs because they can discover exposures that admins can mitigate with custom WAF rules. Some Web app scanner and WAF companies have partnered so that the scanner can automatically suggest a customer rule, in the correct WAF syntax, when exposures are discovered during the scan process. This helps to compensate for the exposure quickly and eliminates the administrative overhead of trying to craft the best rule to prevent the attack.
Does the vendor have partnerships with any Web App Scanners?
How tight is the integration between the products?
Can rules be updated automatically or is manual intervention required?
The above questions and considerations are a strong baseline for considerations when buying a WAF product. For additional details and considerations, please take a look at the Web Application Security Consortiums WAFEC Evaluation Response Matrix . Using the points outlined above and the additional detail in the matrix as a baseline, write out requirements and define essential feature sets before submitting an RFP to vendors for completion. Though the WAF market isnt as crowded as some others, doing the RFP work up-front will narrow down the products significantly and help to ensure that the organization gets the right tool for the job.