How RASP Has Transformed App Security. What’s Next?

Runtime Application Security-Protection (RASP) tools protect applications by using a security engine embedded directly into or adjacent to the application. RASP emerged as a response to limitations of existing perimeter-security technologies for protecting networks and web applications.

RASP has several advantages over previous approaches running on external appliances. It tightens the security perimeter as close to the application as possible. It also takes advantage of a richer understanding of how the app is supposed to behave and can take corrective action when the app is doing something it should not.

But RASP also adds additional complexity in terms of deploying and managing more security engines and making sense of the higher granularity and frequency of information it generates.

Over the years RASP has evolved from being the new darling of the security industry to a checklist feature woven into various types of security and performance management tools.

This has led to divergence in how the term is applied. RASP is used mostly to describe the protection of  web applications or back end applications they interact with. You might encounter the term in conjunction with  application security testing, application performance management tools, or web application firewall (WAF) tools. At least one vendor has used the term to describe protecting the perimeter of mobile applications that interact with back-end APIs deployed in risk-averse industries such as banking and finance.

RASP on the Rise

It seems like there is a major update in internet protection technology about every decade, and RASPs are part of this trend following in the footsteps of firewalls introduced in the early 1990s and web application firewalls  introduced in the early 2000s. The term RASP was introduced in a 2012 Gartner report by Joseph Feiman to reflect the way vendors were finding ways to embed WAF capabilities directly into apps.

The idea gained significant traction in 2014 with Feiman’s deeper analysis that implored enterprises to “Stop Protecting Your Apps; It’s time for Apps to Protect Themselves.” He suggested there was an urgent need to change security priorities.

Shortly after writing that, Feiman moved over to Veracode, an application security testing company, and elaborated on “Why RASP is a Transformational Technology”. He suggested four key reasons why traditional security approaches failed to protect and diagnose production security issues.

1. Existing WAFs only operated at the perimeter and the inner workings of the applications themselves were black boxes. This limited their ability to protect what they could not see or understand.
2. The perimeter of apps was vanishing with the rise of mobile applications.
3. Perimeter security could not protect against insider threats.
4. Traditional application security focused on obfuscation to defend applications from reverse engineering and tampering, but did not offer attack protection. Obfuscation tools also ran the risk of affecting business logic code.

Early RASP tools added instrumentation logic into application runtime engines such as a Java virtual machine, .NET engine, or Apache server. This gave them a comprehensive view of how the application was passing data between various internal modules. Feiman predicted other technologies would spin out of RASP technology as it matured.

Modern RASP Blends Into the Security Environment

RASP has progressed from being its own thing to becoming a part of other tools. Putting RASP into production means adding instrumentation code to every application and then automatically updating RASP security policies as needed. It also requires ensuring this added code does not introduce quality issues that affect applications or the business logic that runs through them.

As RASP blended into the overall security environment, leading  research firms steered away from characterizing RASP as a separate technology or its own specialized market.

Gartner’s Peer Insights, for example, a review and ratings platform, included RASP coverage only because of high reader interest, noting the technology had not been included in any Market Guide or Magic Quadrants reports, which is normally required. Gartner’s review section lists only a single RASP offering by one vendor.

Forrester dove into more detail with its 2018 Forrester New Wave on RASP, the last time any of the big analyst firms had anything to say on the matter. Forrester highlighted RASP’s  ability to detect and respond to attacks and provide attack visibility as the biggest differentiators of the eight tools surveyed. Forrester observed that RASP tools can play a part in preventing zero-day attacks because they provide an additional layer of protection that hackers must navigate. Forrester also highlighted the need for automation to ensure RASP tools are deployed with every release.

One of the biggest concerns noted by the analysts  was the need for buy-in across development and operations teams. Another concern was that RASP could slow application performance or act as a new  bottleneck since it runs directly on the same server as the apps. There was also a need to ensure RASP tools played nice with existing tools and analysis techniques in order to protect the applications as intended.

Types of RASP Infrastructure

As noted above, RASP has evolved from a standalone concept to a component of larger toolsets primarily provided by WAFs, application security testing, and application performance management vendors. This makes a lot of sense: RASP can add value to each of these types of tools and take advantage of their existing development, deployment, and management capabilities.

For WAF vendors, RASP provides a way to extend the defense perimeter right to the edge of the application. RASP engines can be updated using WAF policy management tools.

RASP can also extend application security-testing tools to support real-time protection capabilities. This can complement other capabilities like Static Application Security Testing  (SAST) for quickly vetting coding errors, Dynamic Application Security Testing (DAST) to find errors in how the applications run, and Interactive Application Security Testing (IAST) that combines both approaches with ongoing human exploration. Some RASP vendors mention how RASP tooling can even simplify penetration testing.

RASP is a natural extension to logging and metrics engines developed by application performance management vendors. These tools already simplify the process of weaving a monitoring runtime into application code. They also include centralized management that helps teams relate performance issues to specific blocks or lines of code. For companies that already use tools from these vendors, adding RASP might be a relatively easy addition to their existing tools and workflows.

RASP Challenges

It’s getting on a decade since RASP was introduced, and the security industry is once again going through a major shift in thinking about how to protect applications. At one end of the spectrum, the tools for building secure applications are getting better and more integrated into the development pipeline. Indeed, many AppSec testing vendors have dropped RASP as a named feature of their products.

At the other end of the spectrum, enterprises are shifting their thinking from protecting applications to protecting APIs. This makes sense as attackers focus on finding ways to exploit business logic.

A 2019 report by the SANs Institute observed that RASP provides a way to make new and existing applications self-defending. However, companies needed to address challenges around customization, integration, and performance.

The report’s biggest concern was the limited scope provided by RASP protection. “It focuses on common application security weaknesses and does not replace a human being for the discovery of business logic flaws,” wrote author Alexander Fry.  “In addition, it takes effort by an organization to evaluate RASP offerings to ensure they meet business and performance requirements.”

The next generation of application security might find ways to combine the benefits of better testing in development with improved application security and observability. It may also expand to run  across different kinds of infrastructure built across physical servers, virtual machines, containers and serverless applications and APIs.

RASP has played a valuable role in adding a layer of protection to complement the weaknesses of traditional WAF. Access to the local application runtime provided enhanced context from within the application and helped in identifying and protecting against aberrant behavior. However, RASP also added new challenges of adding computational overhead and offered limited visibility across distributed applications or micro services architectures.

Stepping Beyond RASP

As the world moves towards replacing Web applications with APIs the next generation of protection tools will need to combine this local tracing with visibility of behaviour across APIs. A distributed tracing approach shows promise in meeting this challenge. In this model, a small bit of code is deployed on each service to instrument the code. This data can be analyzed across distributed services to provide a wider context useful for protecting against business logic attacks.

Whatever supersedes RASP might look more like a realtime API security protection system that combines the benefits of local observability with distributed context. Distributed tracing is one promising approach that can provide this wider security context in a way that addresses many of the weaknesses of current RASP solutions.  

About the Author

George Lawton is a technology writer and regular contributor to The Inside Trace.

View a recorded demo of Traceable AI.