What is the Difference Between NGWAF, WAF, and RASP?

Originally published July 14, 2016, this blog was updated with more relevant content April 29, 2020.

Evaluating security solutions can be a daunting endeavor. But fear not dear reader: I did not write this blog to sell you something. Rather, this blog will define the alphabet soup of application security technologies and their key differences that you, the buyer, must navigate as you evaluate various application security offerings.

With web apps being the top threat vector leading to breaches for over five years in a row application security is an imperative for every organization with a web presence servicing customers and partners with web apps and APIs.

What’s the most effective way to secure those apps and APIs?  I could write a very short blog and just tell you, “Make the investment in Signal Sciences to protect all your mission critical apps, APIs and microservices with unrivaled production visibility into how attackers are trying to abuse and manipulate your apps.” But that wouldn’t be a challenge and, again, I’m not writing this to sell to you. You’re reading this because you’re seeking clarity around various means to proactively protect your organization’s web layer assets.

Development velocity has changed. To be a force multiplier, application security must also.

Before I get to unscrambling the AppSec alphabet soup in the marketplace, we need to look at how dev teams design, build and deploy apps in the past and the present. Application development has been in state of change for the past decade as more companies adapt legacy apps to the cloud or design brand new cloud-native apps that harness the power and scale that the cloud affords them. So how we secure dynamic cloud-first apps has also evolved. Meanwhile, security has struggled to keep up with this new world of rapid release cycles. Choosing the right application security offering will make the difference between security being a blocker or an enabler to software delivery teams.

Demystifying the cloudy appsec alphabet soup

One of the hardest problems is keeping up with the acronyms security industry analysts devise. Further confusing the situation is that stakeholders will have a different definition of each technology and its attendant strengths and weaknesses. Hopefully the following will provide you with clarity around each of the major production web application security tools available.

Web Application Firewall (WAF): According to OWASP, WAF is an application server plug-in or filter that applies a set of rules to an HTTP request. These rules generally cover common attacks such as cross-site scripting (XSS) or SQL injection (SQLi).  By customizing the rules to your application you can identify attacks and block them.

The key here is the first part of the statement: an appliance or server plug-in or a filter.  But it gets grey when we start talking about virtual machines, network-based appliances or an application security control that’s software driven from a cloud provider.  What about a library that you embed into your code that automates input filtering input—isn’t that a web application firewall too? It gets very confusing very quickly.

Here’s the bottom line: not all WAFs are created equally. When evaluating a WAF, make sure you understand the underlying technology that powers the WAF. Legacy WAF vendors use an outdated, static technology called regular expression pattern matching that results in so many false positives that the operator usually puts these legacy WAF appliances (either virtual or hardware) into “monitoring/logging” mode, which provides no security value in production. I published an entire blog on the failings of legacy WAFs if you want more context here.

Runtime Application Self-Protection (RASP): This is an analyst-created term from our good friends at Gartner Research and it’s a security technology that links into an application runtime environment. In theory, the RASP module should be capable of instrumenting and observing an application as it executes and detects and prevents real-time attacks. This is a real benefit to app and API developers and security staff because a RASP can show you how the application is being attacked in production. Taking that feedback, developers can modify the code base to eliminate security vulnerabilities.

But as with WAF, not all RASP implementations are equal. We’ve had several customers tell us that they chose Signal Sciences over other RASPs for three essential reasons:

1. Flexible deployment: we offer several RASP modules that are specific to common programming languages such as Go, node.js, Java, .Net and others.
2. Efficacy: our protection works in production and uplevels actionable security data
3. Performant: works without negatively impacting app and API performance. This is where many RASP offerings fall down. Ours does not.

We have a very useful video available on what to consider if you’re looking for a RASP solution.

Next-gen Web Application Firewall (NGWAF): Signal Sciences was designed from the ground up to be a next-gen WAF and we’ve used the term for several years. True NGWAF is a reinvention of the legacy WAF but with a new approach to production app and API security:  it brings intelligent application context to the WAF model that we all know and detest for the above mentioned weaknesses.  A real NGWAF provides security intelligence and capability to protect the application, feeds actionable production security data to teams that need it, and empowers the DevOps lifecycle instad of hindering it and making security a blocker.

The real needs met by effective application security

There are a few criteria that a true proactive application security solution meets, so consider these as you work through a WAF or other application security tool evaluation process:

1. Security cost:  you want to make it expensive for attackers to go after your web layer assets, your sites, your APIs and services that power your applications.
2. Make it hard, if not impossible, for attackers to breach an application layer resource: You want an appsec tool for your production environment to make it significantly more difficult for attackers to gain access to sensitive data.
3. Truly automated and a force multiplier: business and security value is derived from technologies that both bring together the silos of your business: development and security ops. It bridges the gap between these silos. Application security has to be focused on production visibility and real-time attacks in a world where you don’t even own your infrastructure component.  Hardware is quickly becoming irrelevant as apps and APIs run increasingly in a virtual layer on top of managed hardware resources that are allocated based on usage.
4. Cloud-native friendly: Security stakeholders need technology that secures your application production environment no matter where they operate while augmenting your resources instead of making you add more people to support the technology that you buy. Also, does the solution inspect east-west traffic between microservices? Not all WAFs can — Signal Sciences can with native integrations with service meshes like Istio and Envoy.

Effective AppSec Tooling Powers the DevOps Lifecycle

Application security should be woven into what was traditionally a long development cycle of six to 24 months for each individual release of your web application (Waterfall SDLC anyone?). Development teams would gather requirements for what they’re building, go into a black hole for months and come back with a design that eventually is tested by a QA team and code issues supposedly fixed before release to production. Security was then essentially overlaid on the design process with a code review, pen testing, bug and vulnerability fixes, each acting as stage gates the security team had to sign off on

But modern application development has completely changed: agile, competitive companies no longer pursue long-drawn-out dev cycles any longer.  And young companies have thrown away that model and build their products using an agile lifecycle out of the gate.

Flexible, effective application security is not a blocker to innovation. That means choosing application security tooling that provides production visibility by inspecting web requests with additional context for precise decisioning that does not block legitimate users. If this is important to you, you owe it to yourself to request a demo of Signal Sciences.

You said you weren’t going to sell to me, pal.

I’m not because the proof is in the proverbial pudding: there are many reasons why four of five prospects who try our technology become customers.  You’ll experience an “aha!” moment from a visibility standpoint during a demo where one of our experts can show you how effective Signal Sciences is at protecting your apps and APIs without the debilitating negatives of legacy WAF and other RASP implementations.

Learn more about proactive web application security with these resources:

• Request a demo
• Blog: Why Customers Choose Signal Sciences
• Signal Sciences integrations