Welcome to the second part of this series examining some of the myths that I’ve heard in many conversations around Interactive Application Security Testing (IAST) and Runtime Application Self-Protection (RASP) while working at Contrast. Over the past four years, I have had the pleasure of discussing RASP with both open-minded individuals and Web Application Firewall (WAF) traditionalists and found that both groups often make incorrect assumptions and assertions about how RASP works. Let’s drill into some of those common myths.
Click here for a look at the myths around IAST.
Myth #1: A RASP is a RASP is a RASP
The term “RASP” was initially coined by Gartner in 2012 and is defined as “a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.” The category is extremely broad, and there have been a surprising array of different implementations of RASP. There are some providers who offer RASP as a Java Virtual Machine (JVM) replacement, some who consider RASP as a host-level firewall and some who operate RASP as an application-layer firewall. The industry has coined many fancy terms that can make RASP a bewildering category for buyers, many of whom I imagine have become increasingly confused with each booth conversation at their favorite conference.
Let me try to simplify RASP from a Contrast perspective: Our recipe to add RASP to the platform was super easy!
- Step one: start with an existing instrumentation agent that is already armed to the teeth with deep security knowledge of languages, frameworks, sources and sinks.
- Step two: Add some sensors to detect if the application is doing something unusual… and you’re done!
Of course, I’m kidding, and I hope our engineering team is still reading! Even if it was a little more complicated than that, Contrast has spent the last eight years road-testing our RASP agent across tens of thousands of real business apps, optimizing the performance and constantly improving the robustness of the ruleset. Think about it: What is the first thing our curious customers do when detecting a new vulnerability or hearing about a new zero day? They turn on RASP to see if it’s blocked. I do the same. It’s kinda fun!
In all seriousness, though, I honestly don’t know how you’d approach building a RASP solution today without the benefit of starting with IAST.
Myth #1 is busted: RASPs are different. If you’ve tried RASP, then you’ve tried a RASP.
Myth #2: RASP is like a WAF but closer to the app
Although there is some overlap between use cases for these technologies, the way they provide protection is fundamentally different due to how they are implemented. WAFs are deployed in front of an application, acting as a gateway to determine if requests should be allowed though (or alerting if anything looks remotely nasty).
This differs from Contrast Protect, which operates with the full context of the running code. This means that it doesn’t matter whether you encode, obfuscate or smuggle your payload: The RASP agent will still see what the application is doing with the data. Almost all the rules within the RASP agent operate deep within the request execution cycle, because the agent does not want to over-block. Rather, the agent prefers to check whether the payload would be successful before raising the alarm. This means that our RASP solution provides a dramatic reduction in alerts, helping the security team focus on what matters. What’s more exciting about this, though, is that RASP is providing you with something you can realistically act on, highlighting a vulnerable piece of code or a library that your development team can remediate.
Myth #3: RASP can replace WAF
It would be remiss of me to assert that RASP can always replace WAF technology, as there are some types of attacks or traffic that WAF is more capable of handling. The first and most obvious one is application layer denial-of-service (DoS) attacks. In such a scenario, RASP is a little late to the fight, as your application is busy trying to serve requests. The second use case is about reserving your infrastructure for paying customers. You may be trying to prevent some traffic from some sources — such as botnets — from even reaching your application, helping you to manage your cloud bill. RASP cannot help you with either of these scenarios, so you’re probably going to still need a WAF if they keep you up at night.
Myth #4: RASP requires tuning, just like a WAF
The task of tuning a WAF is twofold: You’re either adding rules to increase protection or refining rules to prevent false positives. Very often, I’m asked about the tuning options for our RASP agent, and frequently there is an incorrect assumption that you need to run IAST first for the agent to “learn” about what needs protecting.
The truth is, you can deploy our RASP agent without any tuning on an application that it just met for the first time. If you are anxious about blocking legitimate traffic, then just set it to monitor: That will quite clearly highlight anything that would have been stopped if blocking were enabled. Don’t expect this to be a mammoth task. Remember that RASP can detect whether your application is truly vulnerable, so the number of alerts you need to triage will be minimal.
There is also a key point to be made here about the portability of RASP. Application development teams have a considerable number of options when it comes to deployment, and security teams are struggling to keep up. If you do make any changes to RASP configuration, then you’re only doing it once, meaning that protection from RASP will be predictable and consistent across all your cloud or datacenter deployments.
Myth #5: RASP still requires signatures to prevent exploitation
I could dispel this one with a single word: Log4Shell. Those who followed our blog during the events that unfolded late last year know that Contrast Protect was able to prevent exploitation of this vulnerability without requiring any tuning or new signatures. This is because a RASP does not rely on signatures to prevent exploitation of your application and instead looks at the application's behavior. This highlights a very important difference between the technologies: WAFs are designed to block known threats, whereas RASP can defend against both known and unknown threats.
Summary
With every notable development in the Application Security (AppSec) industry, an age-old debate reignites within the four walls of Contrast about prevention vs. protection. There are those who advocate shipping well-reviewed code and clean libraries to production, but last year’s developments around Log4j re-illustrated the threat of the unknown. We must be more pragmatic.
The struggle to patch is real, and RASP can play a big part in buying time to shore up our defenses.
Thanks for reading this, and I hope it removes some of the mystique around RASP technology. Please don’t hesitate to contact our team if you’d like to know more.
