WAF + ASM: Full Protection for Your Running Application
Contrast built and marketed Contrast Protect as a “WAF killer;” a better, more accurate and scalable way to protect your web applications in production. However, our customers told us something completely different. Specifically, they told us the following:
- They think their WAF is a worthwhile investment and don’t plan to get rid of it
- But, there are limitations – WAFs:
- Miss “hard to signature” attacks
- Generate alert fatigue
- Provide no data beyond the HTTP request
- Require constant tuning (especially with frequent code changes) and,
- Are difficult to scale to cloud deployments
- They are looking to Contrast to address these limitations and complement their WAFs
That is why Contrast Application Security Monitoring (ASM) was born – a solution for customers to leverage their WAF investment, but address their pain points, all without adding head count and making their SOC more productive and responsive to application-layer attacks. One customer said it best: “We’re not getting rid of it (their WAF) but we only have six people in our SOC with hundreds of WAF alerts. We are using Contrast Protect to give our SOC more context and zero in on which WAF alerts are important. We then use Contrast’s attack data to tell dev teams what to remediate.” With their WAF and Contrast Protect, our customer has full Application Security Monitoring. READ THE ASM BRIEF >>
A WAF is a Worthwhile Investment to Many of our Customers
Historically, the WAF became popular as the first dedicated protection for the web application layer. According to Securosis, Intrusion Detection Systems (IDS) and general-purpose network firewalls are poorly suited to protecting the application layer, and remain largely ineffective for that use case. In order to detect application misuse and fraud, a security solution must understand the dialogue between application and end user. WAFs were designed for this need, to understand application protocols so they can identify applications under attack1.
But, WAFs have endured for the following reasons:
1. As a cost-effective way to comply with PCI DSS section 6, especially since the regulation specifically prescribes WAFs as a method to address the control.
In addition, the PCI Security Standards confirms this in the supplement released to clarify PCI DSS 6.6 requirements:
Requirement 6.6 Option 2 – Application Firewalls2
In the context of Requirement 6.6, an “application firewall” is a web application firewall (WAF), which is a security policy enforcement point positioned between a web application and the client end point. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components.
2. It is seen as an easier way to protect an application than building security into the application itself. Specifically, given the historically contentious relationship between engineering and security teams, WAFs became a less interventional way to secure the production environment of an application. This is especially relevant when protecting legacy applications that may have limited to no engineering resources to build security controls into the application or fix vulnerabilities in source code.
3. WAFs are effective protection against layer 7 (application) distributed denial of service (DDoS) attacks.
4. Customers need the WAF infrastructure anyway to run their content delivery network (CDN). In these cases, our customers purchased the WAF from a CDN vendor.
For the reasons above and the historical lack of alternatives (and some healthy sunk-cost bias), WAFs will endure for the foreseeable future. And, so will their limitations.
Yes, WAFs have Key Limitations but...
Sources:
https://securosis.com/blog/maximizing-value-from-your-waf-new-series
https://www.pcisecuritystandards.org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf