A Brief History of AppSec

In the beginning, there were just firewalls. Then there were next generation firewalls. Then there were WAFs. AppSec people were ecstatic. Finally a tool that understood their HTTP-based applications and could try and catch the bad guys on the way in.

Then the RASPs started showing up. Protection from the edge makes no sense when you could be present right where the attack is about to happen, and not way back where the malicious payload first enters the system. 

RASP vendors touted the benefits of the added context that RASPs have, both to catch more attacks, and to improve accuracy. For example, a RASP is less susceptible to complex encoding schemes to mask malicious data. A WAF will surely be looking for ‘ 1=1 (the classic SQL injection example). It might even be looking for %27%201%3D1 (the same payload URL-encoded). But it might not catch %2527%25201%253D1 (double encoded), while your application might still be susceptible to this payload. 

Since a RASP is looking at the data as it’s actually being used deep in the application, any strange encodings were probably already decoded. Similarly, since it’s evaluating the data in the context of use, it will only block the request if that payload is actually being used in a SQL-query.

WAF vendors, on the other hand, will fire back that WAF catches attacks earlier, before the data has made it deep into the application. Additionally, they will claim that detecting malicious patterns that don’t result in an attack is a benefit, as these still indicate an attempt by an attacker, and can be used to improve security. An example for that is blocklisting the source IP of the unsuccessful attack.

Which Should I Choose?

That’s a common question from security practitioners. If I have a WAF, do I need a RASP solution as well? If I deployed a RASP solution, can I get rid of my expensive WAF?

The typical answer to this question is keep both. Security is a game of layers, and having redundant security tools makes life more difficult for attackers.

This is, of course, a somewhat naive answer. For one, it ignores the direct and indirect costs of both solutions. If you’re running a RASP solution, perhaps you could save money by dropping the WAF, and repurpose that budget to solve some other security worry. If you’re happy with your WAF, perhaps running RASP is adding additional latency to your application that can be avoided.

You’re Asking the Wrong Question…

For a modern application, RASP vs WAF is the wrong question to begin with. Protecting your application from the outside perimeter is not going to be sufficient in any case. Modern applications are fragmented, distributed, and use a multitude of managed resources, so figuring out where your WAF should sit is an exercise in futility.

Traditional RASPs don’t do much better, as they are not suited for correlating signals from distributed applications and they don’t understand the structure and flow of your application. ProtectOnce’s application security solution brings a seamless, perimeterless zero-trust solution to each part of your application, providing the benefits of WAF-like filtering at the entrance and exit of each microservice or workload along with the in-context protections of RASP-like solutions.

So you no longer need to choose between the solutions, but rather you need to choose a modern solution that embodies both types of security in a single seamless integration.

You’re Still Asking the Wrong Question…

When you build a solution that incorporates WAF-like and RASP-like technologies in a single in-workload solution, you start to realize that it’s not a WAF vs RASP question at all. The question we need to be asking is how much can we gain by having these technologies together. Not simply by layering multiple solutions. That’s too easy an answer.

What you realize is that these two technologies can complement each other if they are part of a single fluid system. For example, when ProtectOnce detects an attack using a RASP technique, the ProtectOnce backend can update all the other workloads that are exposed to the outside world to be on the lookout for the same attacker.

Even more powerfully, the WAF and RASP solutions can work together to help decrease false positives. WAFs, for example, are often configured to block various SQL-injection patterns. Some of these patterns (Robert’); DROP TABLE students;–, for example) might be clearly malicious, and blocking them is a no brainer. But others (–1234567, for example) might or might not be malicious. The incoming WAF-filtering capabilities in ProtectOnce can calibrate the RASP solution whenever such a borderline case is discovered, helping the RASP solution decide if an attack is sufficiently malicious to block.

Of course, it’s difficult to imagine reaping these benefits with traditional RASP and WAF solutions. Moving to a modern, workload-level perimeterless solution, which forced us to move WAF and RASP into a single package, serendipitously creates these new opportunities to further improve application security.