The Contrast Between Today's RASP Approaches

Runtime application self-protection is a hot topic in the security world these days. This emerging technology is generating a lot of excitement and interest from investors, entrepreneurs, and technologists. Yet, not all RASP is created equal. Let’s compare and contrast approaches to separate the hype from the reality.

Not all RASP is RASP

The application security market, Gartner, and pure RASP vendors use runtime application self-protection to refer specifically to web application security. In contrast, some vendors are using the term RASP to apply to any solution that secures mobile applications, or even physical/virtual servers (at the operating system level). When most people talk about RASP they are referring to (web) application security.

Blacklisting and RASP

Some RASP vendors are entirely blacklist or signature based, even if it is embedded in the app. This *may* only stop trivial attacks. This technology is basically a low-quality web application firewall (WAF). Blacklisting-based RASP is not as good as even the free and open source WAFs at securing apps, since they will contain only a fraction of the blacklists available on the network/server alternatives. Blacklisting on the web server or network is faster than doing the same amount of blacklisting at the application level. Furthermore, looking at traffic hitting your application is a poor way of identifying where real vulnerabilities lurk in your application, which is one major advantage to using RASP in the first place. Easy to bypass, not sufficient, and very noisy.

Can Your RASP Stand Alone?

Pure RASP players have tools that can stand alone. They provide proactive protection to the entire stack—and are not based on signatures, common vulnerabilities and exposures (CVE), or ahead of time detection of vulnerabilities. Contrast that with RASP tools that require some form of prior testing (usually SAST, IAST, or DAST) or protect only part of system. These RASP solutions only protect the vulnerabilities that were already found during testing. The main advantage is that you don’t have to fix the bugs found right away. The downside is that detection tools are not perfect, will not find everything, and usually focus on the code you wrote, which is a fraction of the code running (which includes 3rd party libraries and frameworks).

Threat Coverage

RASP technologies differ in the scope and coverage of the vulnerabilities they help prevent in the exploitation of. Virtually every product out there offers some level of SQL injection and XSS protection (albeit, at widely differing capabilities and effectiveness), not all handle other OWASP top 10 vulnerabilities such as remote command execution, directory traversal, local file inclusion, or more modern day runtime threats like account takeovers and certain types of botnet attacks such as credential stuffing.

Platforms and Support

Contrasted with each other, RASP vendors provide different support across platforms. Some are limited to Java/.Net, while others support multiple platforms, including Ruby, Python, Node, and PHP. RASP vendors also contrast greatly in maintenance and upgrade required after deployment and in remediation mechanisms they offer.

RASP is not about identifying vulnerabilities. It is about proactively protecting applications against known and unknown exploitation and modern type attacks, like account takeovers. It protects code you wrote (that usually receives application security testing) and the code that you didn’t write (like frameworks and third-party libraries).

There is a lot of hype in RASP-land. And it is difficult to separate the hype from the reality. So before you choose a RASP solution, it pays to compare and contrast vendors and their offerings to decide which will provide the best proactive protection for all your web applications.