How to choose the right Web application firewall

About 10 years ago, the Web application Firewall (WAF) entered the IT security field, and the first vendor to offer it was a handful of start-ups, such as Perfecto (once renamed Sanctum and later bought in 2004), Kavado (acquired by Protegrity in 2005) and Netcontinuum (Barracuda acquired in 2007). The working principle is quite simple: as the attack ranges move to the top of the IP stack, aiming at security vulnerabilities for specific applications, there is a need to develop products designed to identify and prevent these attacks. Although network firewalls are effective at preventing low-level attacks, they are not good at unlocking IP packet layers to analyze higher-layer protocols; This means that the network firewall lacks the ability to apply awareness, and requires this functionality to turn off the vulnerability window in a custom Web application.

But despite the WAF, the vendor promises many advantages, but the end-user experience is rather poor. Early products have many disadvantages, such as high false positives, to the performance of protected applications adversely affected, but also difficult to effectively manage. Around 2005, big-name network vendors, including Cisco, Citrix and F5, or developed web-layer monitoring technologies, WAF as a recognized border security line. Another factor that prompted WAF to be used by mainstream users was the introduction of the payment Card Industry Data Security Standard (PCI-DSS), which explicitly required the use of firewall with application-layer awareness in the 6.6 requirements.

Today, WAF is already a recognized part of the IT Security Toolkit. But many companies are still grappling with the problem: which WAF to buy and how best to integrate them into the Web application risk management product family. This paper analyzes some major decision factors in procurement WAF, and gives some suggestions to ensure that they are suitable for enterprise architecture and network ecosystem.

Architecture and physical Dimensions

WAF should be suitable for existing architectures and take the physical dimensions that are accepted and supported by the Security Operations team. There are two main architectural scenarios for WAF placement: Bridging mode (in-line) or split/bridging mode (Tap/span).

Bridging mode: In this architecture (also called active configuration), the WAF is placed directly between the requester (such as the browser client) and the Web application server in the traffic path. WAF sends requests and responses after checking for application requests and responses.

In bridging mode, the way the WAN uses to deliver traffic, the enterprise can make many choices. The choice of network is: router (3 layer), Bridge (2 layer) and HTTP reverse proxy system. WAF can also be used directly on the host server (where the Web application resides), which is called a host-based WAF or embedded WAF. WAF WAF using the Network Bridge mode may not need to change the network, but traffic must be directed to WAF in the router or reverse proxy mode.

To choose a best model, first evaluate how Web applications are built on the network today: is the application already behind the reverse proxy system? If this is the case, the enterprise would like to continue to use the reverse proxy architecture, you can consider supporting the WAF of this need. The reverse proxy system is an ideal choice if the enterprise requires WAF to terminate the SSL connection to check packet content. However, it does require processing power to terminate the connection (whether it is an SSL connection) before sending the packet content, so you need to sculpt and test this pattern to ensure that there are no unacceptable delays.

After the bridge WAF is configured, you can proactively block requests and traffic that violate the WAF rule set. This functionality is useful, but use caution-if the bridging WAF is too aggressive to block, the legitimate traffic will be blocked from entering the Web server, thus causing the application to be unusable. Before any proactive blocking rules are developed, a thorough test is performed to ensure that the service unexpected interference is not present in the production environment. In addition, you can use WAF as a bridge, but leave it in a pure monitoring (or passive) mode.

Another factor to consider in architecture is how many WAF will be installed and managed. If you need WAF for multiple scenarios, consider supporting distributed management or distributed WAF solutions. In this mode, you can use a central console to manage firewalls for multiple occasions. You can use rules or settings uniformly for all WAF, or you can use the rule set individually depending on the situation of each WAF, depending on which Web application WAF is protecting.

Table 1: Advantages and disadvantages of bridge type WAF

Split/Bridging Mode: This mode is also called "passive" mode, because the WAF is blocked outside the flow path, monitoring traffic from the connection port or across the port. The WAF/bridging type is often used to collect data for later use in investigation or forensics analysis. A major advantage of this architectural pattern is that it does not interfere with network traffic or throughput because it is not embedded directly. On the other hand, not in the traffic path means that the solution cannot perform the kind of blocking operations that the active bridging WAF can perform. However, some form of blocking action is supported, such as a connection reset, or by contacting another system, such as a network firewall, and then having the system perform a blocking operation.

Figure 2: Advantages and disadvantages of WAF/cross-connect

New changes: Two important changes in the enterprise need to WAF the use of new architectural patterns, these two changes are cloud computing and virtualization. Cloud based WAF first intercepts traffic, then allows legitimate traffic to enter the corporate network, or for companies that have Web applications in the cloud environment, allowing legitimate traffic to enter the server through the cloud. Virtualized environments pose a unique challenge because virtual institutions running on virtual machine management programs become their own small networks, where traffic is transferred from one virtual server to another, and is not necessarily routed over the network. To prevent application attacks within the virtual machine, WAF needs to be able to view traffic. This can be done by using the Application Programming interface (API) or other services to monitor activities through virtual machine management programs.

Physical Dimensions: Explore the issues of how WAF bundles and sells to customers. Many WAF support a variety of physical sizing options, so businesses don't have to worry about buying hardware, as long as the software for independent software Developers (ISVs) is approved. In other words, choosing what physical size hardware depends on what your business is most accustomed to. Options include:

Pure software-hardware is provided by the purchasing department

Equipment--software and bundled sales of equipment specifically tailored and adjusted for WAF

Hardware--WAF intelligence embedded directly in the hardware itself

Host-This is a software scenario, but the software is installed on the same server that is running the Web application, not on a separate host or virtual machine.

Detection technology

Now that you've discussed the architecture and physical dimensions, let's ask the question: How can WAF detect vulnerabilities in Web applications and attacks against Web applications? The purpose of WAF is to intelligently protect web applications, so it is important to have fine-grained rules and detection mechanisms. Most WAF adopt a method combining different detection techniques to ensure the widest range of detection and the most accurate results. In addition to asking the supplier what detection technology to use, but also let the supplier show the false positive rate/False report rate and Third-party test results, in order to better understand how the WAF in the actual use of the effect will be good. Here are some testing techniques and several questions to ask the last selected product vendor:

Features: Similar to the features written for anti-malware and network intrusion Detection systems (IDS), the WAF feature also matches a predetermined string or regular expression (RegEx) to traffic to find a known attack.

is the product delivered with a set of features?

How often do vendors update features?

Rules: Rules are a step closer to the concept of features, which can link a series of strings with the logical "and" operators, add more complex matching mechanisms with the "or" operator, or use the "non" operator to implement the "exclusion" feature. You can also set rules to seek out very specific string types, like a 16-digit number (such as a credit card number), sent as a response from a Web server. Some WAF can dynamically "learn" traffic patterns, looking for abnormal behavior according to a set of benchmark rules. "Learned" information can be sent to administrators to propose new rules for WAF or complementary protection devices such as IDs or network firewalls.

Does the vendor provide benchmark rules?

Can customers manually add new rules?

Can WAF dynamically "learn" new rules?

Normalization: An attacker's modus operandi is to tamper with the payload of the vulnerability by posing harmless content (such as URL-coded portions of the payload) to avoid WAF detection. In order to detect this attack, WAF must be able to normalize the request for analysis. Here are just a few canonicalization mechanisms--a complete list of the 3.1 chapters of the Web Application Security alliance Web Application Firewall Assessment standard.

Can WAF normalize escape characters or encoded characters (such as T, & #0, 01,%2C, Xaa, and Uaabb)?

Use a self-referencing path (that is, using/./and an equivalent encoding scheme)?

Do you use mixed case and international character sets?

API: If a business wants to develop custom detection techniques or rules for special evaluations, such as logic checks, this can be done through the API. Consult the vendor to see if the other side really supports the API, and if so, how tightly integrated the APIs with the WAF analysis engine?

Does WAF have an API?

How tightly does the API integrate with the WAF engine?

What kind of support does the vendor provide for custom Plug-ins?