SBN

Understanding and Selecting RASP 2019: Technology

Posted under: Heavy Research

Here we discuss technical facets of RASP products, including how the technology works, how it integrates into an application environment, and the advantages of each approach. We will also outline some important considerations, such as platform support, which will impact your 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 of years the RASP market has settled on a couple basic approaches to RASP, with different variations on these approaches to enhance detection, reliability or performance. Understanding the technology should greatly assist the reader in understanding the strengths and weaknesses of the RASP offering.

  • Instrumentation: With this deployment model RASP places sensors/callbacks at key junctions within the application stack to see application behavior within — and between — custom code, application libraries, frameworks and underlying operating system. This approach is commonly implemented by using native application profiler/instrumentation APIs to monitor application behavior at runtime. When a sensor is hit, RASP gets a callback and evaluates the request against the appropriate subset of policies relevant to the request and application context. For example, database queries will result in examination of the request for SQL Injection (SQLi). But they also provide request de-serialization ‘sandboxing’ to detect malicious payloads, and what I prefer to call ‘checkpointing’, where a request that hits checkpoint A but bypasses checkpoint B can deterministically said to be hostile. These approaches provide far more advanced application monitoring than WAF, with nuanced detection of attacks and misuse. However, it does require the solution to monitor all relevant interfaces to provide full visibility, at some cost to performance and scalability. Essentially a balancing act between thorough coverage and performance.
  • Servlet Filters & Plugins: Some RASP platforms are implemented as web server plug-ins or Java Servlets, typically installed into either Apache Tomcat, JBOSS or Microsoft .NET to process requests. Plugins filter requests before they execute functions like database queries or transactions, applying detection rules to each request received. Requests that match known attack signatures are blocked. They offer not less function than a WAF Blacklist, with some added protections such as lexical analysis of inbound request structures. This is a simple approach for retrofitting protection into the application environment, and is effective at blocking malicious requests, but it doesn’t offer the depth application understanding possible with other integration approaches
  • Library or JVM replacement: Some RASP products are installed by replacing the standard application libraries, JAR files, and at least one vendor offers full replacement of the 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, the RASP can alter classes as they are loaded into memory, augmenting or patching the application and application stack. Like Instrumentation, this approach provides complete visibility of the application behaviors and performs analysis of user requests. Some customers we spoke with preferred the automated application of platform patches, but the majority were uncomfortable with dynamic alteration of the application stack in production.
  • Instrumentation & Static Hybrid: Like many firewalls, some RASP platforms can deploy as a reverse proxy, and several RASP vendors offer this as an option. In one case there is a novel variant that couples the 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 in order to scan all source code in. It then bundles the scan result into the RASP engine as the application is deployed, effectively providing an application specific form of functionality whitelist. The security controls tailored to the application, offering excellent code coverages, at the expense of full build integration, the need to regularly rebuild the CPG profile, along with some added latency for security checks.

There have been several other small companies that have come and gone over the last couple of years, with a mixture of application logic crawlers (DAST) rule sets, application virtualization to mimic the replacement model listed above, and mirroring runtimes in cloud services. The full virtualization approach was interesting, but being too early to market and being dead wrong in approach are virtually indistinguishable. Still, I expect over time we will see new variations on RASP detection capabilities, possibly in the area of AI, and new cloud services for added layers of support.

Detection

How RASP products detect attacks is complicated, with multiple techniques being employed depending upon the type of request being made. Most examine both the requests and associated parameters, and each are subject to multiple types of inspection. The good news is that RASP is far more effective in detection of application attacks. Unlike other technologies which use signature based detection, RASP fully decodes parameters and external references, maps application functions and 3rd party code usage, maps execution sequences, de-serializes payloads and applies polices accordingly. This not only allows for more accurate detection, but helps with performance as which checks are performed are optimized to the context of the request and execution path within the code. As rules are enforced at the point of use, it is far easier to to understand proper usage and detect misuse.

Most RASP platforms employ structural analysis as well. They understand what framework is in use, and the common set of vulnerabilities the framework suffers. As RASP understands the entire application stack, it can detect variations in 3rd party code libraries —- essentially a vulnerability scan of open source —- to determine if outdated code is being used. And RASP can quickly vet incoming requests and detect injection attacks. There are several approaches; one such approach is achieved by a form of tokenization — substituting parameters for a tokens — in order to quickly check that any given request matches its intended structure. For example, tokenizing clauses and parameters in a SQL query, you can quickly detect when a ‘FROM’ or ‘WHERE’ clause has more tokens than it should, meaning the query has been altered.

Blocking

When an attack is detected, as RASP is within the application, most products throw and application error. In this way the the malicious request is not forwarded, and the application is responsible for a graceful response and maintaining application state. Products that offer full instrumentation can block the execution sequence during runtime, when something bad is detected but prior to execution. What is reported to the user is entirely up to the application developers. That said, this can create issues with server side application stability and user experience. RASP offers some capabilities to tune response behaviors, but this should be examined on a vendor by vendor basis.

Language Support

The single biggest growing pain for the RASP vendor community 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 others are in wide use. For each vendor we spoke with during our research, language support was a large part of their product roadmap. Most provide full support for core platforms like Java and .NET; beyond that support still a little spotty. You will need to check with your vendor on what is supported, and what versions.

Another part of the problem is the complexity of the environment; not just the server side but the client side as well. Over the last few years we have witnessed an expanding universe of frameworks, client side utilities, web-facing APIs and changing fashions for data encoding. Consider that RASP needs to parse XML and JSON, handle diverse clients running Javascript and Angular.js, micro-service architectures and possibly multiple versions of APIs all at the same time. The diversity of application environments makes it challenging for all RASP vendors to provide full support. If your application doesn’t run on a standard platform you will need to discuss support in great detail with the vendors prior to purchase. Within the next year or two we expect this issue to largely go away, but for now it is a key decision factor for buyers.

Performance and Scalability

As RASP embeds within the application or the supporting application stack, once bundled with the application, it scales with that application. For example, if the scalability model means more copies of the application running on more server instances, RASP will be run atop more server instances as well. If deployed on virtual or cloud servers, RASP benefits from added CPU and memory resources along with the application.

From the latency and performance perspectives, RASP enforcement rules — both how they operate and the number of checks employed — should be considered. The more analysis applied to incoming requests grants better security, but comes at a cost of latency. If third party threat intelligence is not cached locally, or or external lookups are used, latency increases. If the sensors or integration points are purely event collection, and the events are passed to another external server for analysis, the added services with increased latency. As we recommend with all security products, don’t trust vendor supplied numbers, rather run tests in your environment with traffic that represents real application usage. And as vendors have applied considerable engineering resources to performance over the last couple years, latency issues have been far less common.

Instrumentation

Security teams often want visibility into application security, and it is increasingly common for them to use scans in the build pipe-line, pre-production and production to create metrics and visibility into application security posture. This tells them both where they need to deploy more resources, but also allows them to better gauge the effectiveness of the resources that they have already deployed.

One huge advantage of RASP is it can instrument application usage and defect rates. Part of this capabilities is what we mentioned above: RASP can catalog application functions, understand the correct number and type of parameters, and then apply policies within the code of the running application. But it also can understand runtime code paths, server interaction, open source, nuances of frameworks, library usage, and custom code. This offers advantages in the ability to tailor detection rules, such as employing specific policies to detect attacks against the Spring framework. It can be set to block specific attacks against older versions of libraries, providing a form of virtual patching. This also offers non-security related benefits to developers, quality assurance and operations teams to show how code is used, providing a runtime map which shows things like performance bottlenecks and unused code.

– Adrian Lane
(0) Comments
Subscribe to our daily email digest


*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by [email protected] (Securosis). Read the original post at: http://securosis.com/blog/understanding-and-selecting-rasp-2019-technology