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."
Disadvantage
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.