Web application firewalls (WAFs) are one of the most commonly used tools that organizations deploy to protect their applications at runtime. By monitoring HTTP traffic and filtering out suspicious requests, WAFs act as a protective layer around an application that protects it from certain types of incoming threats.
However, WAFs often fall short of expectations. These solutions filter traffic based on specific rules that can be difficult to correctly tune—if the rules are overly sensitive, teams often struggle with false positives, but if they are too permissive, the WAF may not adequately detect and block threat actors.
In this post, we’ll discuss why security teams often run into issues with their WAFs and show you how Datadog can help you make the most of your WAF’s many strengths. We’ll cover:
- The three main goals of WAFs
- What keeps WAFs from fulfilling their goals
- How Datadog Application Security Management (ASM) can help
The three goals of WAFs
While there are many types of threats facing web applications, WAFs are designed to tackle three main goals for threat detection and prevention:
- DDoS protection: The simplest way for an attacker to cause harm to applications with very little effort is to overwhelm them with traffic through a distributed denial of service (DDoS) attack. There is a large industry of shady providers that offer to “test how your application will react to load” but actually provide outsourced DDoS services for attackers, and threat actors can deploy these networks against victim applications on a whim. WAFs are a common solution for mitigating this type of attack, as they can detect and block traffic spikes of this scale.
- Visibility into the threat landscape: There is only so much time in a day, and defenders need to focus their attention on the most relevant threats and the most targeted classes of vulnerabilities. WAFs can help you gain this context by revealing what types of attacks target your applications most frequently. A WAF may not detect every threat, but it’ll catch enough to tell you that you were just scanned for SQL injections, for example. You can use these insights to form a picture of the attack landscape and defend your application against it.
- Exploit prevention: If there is a vulnerability in your application, you want to prevent attackers from discovering and exploiting it before you have a chance to remediate the issue. Once the attacker notices the vulnerability, they’ll focus their efforts on exploiting it, deploying obfuscation and stealth to try to break into your system. Because WAFs work by detecting suspicious patterns of web vulnerability exploits—such as cross-site scripting (XSS) and SQL injection—in incoming traffic, they’re quite vulnerable to this obfuscation.
For each of these goals, the importance of detection needs to be balanced with the impact a false positive may have. For example, you wouldn’t want to block normal users having a discussion about SQL code on a public forum. Moreover, excessive noise can dilute WAF alerts so heavily that they become useless. This leads to a tricky balance where the WAF needs to be configured strictly enough to block targeted, stealthy attempts at exploiting vulnerabilities, while being permissive enough not to block legitimate usage.
What keeps WAFs from fulfilling their goals
WAFs have historically struggled to achieve this balance—they require teams to configure detailed rules to detect threats on various routes and parameters within an application without blocking legitimate activity. Sometimes, these configurations can be automated, but overworked security teams often end up managing them manually. This results in large detection gaps, slow rollout of blocking capabilities, and massive toil inflicted on the security team.
While WAFs provide an important service, these limitations—which are inherent to their design—can create gaps in threat detection coverage and result in frustration for security teams. Let’s look more closely at how WAFs fare in their three primary tasks:
DDoS protection: good
Effectively protecting against DDoS attacks means detecting and blocking malicious requests in the least amount of time possible to prevent the application from becoming overwhelmed. Content delivery networks (CDNs) like Cloudflare have historically positioned themselves successfully in this segment, since they can neutralize malicious traffic upstream of your systems. However, if a CDN can’t catch the attack, or if your organization is not using one, a WAF is a good alternative. WAFs have visibility into inbound traffic at a granular level, are easier to scale up than your services themselves, and spend less time interpreting a malicious request before rejecting it than the application server will.
Visibility on the threat landscape: great
WAFs are excellent when it comes to understanding an application’s threat landscape, as they are designed to look for suspicious incoming payloads. For this use case, false positives aren’t as significant an issue—here, we’re talking about gaining visibility into attacks rather than actively blocking them. Moreover, even if some requests slip through by using obfuscation techniques, the WAF will catch enough to determine that an attacker is scanning your application for vulnerabilities and identify what they are interested in.
Exploit prevention: poor
WAFs have no special insight into potential vulnerabilities in your application, or whether the route being called by a suspicious request even exists. The best they can do is block based on the rules they are configured to enforce. However, to defeat obfuscation, those rules often have to be quite aggressive, which leads to a high rate of false positives. It is possible to use WAFs for virtual patching—i.e., deploying aggressive patterns on specific routes and parameters that you know to be vulnerable in your application—but most WAFs aren’t optimized for this use case, and you still need to tell them about the vulnerability.
Overall, WAFs function well for most of their intended purposes, but exploit prevention is the main area where they fall short.
How Datadog ASM can help
Datadog ASM includes an In-App WAF that enables you to detect and block suspicious application requests based on known patterns of attacker behavior.
While not a one-to-one replacement for a traditional perimeter WAF that catches suspicious requests before they reach the application server, ASM’s In-App WAF—along with a range of threat detection and prevention capabilities—can be used in conjunction with third-party WAFs for a complete defense-in-depth approach. Let’s look at how you can use ASM to take full advantage of a traditional WAF’s strengths and address the areas where a WAF may fall short.
DDoS protection
By virtue of being in-app, ASM’s In-App WAF isn’t truly able to catch and block DDoS attacks, because its libraries only see a request after it’s been interpreted by the application server. If you’re using ASM, you’ll want to use one of our network WAF integrations to secure your application’s perimeter from DDoS attempts—a use case that is well-handled by traditional WAFs and CDNs.
Visibility into the threat landscape
As discussed earlier, WAFs are very good at helping you understand what kinds of attacks are targeting your application. Datadog ASM extends this strength even further: Because its In-App WAF reads parameters as they are interpreted by the application, the obfuscation techniques that an attacker will be able to use to evade detection are greatly degraded, significantly increasing accuracy. This lets ASM be more conservative with its ruleset, resulting in fewer false positives and giving you a more complete picture of the threat landscape.
Exploit prevention
This is the area where traditional WAFs are the weakest—and where Datadog ASM offers the most significant improvement for defense in depth. ASM includes Datadog Exploit Prevention, which instruments your application at a deep level in order to identify when an attack is attempting to exploit a specific vulnerability. This approach doesn’t rely on WAF patterns but instead on the semantics of the operation performed by the application—for example, it can detect not only a suspicious-looking parameter but also that a request was modified, which means an injection has taken place. This technique helps avoid false positives and false negatives. In addition, Exploit Prevention can block identified attack attempts before the exploit is executed.
Extend your WAF’s strengths with Datadog ASM
The main pain points that security teams experience when operating WAFs tend to come from trying to use WAFs to do the one thing they’re poorly suited for: exploit prevention. Technologies such as ASM’s Exploit Prevention are the missing piece to let WAFs specialize on what they’re great at.
Check out our documentation for Datadog ASM and Exploit Prevention to see these capabilities in action. If you’re not yet a Datadog customer, sign up for a 14-day free trial.
