It is time to discuss technical facets of RASP products – including how the technology works, how it integrates into an application environment, and the advantages of different integration options. We will also outline important considerations such as platform support which impact the selection process. We will also consider a couple aspects of RASP technology which we expect to evolve over next couple years.

How the Technology Works

Over the last couple years the RASP market has settled on a couple basic approaches – with a few variations to enhance detection, reliability, or performance. Understanding the technology is important for understanding the strengths and weaknesses of different RASP offerings.

• Instrumentation: In this deployment model, the RASP system inserts sensors or callbacks at key junctions within the application stack to observe application behavior within and between custom code, application libraries, frameworks, and the underlying operating system. This approach is typically implemented using native application profiler/instrumentation API to monitor runtime application behavior. When a sensor is hit RASP gets a callback, and then evaluates the request against the policies relevant to the request and application context. For example database queries are examined for SQL Injection (SQLi). But they also provide request deserialization ‘sandboxing’ to detect malicious payloads, and what I call ‘checkpointing’ – a request that hits checkpoint A but bypasses checkpoint B can be confidently considered hostile. These approaches provide far more advanced application monitoring than WAF, with nuanced detection of attacks and misuse. But full visibility require monitoring of all relevant interfaces, with a cost to performance and scalability. Customers need to balance thorough coverage against performance.
• Servlet Filters & Plugins: Some RASP platforms are implemented as web server plugins or Java Servlets, typically installed in Apache Tomcat, JBoss, or Microsoft .NET to process requests. Plugins filter requests before they execute functions such as database queries or transactions, applying detection rules to each request on receipt. Requests which match known attack signatures are blocked. This is effectively the same functionality as a WAF blacklist, with added protections such as lexical analysis of inbound request structures. This is a simple way to retrofit protection into an application environment; it is effective at blocking malicious requests without the deep application understanding possible using other integration approaches
• Library or JVM Replacement: Some RASP products are installed by replacing standard application libraries and/or JAR files, and at least one vendor offers a full replacement Java Virtual Machine. This method basically hijacks calls to the underlying platform into a custom application. The RASP platform passively ‘sees’ application calls to supporting functions, applying rules as requests are intercepted. For example in the case of JVM replacement, RASP can alter classes as they are loaded into memory, augmenting or patching the application and its stack. Like Instrumentation integration, this approach provides complete visibility into application behaviors and analyzes user requests. Some customers prefer this option as effectively automated platform patching, but most customers we speak with are uncomfortable with dynamic alteration of the production application stack.
• Instrumentation & Static Hybrid: Like many firewalls, some RASP platforms can deploy as a reverse proxy; several vendors offer this as an option. In one case a novel variant couples a proxy, an Instrumentation module, and parts of a static analysis scan. Essentially it generates a Code-Property-Graph – like a static analysis tool – to build custom security controls for all application and open source functions. This approach requires full integration into the application build pipeline to scan all source code. It then bundles the scan result into the RASP engine as the application is deployed, effectively providing an application-specific functionality whitelist. The security controls are tailored to the application with excellent code coverage – at the expense of full build integration, the need to regularly rebuild the CPG profile, and some added latency for security checks.

Several small companies have come and gone over the last couple years, offering a mixture of application logic crawlers (DAST) rule sets, application virtualization to mimic the replacement model listed above, and runtime mirroring in a cloud service. The full virtualization approach was interesting, but being too early to market and being dead wrong in approach are virtually indistinguishable. Still, over time I expect to see new RASP detection variations, possibly in the area of AI, and new cloud services for additional support layers.

Detection

RASP attack detection is complicated, with multiple techniques employed depending on request type. Most products examine both the request and its parameters, inspecting each component in multiple ways. The good news is that RASP is far more effective at detecting application attacks. Unlike other technologies which use signature-based detection, RASP fully decodes parameters and external references, maps application functions and third-party code usage, maps execution sequences, deserializes payloads, and applies polices accordingly. This not only enables more accurate detection, but improves performance by optimizing which checks are performed based on request context and code execution path. Enforcing rules at the point of use makes it much easier to both understand proper usage and detect misuse.

Most RASP platforms employ structural analysis as well. They understand what framework is in use, and which common vulnerabilities it is vulnerable to. As RASP understands the entire application stack, it can detect variations in third-party code libraries — roughly comparable to a vulnerability scan of an open source library — to determine when outdated code is used. RASP can also quickly vet incoming requests and detect injection attacks. There are several approaches – one uses a form of tokenization (replacing parameters with tokens) to quickly verify that a request matches its intended structure. For example tokenizing clauses and parameters in a SQL query can quickly detect when a ‘FROM’ or ‘WHERE’ clause has more tokens than it should, indicating the query has been altered.

Blocking

When an attack is detected RASP, running within the application, can throw an application error. This prevents the malicious request from being further processed, with the protected application responsible for a graceful response and maintenance of application state. Products which offer full instrumentation can block the execution sequence at runtime, when something bad is detected, but prior to execution. What the user sees is entirely up to application developers, but this can create issues with server-side application stability and user experience. RASP offers some capabilities to tune response behaviors, but this varies between vendors.

Language Support

The single biggest growing pain for RASP vendors has been language support. Java, JavaScript, C#, and Visual Basic may comprise the bulk of application code developed; but Python, Ruby, PHP, Go, and numerous other languages are in wide use. Each vendor we spoke with during our research identified language support as an important part of their product roadmap. Most provide full support for core platforms such as Java and .NET, but additional support is still a bit spotty. You will need to check with vendors on what languages and versions are supported.

Another part of the problem is environmental complexity – not just the server side but clients as well. Over the last few years we have watched an expanding universe of frameworks, client-side utilities, web-facing API, and changing fashions in data encoding. RASP needs to parse XML and JSON, handle diverse clients running JavaScript and Angular.js, deal with micro-service architectures, and possibly handle multiple APi versions simultaneously. The diversity of application environments makes it challenging for RASP vendors to provide support. If your application doesn’t run on a standard platform, you need to discuss support in detail with any vendors you consider – prior to purchase. Within the next year or two we expect this issue to largely go away, but today it is a key consideration.

Performance and Scalability

RASP embeds within the application or its stack, so it scales with that application. For example, if the application scales out copies on multiple server instances, RASP will scale along with it. If deployed on virtual or cloud servers, RASP benefits from added CPU and memory resources right alongside the application.

RASP enforcement rules – both how they operate and the number of checks – also impact latency and performance. More and deeper request analysis strengthen security, but increase latency. If third-party threat intelligence is not cached locally, or external lookups are used, latency increases. If sensors or integration points only collect events and pass them to an external server for analysis, added services likely increases latency. As with all security products, don’t trust vendor numbers – run your own tests, in your environment, with representative traffic. Fortunately vendors have applied considerable engineering resources to performance over the last couple years, significantly reducing latency issues.

Instrumentation

Security teams often want visibility into application security, and it is increasingly common for them to use scans in the build pipeline, pre-production, and production to develop metrics and gain visibility into application security posture. This shows where they need more resources and helps gauge the effectiveness of deployed resources.

One huge advantage of RASP is that it can instrument application usage and defect rates. Part of this capability is derived from its ability to can catalog application functions, understand the correct number and type of parameters, and apply policies within running application code. But RASP also can understand runtime code paths, server interactions, open source libraries, framework nuances, library utilization, and custom code. This offers advantages when tailoring detection rules, such as enabling specific policies to detect attacks against the Spring framework. RASP can be configured to block specific attacks against older versions of libraries, providing a type of virtual patching. This also provides non-security benefits – helping Quality Assurance and Operations teams to see how code is used, providing a runtime map which can identify performance bottlenecks and unused code.