Authored by: TJ Gonen, Head of Cloud Solutions, at Check Point Software Technologies
With the introduction of the Model T Ford in 1908, the world’s first mass-produced vehicle. Henry Ford was on a quest mobilise 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 personalisation 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 personalisation across everything from apparel to digital experiences.
For the many user experience (UX) teams relentlessly pushing the personalisation 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 (WAFs).
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.
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 couldn’t 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 might lull AppSec teams into a false sense of security, leaving their apps and micro-services open to attack.
The truth is, WAFaaS offerings are not customised to the needs of the application it is protecting. This re-incarnation 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, the 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 might sound like a decent solution for a cloud application, the truth is, each new micro-service isn’t going to be automatically protected as soon as it’s deployed, and that means risk.
Most worryingly 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 a 3rd 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 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.
0 Comment Log in or register to post comments