5

I'm having a hard time figuring out what "Runtime Application Self-Protection" (RASP) really is, though I see it mentioned in the press. The best description I've seen of the possible benefits, along with some limitations, is in this article Is runtime application self-protection a shortcut to secure software?

But that still doesn't really give practical examples.

Is there any open-source software that does this? Any frameworks that provide it? Would something like Cross Site Request Forgery protection in Django be an example?

nealmcb
  • 20,783
  • 6
  • 72
  • 117
  • I think these are mostly based on taint checking. Whether anti-CSRF counts as RASP is somewhat subjective, but I think most people would say no. – paj28 Sep 02 '15 at 11:05
  • Here's an interesting comment from @amarnath_chatterjee: RASP is like embedding antivirus into your software – nealmcb Apr 06 '17 at 17:08

3 Answers3

4

RASP takes a naive application and enables it to identify attacks and block them. There are a number of different approaches including filters, sandboxes, and full instrumentation. Here's a good independent article on RASP describing the use cases and approaches: https://securosis.com/blog/understanding-and-selecting-rasp-technology-overview.

Let's look at a simple SQL injection example. A naive application simply has no defense and gets exploited. An application that uses PreparedStatements is safe against injection, but has no idea whether it is being attacked or not. Let's see how this works with RASP. I'm describing Contrast's instrumentation approach here.

First, the RASP is installed into the application. In this case, simply adding the RASP agent to the environment is enough. When the code loads, the RASP uses dynamic binary instrumentation to add new security sensors and analysis capability to the application. This process is very similar to how NewRelic or AppDynamics work to instrument an application for performance.

When the attack arrives at the application, RASP uses gathers data about the request, the user, the session, and any other contextual information. The attacker's request data is tracked through the application. If it looks like an attack, but never reaches a SQL query, it gets reported as a probe. This is a major difference from what a WAF can do, as WAFs are not able to see what happens inside the application and must overblock.

If the attack actually reaches a SQL query and modifies the meaning of that query, only then does RASP block the attack. This is essentially enforcing the definition of SQL Injection, as only attacks that successfully modify the meaning of SQL queries are blocked. This is why RASP implementation can be deployed without much configuration or training.

Ultimately, the user gets visibility into who is attacking their applications, where the attacks are coming from, the techniques being used, the exact line of code that is being targeted, and the full SQL query containing the attack. The number of viable attacks is only a tiny fraction of the overall probes that never hit a matching vulnerability. So the results are quite different than what a WAF can provide.

The process is roughly the same for other vulnerabilities. Although, RASP may add specific protections for known vulnerabilities in libraries and components. RASP may also add security logging or other security features to applications.

planetlevel
  • 335
  • 1
  • 7
3

let me give you a short answer to start a discussion, potentially with a bias, from someone works who works for a company selling RASP. I have seen that nobody has answered for a while.

We understand RASP as something that becomes part of the binary of the app. Using code scanning you develop a secure app but in order to keep it secure you have to harden the application against static and dynamic attacks like reverse-engineering, patching, decompilation, debugging, swizzling, API hooking, cryptographic key lifting etc. See the countermeasures of the OWASP top ten mobile risks for example.

Some of the countermeasures detect patching through checksumming e.g. and then you might know certain techniques to obfuscate control flow, prevent strings literals in the app, detect swizzling, debugging or API hooking etc. But there might be more unknown techniques in RASP implementing products like code repairing (for code that has been patched) and custom actions. Once the app itself understands that it has been tampered with RASP should give you ways to behave in smart ways, a custom action. With smart I mean not just exiting or crashing an app or bringing up a dialogue that something is not as expected but limiting the functionality, destroying the cryptographic keys or whatever is a smart custom action for a specific app.

These countermeasure against certain attacks are all part of the app and the security goes wherever the app goes and does not rely upon anything additionally installed on a device. An important secret of certain RASP products is how the security itself defends against all these attacks.

Makes sense?

Jens Erat
  • 24,566
  • 12
  • 82
  • 103
Mirko Brandner
  • 31
  • 1
  • Protecting against decompiling isn't RASP. To execute any of the attacks you list, you'd basically have to be on the platform with full control of the application anyway. RASP is empowering applications to identify and block attacks like SQL Injection, XSS, CSRF, XXE, Command Injection, EL Injection, known vulnerabilities in libraries, etc... – planetlevel Apr 05 '17 at 16:22
1

There is something called OWASP AppSensor. They've written that their concept is very similar to Gartner's RASP with the difference being that Gartner is focused on "vendors-offerings" and OWASP has built a framework that can allow "deep code integration".

It seems that the first one can implement more specific behavior but the concept is actually quite similar.

Another similar example I can think of is HDIV in Java, though I'm not sure about its runtime capabilities.

nealmcb
  • 20,783
  • 6
  • 72
  • 117
wtrmeln
  • 51
  • 2