Why WAF Rate Limiting isn't Enough | Impart Security (2024)

Some WAFs in the market offer rate limiting features designed to stop automated APIattacks. They do this by implementing a centralized control plane with shared state and counters in the cloud to enable over time detections. However, these solutions still struggle with the unique challenges posed by API attacks, leaving customers frustrated enough to post about in on reddit:

The problem with many WAFs is that they are not architected to handle high volumetric attacks because they are over-reliant on a cloud control plane. Let’s take an example of a typical legacy agent based WAF based on this type or architecture:

Cloud based detections are too slow

First, WAF agents rely on the cloud to detect attacks. WAF agents are thin clients – they run some basic detections and then forward metadata to the cloud in order to optimize for performance and latency. However, this approach means that any behavioral based detections (again, going back to the credential stuffing example) can only be detected in the cloud, and not locally at the agent because the agent does not have state or awareness of what is happening. Attackers can take advantage of this type of system by sending attacks in at high rates in a distributed manner, getting in high volumes of attacks before the agents can check in with the cloud.

The Cloud is a single point of failure

Second, legacy agents have a single point of failure when it comes to detection – the cloud. Because all the state is stored in the cloud, if the cloud goes down then all behavioral based detections stop working as well, as does any blocking and threat mitigation of these types of attacks.

Impart has decentralized the agent

We designed Impart from the ground up to solve these problems using a next generation decentralized architecture – an agent mesh. Unlike traditional distributed systems which utilize a hub and spoke architecture (centralized control plane, distributed data plane), Impart is designed as a completely decentralized system that does not require a central control plane.

Instead of using centralized cloud communications to share and distribute state, our agents can share state directly with each other, as well as with the cloud. The agents can also elect a leader to check in with the cloud so that not every agent has to update the cloud with the shared state, which is more efficient from a load perspective.

‍

What this means for security teams is two things:

Faster detection and response

First, Impart is able to detect and respond to attacks much more quickly than solutions based on legacy agents because we are not reliant on a round trip check in with the cloud to share state. In the example provided above, when a single inspector (our agent) detects an attack, it immediately shares this information with other agents in it’s group. This allows all the agents to know when a single agent is experiencing an attack, and drastically reduces the time to detect an attack such as credential stuffing.

This matters in the real world. Credential stuffing attacks are typically rapid, with attackers using off-the-shelf automation tools to generate and send numerous requests in a short time. Speed of detection is crucial in these scenarios. In a recent deployment, Impart was deployed alongside a legacy agent based WAF and found that the it was not identifying or respond to prolonged attacks quickly enough. Thousands of credential stuffing attacks per hour slipped through before the legacy agent based WAF could react, whereas Impart identified and acted on these attacks almost immediately.

Improved resilience and availability

Second, Impart is able to withstand an outage to the cloud without impacting behavioral detections, or reporting and analytics. If the cloud has a problem, detections continue with all relevant metrics being captured and shared amongst all of the agents. Whenever the cloud returns to normal, all of that shared state can be backfilled by the agents to the cloud, or sent locally by those agents to the customer’s SIEM. This matters because most enterprises don’t want to pin the reliability of their security tooling to the reliability of a single cloud provider. With this type of architecture, a customer’s detection and response capabilities remain intact no matter what is going on in their WAF’s control plane.

Reflecting on our journey at Impart, it’s clear that the landscape of API security requires innovative solutions. Traditional WAFs, with their cloud-dependent architectures, simply can’t keep up with the fast-paced, automated nature of modern API attacks. Our distributed control plane approach not only accelerates detection and response times but also ensures resilience even during cloud outages. It’s been incredibly rewarding to see how our solution makes a real difference in protecting businesses from API threats.

If you want to learn more about our unique approach, sign up for a demo today!

‍

‍

‍