What is a WAF and Do I Need One?

A developer friend once told me “web applications are the drywall of the internet.” What he meant was, web development has become so trivial it’s too easy to just quickly put something together and patch until it looks and works OK.

That exact development attitude, and the exposed nature of web applications, are the reason web application attacks are the number one source of data breaches. The number one recommendation is installing a web application firewall (WAF). Also, PCI DSS, since v1.1, recommends “either a regular source code review or the use of a web application firewall.”

As you read this post, another very important aspect to remember is that web applications aren’t only on the internet anymore – your internal business applications are now more than likely web applications. While an internal web application doesn’t have the same exposure factor as an internet-based application, most of the time they have much more important and confidential information in them. This, along with the end of the perimeter network, makes a strong case to why internal web applications may need the same controls as externally facing applications.

What do we do with a WAF?

Why aren’t WAFs more ubiquitous? Everyone seems to have a faint idea of what a WAF is, but only a few organizations have bothered to introduce them. Some that have are embarrassed to admit how little they’ve done to tune and maintain them.

The first WAF was introduced in 2011, 13 years after the first firewall and 10 years after the creation of the Open Web Application Security Project (OWASP, the authority in web application security), so in internet terms, WAFs are a new idea. I’ve compiled the most common questions I’ve seen about WAFs and hopefully this will guide you and your team in the path to understanding why your organization does (or does not) need a web application firewall.

What is a WAF?

Web application firewalls (WAFs) fill an important need in the security industry. WAFs protect at a different layer than typical firewalls. The web, specifically the HTTP protocol, was not designed for the complex applications we’ve developed, so to compensate for the stateless nature of HTTP we’ve had to develop various scripts and frameworks. These frameworks and scripts have introduced a new set of vulnerabilities, and that’s where WAFs come in.

WAFs filter the traffic to and from web applications. WAFs perform customized inspection, protecting your website from flaws in the code, be it from off-the-shelf, in-house developed or random internet downloaded code snippets.

WAFs can be a standalone piece of hardware, a virtual server, a cloud app or an open source web server plugin.

More importantly, they stand between the attacker and flaws in the code that could be used to compromise your web application, the data behind it and ultimately your organization.

Why do I need a WAF?

If your auditor didn’t already tell you that you need one, that can be a hard question. And it all comes down to understanding how your business uses web applications and how important that data is to your business. Ask yourself:

• Would defacement, modification or leakage of the data in my web application cause my business harm?
• If someone was able to impersonate my web application, what kind of damage could they cause?
• If my website started serving malware, would my business be affected?

If any of these questions will cause you to lose sleep tonight, you need a WAF.

Doesn’t my current firewall do this?

Firewalls and even NGFWs don’t cover the same class of vulnerabilities that a WAF protects.

Web-based vulnerabilities are common and easy to exploit. Web frameworks are the platform of the internet and they are not as tried and true as our desktop/server operating platforms, since web code most often needs to be written fast and without the same testing and rigour. A great article on what is/isn’t covered by WAF has been published by OWASP here.

How can I implement a WAF?

Web application firewalls work similar to a proxy, but in reverse. So the requests made to your site are cached, reviewed and allowed through based on a specific ruleset. Many WAFs come with a standard set of rules out of the box, but the real power of a WAF comes from learning and customization.

There’s no easy “set and forget” fully effective WAF (at least not yet). Automated learning has become better with every generation, but there are so many new dark and beautiful ways in which attackers are able to bypass controls.

WAFs are best implemented by a team of security practitioners and developers. It is important this team understands the both the potential threats and the deployed web applications well. Using whitelists, blacklists and weeding out false positives can be a daunting process.

An effective way to start a proper WAF implementation is doing a thorough web application assessment, reviewing the output manually and weeding out false positives. Finally, update and patch the code to address the recommendations of the web application assessment where possible, and where time does not allow, implement controls on the web application firewall. Rinse, repeat and add to operational processes.

How much work is it to maintain a WAF?

This depends on how static your web applications are. Like most security services they should not be left “as is.” WAFs put your tools/people/process mantra to the test. Application lifecycle and operation change management processes need to be in lock-step.

Basically, proper WAF maintenance needs to integrated with any aspect of IT that may change and/or affect the underlying code of the web application. So, changes to the WAF may be needed after:

• A release of a web application – this is the most obvious scenario
• An update or patch to a web application
• A major modification to the web application (which introduces new fields, for instance)
• Vulnerabilities are found during a regular web application assessment

My application is hosted with a cloud provider, don’t they have a WAF by default?

Not necessarily. WAFs need a custom configuration and typically cloud providers will charge a premium to enable most WAF features. These features need to be configured to match the parameters used by your web application. For example, AWS Marketplace has a number of WAFs available for sale. Like on-premise appliances and VMs, the same configuration, care, feeding and management is required.

I already perform regular web application assessments as part of regular release process, so do I need a WAF?

Absolutely. A web application assessment is an amazing tool for identifying vulnerabilities, and is highly recommended. The output of a web application assessment is a list of fixes and recommendations. A WAF can help in the following ways:

• Some vulnerabilities identified during the web application assessment cannot be mitigated prior to ‘go-live,’ and a WAF ‘rule’ can be used as a stop-gap measure before the code changes can be introduced to the site.
• Some identified vulnerabilities are beyond the control of your developers. Developers may use code packages from third parties where patching them is beyond the control of your team, thus implementing rules to block these vulnerabilities using the WAF may be the only course of action.

WAFs are especially relevant where ‘concrete vulnerabilities’ are found: the vulnerabilities discovered as part of a penetration test or where a vendor has released a patch you can’t apply yet.

An important final thing to remember is that WAFs work very well for what they’ve been intended to do, and are not 100 percent infallible. WAFs simply bring another level of protection that is needed as we add more and more web applications.