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.

Managing security in the OS

While it's possible to configure fine-grained resource access control in the OS or hypervisor, it's a cumbersome and error prone, especially for large enterprises. The cost of having an infrastructure team attempt to manage the security of thousands or even tens of thousands of applications using OS-level resource control gets increasingly expensive and time consuming with each new application.

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.

RASP for SDLC and devops

Many services used to implement a devops pipeline and circuits are Java applications, as are those used to implement a full SDLC. By enabling RASP for SDLC and devops, we are essentially embedding security not only in the application runtime but also throughout the entire application life cycle. From the moment the code is committed, containerized, and wired to the devops circuit, unit testing, user testing, performance tuning, and penetration testing will all exercise application code. While these processes execute, RASP can be used to profile the application and detect runtime vulnerabilities. In effect, security vulnerabilities can be identified by static testing, mitigated by RASP, and verified by dynamic testing, thus obviating the need for code patching.

Figure 2. Embedding security in the SDLC process with SAST, DAST and RASP

Instrumentation vs virtualization

Among Java implementations of RASP, there are two broad categories: those that affect protection by instrumenting code and those that use virtualization, meaning container-based implementations. Instrumentation refers to any process that requires a change to application artifacts such as source code, deployment descriptors, or binaries. Such changes require recompilation or redeployment, both requiring operational intervention when the RASP configuration is introduced or updated. Virtualized or container-based RASP implementations have the advantage of allowing RASP configurations to be altered without affecting the application lifecycle or its operation.

Code precision vs container precision

Instrumentation allows a great deal of fine-grained control in targeting runtime RASP monitoring in the code base. Data flow analysis, performance analytics, and API call scope and frequency can all aid precision. Developers have full control over which lines of their code will be RASP enabled. Balancing protection and performance can be especially important for low latency applications.

The downside of instrumentation is that it demands that developers and not platform administrators configure RASP. This limits the scope of protection, not extending beyond targeted applications. The use case for instrumented RASP is constrained to applications that, for reasons mostly pertaining to low latency or high performance, must maintain sub-millisecond latency.

Virtualized RASP, on the other hand, provides fine-grained precision at the container rather than the code. For example, one can alter the JVM to allow/deny/replace code execution, using rules that virtualized RASP imposes on the container rather than the application logic. Virtualized RASP does not demand direct interaction with application code, so there is no recompilation step or any other form of post-processing that require an application or container restart. Altering the runtime behavior of the RASP configuration in the container does not impose any service disruption to legitimate functionality.

For large-scale deployments, being able to abstract protection from the code and application is critical for reducing the overall effort of configuring RASP; avoiding operational downtime; and reacting quickly to newly identified threats.

Virtual patching

With respect to virtual patching, virtualized RASP has an inherent advantage because it demands less effort to affect and can be applied with disrupting normal operations. While instrumented RASP can technically be used as a substitute for a binary patch, this activity may have to be carried out in unique fashion for every application, and will still result in operational disruption. The activity would be more costly and risky than applying the binary patch in the first instance.

With respect to obviating the need for binary patches it is important to evaluate a RASP solution's coverage for enterprises running up to 4,000 applications, with perhaps as many as 100,000 JVMs. This is an essential question in light of Oracle's CPUs and quarterly patching cadence. Virtualized RASP vendors have innate superiority at this scale by virtue of exercising control over the container and not the code.

Preemptive security

Both instrumented and virtualized RASP implementations offer strong preemptive security capabilities; however virtualized RASP can disable SQL injection, cross-site scripting, and command injection by the use of simple rules (often one line switches) applied to the container and which can be applied to all applications. Again, simplicity and scale are critical factors for enterprises with large Java footprints.

Java vendors for RASP

Currently the three top vendors for Java-based RASP solutions are Contrast Security, Prevoty, and Waratek. Contrast's implementation is instrumentation-based, Waratek's are fully virtualized with container-based RASP, and Prevoty offer a plugin and an SDK.

Waratek won the coveted RSA Innovation Sandbox Award in 2015, and Prevoty where finalists in 2016. All three vendors have accumulated a number of other security and innovation awards. These vendors have announced commercial engagements and partnerships that set the stage for enterprise-scale RASP deployments into production environments. Waratek is the only vendor that can boast of a large-scale production deployment with a Tier 1 global investment bank, the most significant deployment of RASP that exists for Java technology today.

Conclusion

RASP is now a reality in the cyber security space and a proven technology on the Java platform. It's an effective and secure solution for large enterprises with legacy Java applications or code that requires frequent patching. Over the next year we can expect the rates of adoption to continue increasing, especially in heavily regulated sectors that are seeking innovation to meet the demands of global, regional, and state regulators. Finance, banking, health, and defense are all sectors where I anticipate RASP will flourish.

This story, "RASP rings in a new Java application security paradigm" was originally published by
JavaWorld.