Market Analysis: Web Application Firewalls

You're not paranoid: The Internet is evolving so fast that no Web application stays static for long. Web 2.0, AJAX, RSS, blog software, CSS layouts, Google sitemaps, XHTML compliance...there's always a new technology to implement, a new feature to add, a new attack vector to be exploited. And as enterprises move applications from the desktop to the Web, IT is forced to defend an increasingly tangled environment, woven from a mix of internally and externally developed apps with frequently changing code that almost always contains security holes.

If this sounds familiar, consider deploying a Web application firewall, or WAF. This relatively new security tool is designed to pick up where network firewalls--which guard up to the transport layer of the TCP/IP stack--leave off. A WAF protects the application layer, using deep-packet inspection to guard against SQL injection, session hijacking, cross-site scripting, buffer overflows and other attacks.

WAFs are available as software and as appliances that plug into your network at a point where they can monitor traffic to and from Web servers. While building our comparative review of these products for "WAFs Blast Pernicious Payloads," page 41, we ran across a variety of deployment methodologies, with some products supporting multiple configurations.

Understand the Threat

Before deciding whether you need a WAF, you must understand the nature of the threat. At the most basic level, an attacker will try to provide malicious input to the Web app to make it do something that wasn't intended. The attacker could enter an extremely long URL to try and create a buffer overflow. Alternatively, an XSS (cross-site scripting) attack attempts to capture legitimate user session information. Or, an attacker could modify session cookie values to try and impersonate a user, thus gaining access to personal information. Database-driven sites are also vulnerable to SQL injection attacks, where an attacker tries to guess how the application works internally, then enters SQL code into a form field to retrieve data from, or gain access to, the underlying database.

To learn more about threats to your Web servers, click over to the OWASP Top 10 Project, a list of the 10 most critical Web application security flaws with descriptions of each vulnerability

Market Drivers

Of course, security is the major driver for WAF. Even the most sophisticated network, girded with perimeter firewalls, is susceptible to Port 80 and Port 443 vulnerabilities. Human error is a given, and a WAF greatly reduces the risk of your data being compromised. This leads us to the dreaded "c" word--compliance. Let's face it, regulators aren't going away. Over the next several years, we expect that more bills will be passed at the state and federal levels related to online privacy and security. California's consumer privacy law, considered a model, states that if personal consumer data is released, the organization at fault must notify those individuals affected. If a company is unsure who was affected, it must notify all of its consumers. With a WAF in place, the forensics/log files should be able to detail the exact query that resulted in the breach, and if the WAF was not able to stop the attack, at least an administrator can reconstruct the incident to determine exactly which data was compromised.

In addition, Section 164.312 of HIPAA states that entities must implement technical policies and procedures for information systems that maintain protected health information, to allow access only to those persons or software programs that have been granted access rights. A WAF is another step to ensure compliance at this level (see "Feds Reach Out and Touch IT").

Assessing WAF Architectures

Software WAFs typically are installed on the Web server, where they inspect traffic before it gets to the Web service. The main considerations in this approach are CPU overhead and security holes in the underlying OS. As we mentioned, WAF appliances offer multiple deployment options. Commonly used network topologies include:

Connecting the WAF alongside the Web server through a hub, or a mirrored port on a switch, removes these concerns. The trade-off in this case, where traffic isn't going through the device, is that it's difficult to provide foolproof blocking when attacks are detected.

Security Models

As with most security technologies, WAFs can use a positive or a negative security model in deciding which activities to permit and which to block. In a negative security model, all transactions are allowed by default, except for those matching one or more predefined attack signatures. WAFs come with a built-in list of signatures to detect common known attacks, and most products allow IT to add custom sigs. In our tests, only Breach's BreachGate didn't allow customization. In theory, the WAF will recognize attacks while allowing regular Web traffic to pass through. Advantages of this approach are that it doesn't require much effort to set up or maintain, and it yields a manageable number of false positives. This setup is less secure than a positive approach, however, because the server will be vulnerable to newer attacks for which signatures have yet to be created. If considering a WAF based on a negative security model, find out how often signatures are updated. An update might disable previously allowed exceptions and wreak havoc on systems access.

A positive security model, as the name suggests, works in the opposite fashion. All transactions are denied by default, except for those that have been explicitly allowed. Although this approach is generally more secure--all unknown activity would be blocked automatically--it does leave IT with the unenviable task of going through Web applications, page by page, creating a comprehensive list of legitimate inputs. To simplify this, most WAFs employing a positive approach provide for a learning mechanism that can create a list of valid inputs automatically. Learning takes place as the device studies existing traffic and creates a statistical model based on it. The model can then be tweaked to accommodate exceptions. As you might expect, however, this method will yield a greater number of false positives; a model built over the course of two weeks, for example, could raise an alarm when the monthly backup operation is performed. It also requires ongoing maintenance, in the form of constant retraining, as your application load changes.

Which model you select will depend greatly on your particular business needs and your environment. Important criteria to consider are the stringency of security policies, the frequency with which applications change and the amount of management overhead you're willing to take on. If security is paramount, consider a positive security model. If ease of deployment and maintenance in a fast-changing environment are key, a signature-based approach could be a better fit.Note that there are products based on a combination of the two that try to provide the best of both worlds--positive-security-model firewalls that allow for creation of custom attack signatures, and signature-based firewalls that let you create rules on acceptable inputs.

Response Team

A WAF's capabilities in terms of blocking malicious requests depends on your network topology. In proxy-based and bridge modes, to ensure complete blocking--where an attack is completely prevented from reaching the server--the WAF must buffer enough packets to hold an entire HTTP request until it has passed inspection. This, again, introduces latency. For very large requests, the connection can be interrupted at a point when it's partially buffered, but not completed.

In an offline model, where the WAF monitors traffic but isn't placed between client and server, blocking can be achieved by sending TCP reset packets to both, or by using an existing firewall infrastructure. In such a scenario, response time is critical, particularly for internal clients where latency is low enough for the response to have been completed before blocking was enforced. In tests with BreachGate, we did see occasions where the attack was detected and flagged for blocking, but the response nevertheless showed up in our browser. Even in cases where the client was successfully blocked from receiving a response, it's possible the request would get though to the server, which would leave it vulnerable to blind attacks. Under load, this scenario increases the number of attacks that get through. Not a pretty picture.

When evaluating the response capabilities of a WAF, it's important to consider the level of control in terms of selecting different responses to different types of attacks. In most real-world scenarios, an administrator will want to monitor all malicious activity, but respond differently based on the severity of the threat. Some options commonly provided include discarding the HTTP request, blocking the TCP connection, banning the IP address and blocking the application session.Finally, some organizations will want to provide custom error pages, notifying the client that the activity has been logged and providing contact information in case a legitimate request was accidentally flagged.

Log Jams

Most WAFs provide comprehensive logging for tracking suspicious activity. They also let IT filter incidents based on time, attack type, severity, IP address and other factors; this can be useful for investigating an attack. In addition, we like being able to create an executive report, with charts and all, summarizing past activity--helpful when it comes time to justify the expense, as the products tested had an average price of $30,000.

Only BreachGate logged all outgoing responses, in addition to incoming requests. We could view these responses in the browser, to see exactly what the attacker saw. This could be useful in determining the extent of damage, if any, and could be invaluable in complying with reporting requirements in case of a successful attack.

Another feature that's important to consider, from a logging standpoint, is the ability to mask or hide certain information. To prevent logs from becoming a security concern themselves, for example, you may not want to store sensitive information, such as credit-card or Social Security numbers, within them. Most products we tested let you create custom regular expressions to mask this information within a stored request or response.0