Such applications can only be protected by cloud native security that automatically adapts to application changes, argues this expert.

With the introduction of the Model T Ford in 1908, the world’s first mass-produced vehicle. Henry Ford was on a quest mobilize Americans. During this time, Ford famously quipped that the car was available to his customers “in any colour 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.

Henry Ford’s unapologetic approach would never have worked today, as consumers now expect personalization across everything from apparel to digital experiences.

For the many user experience (UX) teams relentlessly pushing the personalization envelope to delight consumers, there are just as many DevOps teams continuously testing and deploying new code to create innovative and robust applications. Unsurprisingly, it is important that these applications are secure. Yet security for dynamic cloud native applications continues to be a challenge that has been exacerbated by existing tools like traditional web application firewalls (WAF).

Application security has been the bane of the security community for years. Applications of the ‘90s were simple and monolithic and came with monthly updates if the development team could scale up development quickly enough. Application security was an afterthought and—to allow developers and QA teams to keep moving—was generally implemented on the perimeter.

With a list of known attack signatures, a web application firewall (WAF) would be able to take a binary decision based on each web request. This meant when a request came in, the WAF tried to find a match in the attack signature database and, if there is a hit, the request was denied.

Cloud computing and WAF

This one-size-fits-all approach worked relatively well until the advent of cloud computing when DevOps effectively rendered the WAF useless. The speed at which apps were being updated had accelerated and the WAF with its manual approach just could not keep up. As AppSec vendors tried to automate security the same way that DevOps automated development, it became clear that legacy WAFs were unable to handle the rapid pace.  

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 headache”: WAFs that came with templates or wizards that were supposed to offer blanket security for any application without the need for AppSec teams to spend too much time managing. 

But it has become clear that these WAFaaS offerings are just as ineffective as legacy WAFs when it comes to protecting cloud native applications. On the contrary, using a WAFaaS may lull AppSec teams into a false sense of security, leaving their apps and micro-services open to attack.

WAFaaS: not cloud native

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 auto-adapt with application updates. Without a deep understanding of the application, its content and users, WAFaaS inevitably provides a lower level of security to prevent false positives.

Additionally, WAFaaS is not built into the cloud environments natively. This means that there is no ability to deploy security with the code (whether in K8s, for server-less functions or using an agent), and traditional WAF offerings to these environments provides suboptimal security. 

There is also the minor problem relating to real automation. With the absence of the network perimeter within the cloud environment, each micro-service ends up becoming a perimeter in and of itself. And while WAFaaS may sound like a decent solution for a cloud application, the truth is, each new micro-service is not going to be automatically protected as soon as it is deployed, and that means risk. 

More worrying for AppSec teams using a WAFaaS to protect a cloud native app is the fact that a WAFaaS can only protect the app from direct web traffic. In a distributed micro-services 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 third party API integration. Neither can the WAFaaS provide protection where there are micro-service to micro-service 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 micro-services environment, the application is a sum of all of its parts: 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. 

In the 1990s the traditional WAF was an important tool to protect nascent applications. 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.