The Existential Crisis of a WAF

If a WAF could think for itself during an attack, for the first part of the attack, it would be singing the “ignorance is bliss” theme song even as the Zero-Day attack was creeping up on it like a Grim Reaper. Like a good horror movie, it would be the innocent victim, not having a clue of the approaching menace.

With all the complexity of technologies layered into a WAF, there is nothing the WAF can do to stop what it doesn’t know or understand.

OK, so WAFs aren’t sentient entities with thoughts about Zero Day attacks and Grim Reapers. I confess I’m picking on WAFs, but the analogy could apply to all network-based security devices that depend on signatures to catch exploit code. WAFs are essentially specialized firewalls with a sub-set of web protocol defensive features that are also commonly found in IPS, IDS and Next-Gen Firewall devices. These devices all must satisfy a multitude of technical conditions in order to see the traffic and apply the various detection technologies. Among the conditions that must be satisfied are:

  1. The device must be at a traffic choke point or network tap to receive the traffic
  2. The amount of traffic being inspected must be less than the device is rated for
  3. A valid SSL certificate must be loaded in memory in order to decrypt the traffic
  4. The SSL Cipher used must be supported by the device
  5. The decrypted traffic must be in a formatted standard that can be properly parsed

That’s a lot of jumping through complex hoops before a signature can even be used. Are we asking our WAFs to do too much?

Why a WAF Fails to “Catch” Sophisticated Attacks

If we assume all the above conditions are met and the bad zero-day code in the HTML stream is properly parsed by the WAF, it won’t have a signature to match it to.

We then have to walk through a line of questioning to see if we can be at all optimistic about catching the exploit code.

Does the WAF have a Profile feature, and will it catch the attack? Most Profile engines are so noisy with changes to the protected web site, that they are most often turned off or they’ll drive your SIEM costs through the roof.

Okay, what about the reputation feed? The truth is most WAF owners are happy to dish out the big bucks for a subscription for a cool database of bad actors, but they never really learn how to use it. The feed is there, alerting away at all the bad IP addresses hitting the website. But you don’t dare turn on blocking for fear of your CEO visiting some far away country is in a hotel that has their own firewall address on that bad IP reputation list.

Well, the Bot Detection feature will most certainly detect and stop the attack, no? No. The hacker is not a bot – but rather has a real “bottom” sitting in a chair and real hands on a keyboard.

To recap the sorry state most WAFs are in when a zero-day exploit hits:

  1. The WAF might not have a valid SSL certificate, or is too overloaded to do its job.
  2. There is no signature because it’s a zero-day exploit.
  3. If the profile engine is enabled, it is probably not blocking, so at best an alert is generated and missed due to Alert Fatigue.
  4. The IP Reputation rule will fire, but again it is not blocking and is also missed in the flood of noisy alerts.
  5. The Bot Detection feature is not detecting a bot.

Doesn’t the hacker only need to get lucky once? Well, he or she got lucky five times and now owns your web server – Game Over.

Reality Bites – Just Ask Equifax & Capital One

To point out a few recent breaches because of security device failure, let’s consider Equifax and CapitalOne:

If we take a look at the official Equifax breach report released by congress – See our blog, Congressional investigation into Equifax breach finds multiple security failures - we know that “Once the Apache Struts vulnerability (CVE-2017-5638) was widely reported, security researchers observed a high number of exploitation attempts almost immediately.” The report points to a failure to patch the vulnerable web server immediately and the fact that their network security device had expired SSL certificates that resulted in traffic not being inspected for nineteen months!

Shortly after the Equifax breach, CapitalOne experienced their own breach. (See our blog Capital One Experiences Third Largest Financial Hack from AWS Insider, ). A former Amazon Web Services (AWS) employee was walked out in handcuffs for exploiting a Server-Side Request Forgery (SSRF) vulnerability on the CapitalOne web servers, mostly common in AWS services. A mis-configured WAF was to blame.

Too Much to Ask of Technology?

I have to take pause and ask if we are putting too much reliance on technology that is clearly not up to the task of protecting today’s complicated applications?

If you look back in time, WAFs have been around since the mid-1990’s masquerading as Reverse Proxies, and Intrusion Detection Systems even before that. But back when these technologies were hot, the number of signatures needed to detect web attacks was very small, and the concept of the “Zero-Day” attack wasn’t even a twinkle in Kevin Mitnick’s (the World’s Most Famous Hacker) eye.

Web sites that used SSL were only used for small parts of the site that needed secure transactions, so the devices employed to secure the websites could have been a repurposed desktop computer. Today, these devices are very beefy and expensive in order to handle all the processing associated with just keeping up with encrypted web traffic. And the more features that are piled on, the more horsepower needed, and the more time it takes for care and feeding. It seems to me that the Total Cost of Ownership keeps going up, while the effectiveness is in a downward spiral.

The catastrophic failures at Equifax and CapitalOne were completely avoidable if they would have employed the right technology to protect the applications themselves and had not been relying on an outdated technology that has seen their glory days, and now are heading down hill. WAFs and their close cousins – IDS, IPS, and FW DPI, are trying to perform too much that can easily go wrong if not carefully managed, as we have seen time and time again.

Don’t Despair, Companies Can Avoid the Grim Reaper

Now for the good news – there is salvation for the security practitioner. What if we can throw away the complexity of network security devices and look to a new technology that encompasses the Holy Trinity of application security?

  1. Data shall not become code
  2. The application shall not use memory that is not intended for its use
  3. No files shall be changed, added or deleted that is not intended by its creator – the developer

This new technology called “Trusted Execution” from Virsec is a true slice of heaven due to how it implements protection: This technology quickly analyzes the application when it starts and sets up guardrails to stop the application from doing anything that it was not intended to do. It does this by watching the input of data, to make sure it does not become code (the exploit), tracks the memory used to protect against fileless attacks, and finally employs file integrity monitoring to make sure nothing is changed or introduced to the application that is being protected – all done with a single agent, achieving full context of the application process.

The good news continues because this technology is not a hypothetical pipe dream It’s a real product protecting applications today. One that does not rely on any kind of signature or analytical insights. Following is just a partial list of its true value:

  1. Protection against Zero-Day attacks
  2. No False Positives = No Tuning and No Learning
  3. Visibility of the full “Kill-Chain”
  4. Blocking action at any phase of the Kill-Chain
  5. Very low Total Cost of Ownership


All of this and more comes with Virsec Security Platform.

There Is a Place WAFs Can Call Home

Lastly, I have to say that with all my WAF bashing, the WAF is still a valuable device in the Defense-In-Depth strategy in one area. In my opinion, a WAF defense is best served as a Cloud WAF. If you think about it, the cloud is the best place to push out your security perimeter to defend against distributed attacks, so you can keep your services up and running from those nasty DDOS attempts. These services are often easier to provision and manage compared to their on-premise siblings.

For now, I hope you have seen the light like I have. I feel like a born-again security practitioner, I can finally sleep peacefully at night, dozing off to happy thoughts of water sports and how I can use my old WAF as a boat anchor.


Further resources:

White Paper: Why Web Application Firewalls Are Not Enough

Prediction Series #12: Moving WAFs to the Cloud Means Dialing Down App Security

Congressional investigation into Equifax breach finds multiple security failures

FTC Fines Equifax up to $700M for 2017 Data Breach