Four questions to ask before buying a Web application firewall

How does the WAF integrate into your environment?

One of the most critical aspects to look at when evaluating a WAF is deployment. In other words, what is required to put the WAF to work? There are a few different WAF deployment options to look at, and each of these should be considered, along with an enterprise's existing environment, to determine which type of WAF is the best fit. In many cases, this will allow decision makers to -- through the elimination of products that don't work for their network and IT environment --- to narrow down the list of vendors and products.

• Inline appliance: This very common WAF implementation method involves placing a device on a network between the users and a Web application. This method usually requires some in-house expertise because admins will be changing in-house network configuration(s). It is ideal when an enterprise has adequate internal technical staff or can afford to pay for implementation services through the vendor.
• cloud-based WAF: This WAF method usually requires that organizations redirect DNS records to resolve to the WAF vendor's IP addresses and have the Web traffic forwarded from the vendor to the actual application host. In many cases, enterprises will need to provide their SSL keys as well, due to the fact that the vendor's servers will be decrypting the data before it is forwarded.

There may be performance implications here, because the traffic is taking extra steps before reaching company servers. Most vendors have adequate bandwidth, so this isn't a problem in the majority of instances (but should still be kept in mind). The cloud-based WAF is often easier to implement because it requires only the DNS change (and possibly SSL keys being installed), and could be less work on internal IT technology skill. NOTE: Many cloud-based programs now offer DDoS protection as well.

• Integrated WAF: The code- or software-based WAF will most likely require changes directly in an enterprise's Web application code, or on its Web servers. This is a great option for technically skilled staff, and can be cheaper than other WAF products. It doesn't require a network architecture change or DNS redirection either. And integrated WAF products generally have the least overall impact on networks, systems and performance.

Enterprise decision makers should have a thorough and detailed list regarding which questions need to be answered before they choose a WAF product or vendor.

It's important to talk to the vendor and involve internal technical teams when evaluating the type of WAF an enterprise wishes to buy. There may be requirements or restrictions that they aren't aware of on the surface, but could have a major impact on what is chosen. An example of this might be how the chosen integrated WAF works with the Web server. Having Web server administrators involved might avoid any problems during implementation. Another common issue is with streaming or heavy, network-based content streaming through a cloud-based WAF. Having the network team and performance-testing employees handy will ensure users don't experience latency issues.

Another important consideration here is how the WAF handles Secure Sockets Layer (SSL), which protects website identity and data as it flows over the Internet. WAF implementations vary in how they work in regards to SSL.

In either cloud- or appliance-based WAF implementations, organizations need to decrypt the traffic in order to see it. This involves either terminating the SSL session and recreating it (if necessary) or decrypting the sessions on the wire as they pass through the WAF. Make sure the products being evaluated supports these options.

How does the WAF detect and respond to attacks?

WAFs operate primarily by inspecting the content of requests and responses between the application server and the client. How and what a WAF inspects is critical to its effectiveness in protecting enterprise resources.

What the WAF inspects -- such as headers, sessions, file uploads, etc. -- will determine its ability to respond. A WAF should be able to inspect all components of a request/response object, including the session details itself. If an application has requirements, such as limiting the number of sessions for a user, most WAFs can help enforce those. A WAF should have configurations available to allow admins to choose these options with ease. If an organization has specific requirements around how GET versus POST is used, or specific items in the referrer, the WAF should support this.

Detection of anomalous or malicious traffic is based on a few models, and understanding each is important.

If the WAF uses a blacklist approach, it will only block requests if they are found to contain a known attack in the list. Well-known attacks such as SQL injection and cross-site scripting often contain certain characters that are easily detected. Blacklisting works great, as long as the WAF is aware of the attack method. So, blacklists must be kept up to date as threats change often.

If a WAF uses a whitelist approach, it will only allow requests that meet the criteria in the list or configuration. This detection method requires more effort during implementation on the front end, but is usually a more secure approach because it blocks everything that isn't defined as acceptable.

Either of these methods should be configurable by a company's technical team.

Beyond detection, how the WAF responds to an attack or anomaly is also critical. There are a number of response options that WAFs offer, and they should be able to be easily changed in the configuration interface. Typically, a WAF will interact with a request or session in some way (when an attack or anomaly is identified), such as terminating the session with the application server or blocking that single request. Each method has benefits and drawbacks, and understanding which methods are available is important.

A WAF should be configurable to block using one of the following methods:

• Block the session
• Block the IP address
• Block the request
• Log out the user
• Block the user

Ideally, a WAF should support these in various configurations as a response to detecting an attack or anomaly. In some cases, though, a WAF may need to rely on other devices, such as network firewalls or routers, to perform its blocking operation. Organizations should make sure the WAF product chosen is compatible with existing network devices if they wish to use this feature.

How does the WAF perform logging?

While (arguably) the most important feature of a WAF is to protect from attacks, a close second would be its ability to log and alert admins to what's going on. In some cases, organizations may suspect an attack or compromised user, and want to see the details of what happened. This is where, what and how the WAF logs are critical. The easiest breakdown of how to do this logging is the tried-and-true Where, When, What method.

First, let's discuss the "What." What does the WAF log? It should be logging as much detail as possible. It should be tracking each transaction, including sessions, navigation details and everything in-between. The full details of each transaction log entry should be well-documented to reduce the amount of time and effort it takes to investigate an incident. By having extremely detailed logging, enterprises will also be able to troubleshoot problems that might occur due to configuration issues with the WAF itself.

Next, let's discuss the "When." This is pretty straightforward, but it's important to look at two key points. At minimum there should be two sets of logs. The first would be an access or transaction log populated with all activity passing through the WAF. The second would be an event log where an entry is created when something triggers the WAF's detection or reaction. While both logs are important, the event log will be used often because the entries usually indicate anomalous behavior, such as attacks or suspected attacks.

Finally, let's discuss the "Where." Where the logs are stored or how they are sent to a central logging service is critical. Are the logs formatted and transmitted using formats and protocols supported by security information and event management, or SIEM, systems that the organization uses? Are the logs retained for a certain period of time on the devices? Does the WAF obfuscate any sensitive information, such as Social Security numbers or permanent account numbers (credit card numbers, for example) contained in requests? This could be important for compliance with regulations such as Payment Card Industry Data Security Standard Version, or PCI DSS.

In addition to storage, the Where also includes how alerts are generated and sent to the organization. Email alerts, Web portals and SNMP are the norm, but the more options available, the better.

How is the WAF managed and updated?

WAFs aren't intended to be configured and forgotten, and so how they are managed is important for long-term use. If a WAF uses blacklist signatures or rules, an enterprise should find out how they are going to be updated. The organization should also ensure that it can customize these rules and signatures in a way that affords the most flexibility.

If the company isn't using the PHP scripting language, it likely doesn't need those blacklist signatures or expression rules, and should disable them. Typically these options are configured via WAF policies through the management interface. Ensure that these policies are entirely user-configurable, in order to maintain the most control over how the WAF works.

If an organization is getting regular vendor updates, how are they delivered? Many vendors will supply a manual update file, or allow the appliance to automatically contact an update service. The same concern should be applied to the underlying operating system updates, depending on the platform that the WAF runs on (such as Windows or Linux). Make sure that whatever update method the WAF product uses, it does in fact perform them. It would be counter-productive to have an insecure device protecting the enterprise's Web applications.

Conclusion

In summary, enterprise decision makers should have a thorough and detailed list regarding which questions need to be answered before they choose a WAF product or vendor. Make sure to formalize these questions ahead of time, and get them all answered or addressed before making a final decision. For an additional resource, the Web Application Security Consortium has created a WAF evaluation criteria document that is worth checking out. It is extremely detailed.