Rethinking Web Application Firewalls – The New Stack

Web application firewalls (WAFs) first appeared in the late 1990s as web server attacks became more common. Today, in the context of cloud-native technologies, there is a constant rethinking of how a WAF should be applied.

It’s not just about static applications behind a WAF anymore, said Tigera CEO Ratan Tipirneni, President and CEO of Tigera in this episode of The New Stack Makers.

“With cloud-native applications and a distributed microservices 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 almost every microservice container is open to the internet, metaphorically speaking.

So the question is how to apply WAF controls?

Today’s WAF should be workload-centric, Tiperneni said. According to him, each workload should have its own WAF. When a container is launched, the WAF control is automatically launched.

So 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 need to think in terms of a workload-centric WAF.

The scenario

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

“It’s no longer enough to issue a report that informs you of all the vulnerabilities in your system,” Tiperneni said. “Because this report is not usable. The people running the services find that the time and effort it takes to fix all of these vulnerabilities is incredible, isn’t it? So they are looking for some level of prioritization in terms of where to start. »

And it’s up to the user to mitigate the problem, Tiperneni said. These customers need to think about the vulnerability’s explosion radius and its context in the system. The second part: How to manage the attack surface.

In this world of cloud-native applications, customers very quickly discover that trying to protect everything, when everything has access to everything else, is a nearly impossible task, Tiperneni said.

What is needed is a way for users to control how microservices communicate with each with set permissions for pass-through. In some cases, specific microservices shouldn’t talk to each other at all.

“So this is a high-leverage security activity and control that can stop many of these attacks,” Tiperneni said.

Even after all of this, the user still has to assume that attacks will occur, mainly because there is still the threat of an insider attack.

And in this situation, the search looks for abnormal behavior patterns at the process level, at the file system level or at the system call level to determine the basis of the standard behavior which can then tell the user how to identify the deviations , said Tiperneni. Then it’s about trying to disentangle certain signals, which are indicators of either an attack or a compromise.

“Perhaps a simpler use case is to be able to constantly monitor and monitor at runtime for known bad hashes or files or binaries, which are known to be bad,” Tipirneni said. .

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

“There is no single silver bullet,” Tipirneni said. “There are several things you need to be able to do to keep your application secure in cloud-native architectures.”

Band Created with Sketch.

Comments are closed.