How RASPs and WAFs can work together

When it comes to security tooling, it can be difficult to tell different acronyms and the approaches they represent apart. In the case of application security for production applications, there are several approaches out there, some new and some old. Today, I want to focus on two prevalent means of monitoring and/or protecting applications: Runtime application self-protection (RASP) and web application firewalls (WAF). RASPs and WAFs are both more connected, and more different than it appears at first glance.

RASPs are an evolution of WAFs just like WAFs are an evolution of network firewalls: some concepts make it over, but most are different and what truly matters is what was unfathomable before.

How RASPs and WAFs are different

There are two large differences between RASPs and WAFs. The first one is where the data they’re processing is coming from.

Just like WAFs innovated by examining HTTP requests rather than TCP packets to bring a greater level of insight, RASPs raise the bar further. RASPs pull data from the application runtime, i.e. when there is no longer any ambiguity in parsing. The RASP runs on what the application is seeing, instead of what the application server receives, which makes virtually all obfuscation by attackers useless overnight.

Running on data from the application runtime with the classic WAF approach of pattern matching requests gives you an In-App WAF: definitely superior to a traditional WAF when it comes to application security, but still fundamentally similar (you would still be running patterns on request parameters). Modern RASPs differ in one additional, important way: by entirely ditching patterns.

This is the biggest difference between RASPs and WAFs: WAFs look for suspicious payloads, while RASPs look for exploitation attempts.

RASPs work by fetching the request parameters, but more importantly by catching the internal function calls your application is performing (such as to the SQL query executor) and gathering the parameters of the call. This means that the RASP is, in this context, not working solely with the request parameters, but also with the SQL query the application is trying to run and the precise context in which to run it. It can then run arbitrarily complex logic (such as a full SQL parser) to determine precisely what the user parameter is doing in the query and whether or not it is malicious.

What is fundamentally new here is that false positives are virtually impossible, and so are false negatives (bypasses): if the user parameter affects the query, no matter how complex or obfuscated, it will be flagged.

This is a significant shift in what you see as a security person. RASPs won’t show you odd-looking requests, but will detect every single attempt to exploit a vulnerability. This is the biggest difference between RASPs and WAFs: WAFs look for suspicious payloads, while RASPs look for exploitation attempts. A RASP isn’t a better WAF anymore than a WAF is a better network firewall: it’s something new with completely different properties, different strengths, and different weaknesses.

How RASPs and WAFs complement each other

RASPs are not an unmitigated improvement over WAFs in every regard: they are different. However, they are complementary. The strength of RASPs, when combined with WAFs, let them both shine.

Specifically, the issues that plagued legacy WAFs (i.e. false positives, excessive noise) are rooted in the fact that the WAF is used as a protection tool. As a protection tool, it must catch every single malicious payload or it will let an attack pass through. If a WAF can rely on the RASP to take care of the protection, they can move to what patterns are best suited for: detecting oddities in large volumes of traffic. WAFs are great monitoring tools, but mediocre protection tools. 

The strength of RASPs (i.e. no false positives/negatives) is also a weakness when looking at a general security solution: RASPs won’t tell you anything about your app until it averts disaster. This is definitely better than the opposite (alerting you and being unable to avert disaster), but security teams can take measures to stop attackers earlier in the process if given warning. This is where WAFs (and their reduced maintenance cousins, In-App WAFs) come in. Through their pattern matching capabilities, they can warn the security team about noisy attackers before they hit an exploit. If implemented well with a restricted set of patterns, they won’t catch every malicious payload, but still enough to raise an alarm. This lower level of sensitivity comes with much lower rates of false positives.

This is all assuming two independent tools, but integrations can bring tremendous advantages. For example, the RASP can let the WAF know which fields are used in SQL queries and therefore warrant a higher level of sensitivity. A WAF can flag some parameters as suspicious and make sure that no matter what, the RASP will keep an eye on them (as a performance optimization). Both of those data streams would be way too noisy if exposed directly to the security team, but as simply an input to each other’s logic, they tolerate a very high level of false positives without negative impact.

Conclusion

If the only thing you’re interested in is protecting your application from attacks, then a RASP is a great solution that will cover your back without requiring maintenance or your attention unless it just saved your neck. For this use case, WAFs were never a good fit and are now completely obsolete.

However, if you have a security team looking to protect a broader system, a standalone RASP will be lacking contextual insight about the general activity of your app. Here, a WAF with a permissive configuration can provide a useful sample of traffic to let a security team understand which applications are being attacked and thus warrant attention from the security team.

An integrated product will, of course, offer opportunities unavailable to independent solutions, while separate products will be more focused. However, what is important is to make sure that each focus on their strengths: RASPs should protect, while (In-App) WAFs should monitor. Any attempt to stray outside those specialties results in compromise and a weaker result.

If you’re interested in exploring how an integrated RASP and In-App WAF solution works for your apps, check out a free trial or a demo of Sqreen.