Rethinking Web Application Firewalls

Web Application Firewalls (WAF) first emerged in the late 1990s as webserver attacks became more common. Today, in the context of cloud native technologies, there’s an ongoing rethinking of how a WAF should be applied.

No longer is it solely static applications sitting behind a WAF, said Tigera CEO Ratan Tipirneni, president and CEO of Tigera in this episode of The New Stack Makers.

“With cloud native applications and a microservices distributed architecture, you have to assume that something inside your cluster has been compromised,” Tipirneni said. “So just sitting behind a WAF doesn’t give you adequate protection; you have to assume that every single microservice container is almost open to the internet, metaphorically speaking.

So then the question is how do you apply WAF controls?

Today’s WAF has to be workload-centric, Tiperneni said. In his view, every workload has to have its own WAF. When a container launches, the WAF control is automatically spun up.

So that way, even if something inside a cluster is compromised or exposes some of the services to the internet, it doesn’t matter because the workload is protected, Tiperneni said.

So how do you apply this level of security? You have to think in terms of a workload-centric WAF.

The Scenario

The vulnerabilities are so numerous now and cloud native applications have larger attack surfaces with no way to mitigate vulnerabilities using traditional means, Tiperneni explained.

“It’s no longer sufficient to throw out a report that tells you about all the vulnerabilities in your system,” Tiperneni said. “Because that report is not actionable. People operating the services are discovering that the amount of time and effort it takes to remediate all these vulnerabilities is incredible, right? So they’re looking for some level of prioritization in terms of where to start.”

And the onus is on the user to mitigate the problem, Tiperneni said. Those customers have to think about the blast radius of the vulnerability and its context in the system. The second part: How to manage the attack surface.

In this world of cloud native applications, customers are discovering very quickly, that trying to protect every single thing, when everything has access to everything else, is an almost impossible task, Tiperneni said.

What’s needed is a way for users to control how microservices talk to each with permissions set for intercommunication. In some cases, specific microservices should not be talking to each other at all.

“So that is a highly leveraged activity and security control that can stop many of these attacks,” Tiperneni said.

Even after all of that, the user still has to assume that attacks will happen, mainly because there’s always the threat of an insider attack.

And in that situation, the search is for patterns of anomalous behavior at the process level, at the file system level or the system call level to determine the baseline for standard behavior that can then tell the user how to identify deviations, Tiperneni said. Then it’s a matter of trying to tease out some signals, which are indicators of either an attack or of a compromise.

“Maybe a simpler use case of that is to constantly be able to monitor and monitor at run time for known bad hashes or files or binaries, that are known to be bad,” Tipirneni said.

The real challenge for companies is setting up the architecture to make microservices secure. There are a number of vectors the market may take. In the recording, Tipirneni talks about the evolution of WAF, the importance of observability and better ways to establish context with the services a company has deployed and the overall systems that companies have architected.

“There is no single silver bullet,” Tipirneni said. “You have to be able to do multiple things to keep your application safe inside cloud native architectures.”