You have had your network firewall in place for years, and it makes you feel safe. Your ports are all locked down, so that no-one can hack your e-mail or FTP servers. So how is it that the database serving content to your website just got hacked, and is happily delivering malware to all of your paying customers?
The problem with network firewalls is that they can't block port 80 (the port through which HTTP traffic is served to the web). And web-based application attacks have been mounting in the past few years, as operating system suppliers become more adept at protecting basic system resources from hackers.
Web application firewalls can help to solve this problem, by analysing and applying rules to HTTP traffic. Instead of just looking at which traffic is going to which ports, they can analyse the content of the traffic to look for suspicious activity targeting applications.
If, for example, someone from outside the company is accessing a web application and injecting SQL commands into a URL or web form, a rule in the application firewall could spot that and stop it from happening. Rules can also be created to stop people from sending malformed HTTP packets in an attempt to crash the system, for example.
The Open Web Application Security Project (OWASP) defines the specific selection criteria for web application firewalls. They should create very few false positives, it says, never refusing an authorised request. Other criteria include the strength of defences contained in the default configuration, ease of use, and the types of vulnerabilities that it can prevent. They should also be configurable to prevent any specific problem (so that an emergency patch on a web application doesn't break it, for example).
OWASP offers its own quasi-web application called Stinger. This is a Java input validation filter that can be put in front of a web application, it says. Commercial web application firewall suppliers will either adopt the hardware appliance route, or take the software approach.
Payment card security requirement
Web application firewalls have become hot property ever since the Payment Card Industry Data Security Standard (PCI DSS) was updated to specifically request them. But Paul Henry, security and forensic analyst at endpoint security company Lumension, says that vague definitions in the standard have opened the door to marketing hype from suppliers wanting to jump on the bandwagon.
"For many years there was no application firewall requirement as part of PCI. They finally instituted a requirement for an application firewall, but didn't define what it was," he says, adding that it enabled packet firewall suppliers to layer a few intrusion prevention system signatures on top of their existing products and call them application firewalls - something which he considers misleading.
There are certain features within web application firewalls that set them aside from the pack. The deep content inspection - probing inside network packets to understand what they contain - is a basic requirement. Another quality is SSL support. Many web application sessions now encrypt their content using SSL signatures, which can make it difficult for the firewall to see what is being communicated between the web-based client and the company's internal web server.
"Web application firewalls deal with this by inspecting SSL sessions using the web server's private key, detecting policy violations, and resetting offending connections," says Andrew Hacker, senior security analyst at independent network equipment testing organisation ICSA Labs. "These sessions can either be passively decrypted and inspected or actively terminated and re-encrypted."
However, Simon Heron, internet security analyst at Network Box, points out the disadvantage: "The obvious downside of this is that the secure link is compromised by the gateway device and there are privacy implications. Any company using this must make it perfectly clear to their employees that this is what they are doing."
It is also important to remember the maintenance involved. Configuring a rule that protects an application from network traffic is fine until that application is changed somehow, either by a version upgrade, a module expansion, or an emergency patch. At that point you must factor the web application firewall into your change management procedures (and if you don't have a codified change management workflow, web application firewalls may not be for you).
Web application firewalls are a useful means of applying extra protection to your infrastructure by taking a more intelligent and intimate approach to securing your web traffic, but don't underestimate the work involved in configuration and maintenance.