5 November 2024, Tue |
9:29 AM
The past couple of decades has turned the Web Application Firewall (WAF) into a ubiquitous piece of security kit. Any organization with a web application (which includes most large businesses) has a WAF installed to protect their data and assets from being breached. Best practice for securing web applications has evolved to simply deploying a WAF in front of your app.
The truth however is that today, with the modern application lifecycle empowering DevOps to release updates at a much higher frequency, the traditional WAF has not been able to keep up and maintaining a WAF has become both labor intensive and complex.
Given this challenge, what should security professionals do? What will prevent web applications from becoming the front door into an organization’s infrastructure? Knowing that DevOps are going to keep spinning out new code, how can one figure out if their WAF is worth the maintenance or dead in the water?
Let’s take a closer look at what it would take for your WAF to keep up with the speed of DevOps.
While network security was all about monitoring static networks which use the same protocols as one another, WAFs were designed to protect web applications that are distinctly different from one another. Every app is unique and each piece of code is different and nuanced with its own set of vulnerabilities. Even before the introduction of cloud storage and the breakneck DevOp’s speed, WAFs were recognized as being only a “mediocre” security solution. Inevitably, using a solution that sits in front of the app, rather than inline, means that contextual analysis is impossible. With no context to understand the content within the app that’s being interacted with, it’s impossible to automate the WAF’s evolution in parallel with the application’s evolution.
Machine learning improvements only solved this conundrum to a degree. While sophisticated WAFs need “only” a month to silently sit and learn to create a baseline for the application, a month is a long time to leave an app unprotected. It’s inevitable that humans need to step in and help calibrate the WAF, and that’s when the maintenance becomes heavy duty. If the WAF needs time to learn and create a baseline every time the content or code changes, there is a lot of heavy lifting for the administrator to carry out in order to reduce alerts and create exceptions.
With continuous delivery, it is just not possible for your WAF to protect a web application from logic attacks without human intervention. The reality is that most WAFs aren’t in alert mode. It is too dangerous to allow them to over-block because the high volumes of alerts will create alert fatigue. Perhaps an administrator can do some minor fine tuning so sensitive parts of the app are covered with blocking rules, but the rest of the app will be protected by the WAF in alert mode using pattern matching and other crude techniques. This adds up to a security solution which can’t auto-deploy to protect from new logic attacks as the app evolves.
Native cloud computing is about agility. What took two weeks to create back in 2015 now takes mere seconds. By leveraging new micro services, you can dramatically change your app in a few minutes. In this new environment it is absurd to consider using a standard pre-cloud application security solution that relies on learning or manual configurations.
Each time a developer tweaks code and sends it out into the wild, it’s a unilateral move made without consultation with security personnel. If you’re using a WAF that relies on the assumption that ANYTHING in your environment is generic, your WAF is defunct and it’s time to call in the undertakers.
WAF is dead, and DevOps killed it. Now’s the time to run a forensic analysis to figure out if your WAF has a pulse, or if you’re carrying a deadweight. Here are a few questions you should ask:
If you answered no to these questions, it is time for you to evaluate your cloud app security.
