WAFaaS: When ‘As-A-Service’ Means ‘Bad Service’
In 1908, Henry Ford introduced the Model T – the world’s first mass-produced vehicle. In his quest to quickly mobilize Americans, Ford famously quipped that the car was available to his customers “in any color they’d like so long as it’s black,” The lack of variety or personalization options certainly did not stop potential buyers from purchasing their first automobile.
Compare Henry Ford’s unapologetic approach to consumer expectations in 2021 and it’s hard to imagine that it’s only a little more than a mere century later.
Consumers now expect personalization across everything from apparel to digital experiences.
Behind the many UX teams relentlessly pushing the personalization envelope to delight consumers, there are many DevOps teams continuously testing and deploying new code to create innovative, robust applications. Not surprisingly, these applications also must be secure.
Security for dynamic, cloud-native applications is a challenge exacerbated, however, by existing tools like traditional web application firewalls (WAFs).
Application security has been the bane of the security community for many years. Applications in the 1990s were simple, monolithic applications with monthly updates – if the development team could scale up development quickly enough. Application security was an afterthought; to allow developers and QA teams to keep moving, security was generally implemented on the perimeter, and security maintenance consisted of a list of known attack signatures, against which a WAF would be able to make a binary decision based on each web request. When a request came in, the WAF tried to find a match in the attack signature database and, if there was a hit, the request was denied.
The WAF market’s one-size-fits-all approach worked relatively well until the advent of cloud computing, when DevOps effectively rendered the WAF useless. As AppSec vendors tried to automate security in the same way that DevOps automated development, it became clear that legacy WAFs were unable to handle the rapid pace of development.
So began the shift to WAF-as-a-Service (WAFaaS). Under the guise of automation, security vendors began to offer a legacy WAF “without the headaches” in which they provided AppSec teams with a WAF that they didn’t need to manage – usually delivered via templates/wizards. These offerings claimed to offer blanket security for any application.
But the reality is that WAFaaS offerings are just as ineffective as legacy WAFs when it comes to protecting cloud-native applications. In fact, using a WAFaaS might be lulling AppSec teams into a false sense of security, leaving their apps and microservices open to attack.
The truth is, WAFaaS offerings are not customized to the needs of the application it is protecting – this reincarnation of a traditional WAF does not provide the ability to automatically adapt with application updates. Without a deep understanding of the application, its content and its users, the WAFaaS inevitably provides a lower level of security in a quest to prevent false positives.
Additionally, WAFaaS is still not native to the cloud environment. Without the ability to deploy security-as-code (whether in K8s, for serverless functions or using an agent), WAFaaS provides a suboptimal security solution that is not native to the environment it’s protecting.
There is also the minor problem of real automation. With the loss of the network perimeter, each microservice becomes a perimeter in and of itself. WAFaaS might sound like a decent solution for a cloud application, until you consider the question: will each new microservice automatically be protected as soon as it’s deployed? Uh-oh.
Most worryingly for AppSec teams using a WAFaaS to protect a cloud-native app, is that a WAFaaS can only protect the app from direct web traffic. In a distributed microservices environment, the WAFaaS cannot see much of the app traffic; much less protect the app from attack. With the proliferation of APIs, the application attack surface has grown, and WAFaaS cannot protect against any traffic that comes in via a third-party API integration. Nor can the WAFaaS provide protection where there are microservice-to-microservice communications. For cloud-native applications, this means that WAFaaS is not fit-for-purpose.
Cloud-native applications can only be protected by cloud-native security that automatically adapts to application changes. AppSec teams must understand that, in the disparate microservices environment, the application is a sum of all of its parts and as such, any security solution has to protect each asset. With no two apps built the same, cloud-native applications need cloud-native security solutions, which do not rely on a one-size-fits-all approach.
The traditional WAF was an important tool to protect the nascent applications of the 1990s. Much like the Model T Ford, which brought private transportation to the masses, the WAF introduced application security to the masses with a solution that was configurable back when no one was too worried about hourly app updates and automated deployments. Unfortunately, that time is now long past.
