Runtime Application Self Protection (RASP) is a next-generation cyber security technology designed to redress some of the weak points of application security. Unlike firewalls or code analysis, runtime-based technologies contain application data and contextual awareness, enabling them to be both precise and preemptive.
In this article I introduce RASP. I'll briefly compare RASP to other cyber security techniques and explain the factors that enable a runtime-based security solution to fend off common forms of cyberattack, including command injection, cross-site scripting, and SQL injection. I'll also introduce the characteristics of different RASP implementations and briefly discuss existing RASP solutions for Java-based applications.
To get started, let's consider how RASP compares to two common approaches to application security: web application firewalls and application security testing.
RASP vs web application firewalls
A web application firewall (WAF) is intended to protect applications by analyzing web traffic and using signatures to identify malicious activity. With strong signatures and pattern-matching algorithms, a WAF can be an effective layer in an overall security solution. However, because they lack context-awareness, WAFs are notorious for generating false positives. In contrast, RASP-based technologies can leverage runtime application data and contextual awareness to prevent hackers from exploiting some types of vulnerabilities.
RASP technologies embed security intelligence directly within the application tier. Being able to differentiate between application and user data enables a RASP solution to identify maliciously injected code, or to detect unusual application activity, and to do so with an unprecedented degree of precision. The contrast is stark when compared to the high rates of false positives produced by WAFs, and indeed to incidents resulting in service disruption due to poorly configured firewall rules.
Rather than relying on signatures and pattern matching, RASP security rules are highly configurable. Rules can be used to raise alerts or to prevent attempts to access protected resources such as filesystems and networks. Depending on the capabilities of the specific implementation, these rules can be simple, generic, or dynamically adjustable at runtime; all without impacting the normal application lifecycle or expected application operations.
RASP vs static and dynamic application security testing
There's no disputing the benefits of identifying vulnerabilities in source code, but enterprises have learned the hard way that knowing the source does not resolve the issue. Once a vulnerability has been identified, the enterprise must decide whether the risk level and type justify the resources required to defuse it. Larger enterprises are frequently overwhelmed by the sheer number of vulnerabilities. Patching them all at the level of source code is exorbitantly time consuming and costly. Worse, the majority of enterprise code is sourced from third-party applications and APIs. The remaining 80 percent is not in the enterprise's direct control, as illustrated by Figure 1.
To manage these issues, enterprises frequently assess risks and patch vulnerabilities using something like the Common Vulnerability Scoring System (CVSS). For global enterprises managing multiple stakeholders, determining which vulnerabilities to patch can be error-prone and costly, resulting in systems that violate the NoIT principle.
As a solution to the limitations of SAST and DAST, RASP offers virtual patching, a rules-based technique that can be used to prohibit command injection, cross-site scripting, and SQL injection. In some RASP implementations, virtual patching extends to all Java code running in the container, including third-party APIs.
RASP in Java-based systems
RASP's effectiveness at mitigating vulnerabilities makes it a strong fit for any comprehensive cyber security strategy. Because of Java's ubiquity in the enterprise and in third-party solutions, RASP is an especially powerful addition to Java-based systems. RASP greatly reduces the cost of addressing new vulnerabilities in open source and proprietary APIs. It also can work well with the 90-day Critical Patch Update (CPU) cadence of the JVM.
Three key features differentiate RASP in Java-based systems.
1. Precision application protection
Precision application protection refers to RASP's ability to eliminate false positives. RASP technologies can do this by virtue of running within the application tier and thus having access to application and user data, as well as being able to differentiate between the two. This ability to both access and unambiguously identify user and application data is central to detecting malicious code without generating false positives.
2. Preemptive security
Preemptive security refers to RASP's generic, configurable rules, which can be used to disable the most common execution vectors exploited by zero day attacks. For example, a RASP-enabled JVM could be configured to deny the creation of client and server sockets or file descriptors. This denial could be total for some applications, or it could be configured to allow a descriptor for the exact port numbers and file locations used by the application. Such fine-grained control can stretch to every aspect of the runtime, enabling RASP to prohibit access to specific classes or packages regardless of other native Java security facilities. While the vulnerability still exists in the application logic, exploits are rendered harmless. An alert can be raised if there is an attempt to access a protected resource, initiating further investigation.
3. Virtual patching
An important aspect of virtual patching in RASP is the ability to host legacy code within a virtual container. The container then effectively secures the application as if it were running in an updated, compliant version of the runtime. This is important for enterprises with mission-critical legacy applications that cannot be upgraded due to technical constraints or lack of expertise.
A RASP implementation with virtual patching gives the enterprise an option for safely containing legacy applications. Legacy apps can be run without requiring recompilation, code changes, or having to rush a transformation project to avoid legal or commercial risk.
Another use for virtual patching is the ability to replicate the effect of binary patches. For example, you could use RASP to replicate CPUs issued by Oracle for Java on a quarterly basis, potentially obviating the need to apply CPU binary patches.
This is important for Java enterprises because applying binary patches to hundreds or thousands of JVMs can be a complicated process, demanding both engineering resources and scheduled downtime.
In some RASP implementations, virtual patching is a non-intrusive, centrally managed operation. It's possible to dynamically patch applications without disrupting normal operations or scheduled downtime. A preferred strategy is to enable RASP protection in "monitoring mode" for a period of time. Monitoring allows the development team to undertake a full impact analysis before applying the patch, thus eliminating disruption to normal operations.
Differences among RASP implementations
There is considerable variation among RASP implementations. Many RASP vendors claim that their product doesn't demand code changes, and that configuration and performance impacts are minimal. What may seem to be a trivial code or configuration change can considerably impact the speed of adoption when scaled to hundreds or thousands of applications, however.
A common critique of RASP is the expected performance impact of runtime analysis and protection. Early implementations of RASP could cause as much as 10 percent increase in response times within the application tier, but performance is constantly improving. Many RASP vendors now claim 5 percent or less impact on application response times.
In general, bottlenecks such as database access or internet latency contribute more to performance loss and response times. Rewriting insecure code to carry out the kind of protection delivered by RASP can also cause a similar impact to performance.
With those performance caveats in mind, consider the following variations in RASP implementation.