I’m sure many of you remember Nigel Tufnel oozing admiration for his amps which “went up to 11” in Rob Reiner’s seminal This Is Spinal Tap? Nigel points out that amps normally only go to ten, but he proudly asserts that his “go up to 11” which “is one louder”. When questioned as to why the ten setting could not just be set louder, there is a blank pause followed by a reassertion of the fact that “these go up to 11”. Hilarious!

As idioms go there are few which are so instantly recognisable as indicative of a basic misunderstanding of the capability of technology. For those of us involved in designing cybersecurity technology architectures there are sadly myriad “these go to 11” moments, especially when looking at the arcane world of Web Application Firewalls (WAF).

The Evolution of WAF

The WAF is an amazing technology. Evolved from a fusion of Next Generation Firewalls, Intrusion Detection Systems (IDS) and network proxies, the WAF is (arguably) one of the most critical detective and defensive technologies at play in the perimeter space today. Traditional network, Domain Controller (DC), Demilitarised Zone (DMZ) and even Internal Segmentation Firewall (ISFW) family of firewalls have been limited to applying simple, brutal rules which do not rise above the network level. These network controls can (by definition) only be leveraged based on IP address and port. Simple, necessary and effective as far as they go. However, for organisations that offer web-based services, port 80 and 443 (http and https), all traffic seeking to access services on these web services must be allowed through the firewalls. Next Gen firewalls stepped up inspection capability in light of this fact, but it very quickly became apparent that a dedicated device family was required to address this challenge.

Attackers, realising that there is a perpetual open door through the firewall control tier, have developed a dizzying array of techniques to hide malcode and obfuscated command instructions within the many vectors available to them in the http protocol – control characters can be used to inject arbitrary instructions in urls, cookies, user agent strings, queries, parameters. The nature of http parsing means that there is a very broad opportunity to inject all manner of damaging arbitrary code through the web tier resulting in the potential for a maelstrom of damage, data leakage or worse. Web application attacks are a fascinating area for the security professional to study. The techniques that have been developed to make poor web servers and databases do exactly the opposite of what they were supposed to is actually almost admirable, and certainly a field that requires many years of study to master.

Polymorphic Attack Horizon

Of course, all web applications could defend against these attacks by ensuring (inter alia) that input streams are validated, sanitised and checked at the code level. However, it is a truism that in a world of perpetual development not only in legitimate hosting, content-serving, data management and code structures, there has been an equivalent (and some might say more advanced) rate of development of attack techniques. A constant surfacing of new vulnerabilities means that the organisation must either perpetually patch, upgrade, rewrite, dodge, duck and dive to ensure that application code and infrastructure is as robust as it can be in the moment. Of course, this doctrine should be kept at the heart of application development, but just think about what that means for a moment. Any organisation trying to keep up with this polymorphic attack horizon would need to find the means, methods and management tools to constantly change their business-critical apps and infrastructure. Risk, resource and service here on Earth mean that simply standing like King Cnut on the shore demanding that the tide simply be patched, that every wave should be current, compliant and not exposed to any known attack vector (and the many unknowns) is simply not living in the real world. It’s a Sisyphean task, and frankly not one that can be realistically delivered at a rate that can match the perpetually changing world of attack.

Enter WAF

Which is where the WAF comes in. the WAF sits in front of the web tier and applies the upper-layer controls that the network firewall cannot. The WAF can inspect all of the OSI layers up to layer 7 and can apply content filtering rules based on signatures, or Request For Comments (RFC) standards, or heuristics. Negative security policies (where all traffic is allowed “unless”), positive security policies (where all traffic is disallowed “unless”) and blended variants can be built to ensure that the maximum defensive capability is applied to the http datastream before it hits the host. Furthermore, because of their inspection capability, the best of breed WAFs can also deliver protection from L7 DDoS Attacks, Brute Force Attacks against login pages, Automated Botnets can be detected through client challenges and behavioural analysis, IP Intelligence feeds can be consumed so that known bad actors or compromised subnets out in the world can be spotted and squashed long before the poor application has to deal with any attempts to subvert their legitimate function.

A properly configured WAF can provide that essential help to the application, giving some “slow time” back to the development community to understand and deliver a properly-managed and de-risked approach to code-level protections.

Notice I said a “properly configured” WAF can do this.

Do you know what happens if a misconfigured or poorly configured WAF is stood up in front of the web tier? In purely service terms the best thing that happens is nothing. The worst is annihilation of service, arbitrary blocking of legitimate traffic – it’s entirely possible (and usual) to find that an inappropriate WAF policy can actually be a very effective auto denial of service tool. DownDetector’s best friend.

To properly configure a WAF the organisation must understand the OSI model, network technology, proxy configuration, hosting platforms, coding languages, database technologies, cyber security and encryption. Bear in mind that a WAF can only inspect decrypted data streams – there is no magic wand that allows the WAF to read ciphertext, so the WAF must either be configured as an SSL proxy or be positioned in transit between or behind SSL termination proxies. A point which is very broadly misunderstood. Furthermore, once the WAF is stood up it must be configured properly. There is no point in switching every signature in the box on because all you end up with is an alert console lit up like the fourth of July fireworks with thousands and thousands of spurious alerts, a panicked SoC, lots of electricity, CPU cycles and time spent wading through oceans of false positives. Lots of light and no heat.

Demanding Technology

Unlike many technologies applied in the defence in depth model, the WAF cannot simply be switched on like a toaster and left to make toast. These technologies demand a relationship – they must be understood and constantly tuned, observed, worked. The WAF is a very demanding mistress. However, with the correct attention and understanding they can deliver enormous value. Indeed they might be the device that saves your organisation from ruin. They do tend to be brutally intolerant of any shortcomings: place or build them incorrectly? Misconfigure a policy? Don’t terminate SSL properly? Don’t understand your own applications? The WAF can and will very quickly bite you and bite you hard.

It is therefore critical that all of these factors are well understood before trying to put these powerful control technologies in front of your web services. If you are diligent and put in the necessary legwork these devices will light up and start paying out silver dollars. If not? Duck and cover.

We Have a WAF…

I have seen many fine deployments where the WAF proudly delivers first class protection, evidencing its value and robustly defending the web application against those who would do harm. I have also seen some WAF deployments where with the best of intentions either no protection at all has been delivered, or services have actually been impaired. The former is worse, as it is easy for stakeholders to be falsely convinced that the full gamut of L7 protection has been deployed in their organisation, whereas the reality is that no protection at all is being delivered. It’s a difficult conversation to have to turn this state of affairs around, and sadly, the ghost of Nigel hangs over too many of them:

“We have a WAF.”

“Yes, but unfortunately it’s not doing anything.”

Blank pause…

“But we have a WAF. And it goes up to eleven.”