Again, according to Gartner, runtime application self-protection (RASP) is “a security technology that is built or linked into an application or application runtime environment, and is capable of controlling application execution and detecting and preventing real-time attacks.” What makes RASP unique is that it works from inside the software, rather than as a network device. This allows RASP to take advantage of all the contextual information available inside the running application or API, including the code itself, framework configuration, application server configuration, libraries and frameworks, runtime data flow, runtime control flow, backend connections, and more. More context means broader protection and better accuracy.

Below, we will explore all the things you can do with RASP, but the two primary RASP capabilities are:

1. Preventing application exploits: Accurately stopping application vulnerabilities from being exploited without disrupting legitimate application use.
2. Application threat intelligence: Creating visibility into who is attacking, the techniques they are using, and the applications they are targeting.

RASP has significant advantages in terms of performance and scalability. Because security decisions are made inside applications and APIs without a separate hop, the performance can match the application’s speed. And because RASP is a fully distributed approach, all your applications and APIs can be continuously protected in parallel. RASP runs anywhere the application can run and can be deployed along with the application, so it is perfect for cloud and DevOps organizations.

RASP implementations use different, and possibly multiple, techniques to access this contextual information and protect applications at runtime. Different techniques have different characteristics, advantages, and disadvantages. Everything from simple techniques like HTTP filters to platform shims to virtualization and all the way to full software instrumentation can be used to implement RASP.

The Internet is not a nice place. All web applications and web APIs are attacked every single month. The most common attacks on “latent” vulnerabilities are well-known: cross-site scripting, SQL injection, file path traversal, and command injection. There are also very common attacks on “known” vulnerabilities like OGNL injection in the Spring Framework (CVE-2017-5638) and Java unsafe deserialization (CVE-2018-0147). In the course of a single month, every application will be attacked at least once, and more than half will experience many thousands of attacks across a wide array of vectors.

There are a number of challenges protecting web applications and APIs against attack:

Problem 1: Real attacks are difficult to identify. You can’t simply look at an HTTP request and tell whether it is an attack or. Every application has its own unique vulnerabilities that can only be exploited by completely unique attacks. So, an HTTP request that’s completely harmless for application or API could be devastating for another. Further, data often appears differently on the wire than it does when it shows up in application. This is known as the “impedance mismatch” problem.

Problem 2: Modern applications (particularly APIs) are complex. Modern applications don’t take simple HTTP name-value pairs as input. Instead, they consume complex formats like JSON, XML, serialized objects, and custom binary formats. These requests use a variety of protocols beyond just HTTP, including WebSocket, which are generated by JavaScript in the browser, rich clients, mobile applications, and many other sources.

Problem 3: Traditional defenses simply aren’t effective. Web application firewalls (WAFs) operate entirely separately from applications by analyzing HTTP traffic before it reaches the application server. According to owasp.org, a WAF “is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as cross-site scripting (XSS) and SQL injection.” WAFs have been around since the early 2000s and haven’t evolved much beyond attacks leveraging GET/POST form and URL parameters. Nevertheless, they are widely deployed. Most large organizations have a WAF in place, although many do not have the staff and expertise required to do the tuning necessary to keep it operational, and resort to having it in “log mode” only.

Problem 4: Software is moving fast. In the past few years, we have seen an explosion of containers, IaaS, PaaS, virtual, and elastic environments that allow applications and APIs to be deployed quickly. DevOps has also rapidly accelerated the rate of integration, deployment, and delivery, complicating the process of ensuring the security of rapidly evolving software.

Fortunately, RASP can address many of these concerns.

Since RASP is a recent development in the information security world, it helps to detail where RASP fits in with other types of security protection, both in the software stack and across your organization.

The diagram above shows where RASP fits into the NIST Cybersecurity Framework (CSF). RASP is squarely focused on the application security row. Some RASP implementations can help with identifying and profiling applications. Most provide significant protect and detect capability. And some can assist with response, by collecting data and establishing new policy.

RASP in the Stack

There is a fundamental shift towards cloud and container in modern software. Securing this stack is no longer the job of perimeter devices, which are too isolated, inflexible, and in the wrong part of the stack for these modern environments. Instead, the modern web application stack relies on instrumentation across all the layers.

The following table details the layers of the modern web application stack along with instrumentation-based security solutions.

Contrast

Immunio

Prevoty

Waratek

Twistlock

Aqua

Anchore

Sysdig

Carbon
> Black

Illumio

VMWare

Tanium

ZScaler

AlienVault

Checkpoint

Fortinet

As you can see, RASP is the instrumentation-based approach to securing the application layer. The other layers of the stack are recognizing the advantages of instrumentation-based approaches, as well. At all of the layers, having direct access has massive advantages over attempts to protect from an external perspective.

Since RASP builds security directly into the software stack, the application can be deployed in any environment safely, including cloud, PaaS, VM, and data center.

RASP in the Enterprise

For enterprise organizations, RASP is a powerful way to scale security across the entire application and API portfolio. More than likely, it won’t be your primary website that gets compromised. Instead, it’s more likely to be a partner website, an obscure mobile API, or a business app on your intranet. This is why protecting all your applications and APIs, even non-web APIs, is so critical.

Many organizations reserve security protection for what they think of as “external” or “public-facing” applications. Actually, the concept of “internal” and “external” applications is dependent on a working security perimeter. Unfortunately, the perimeter established by firewalls and other network security devices has become so porous that it is now essentially meaningless. For example, a single employee workstation that is compromised by an attacker becomes an internal attack portal that makes the perimeter irrelevant.

So, while WAFs are typically not applicable for internal applications, RASP can become part of all applications. Think of RASP like an application security control plane that allows you to understand what code you are running and enforce policy everywhere.

Because RASP is a software solution and not a network device, the deployment process is very different from traditional security solutions.

How to Deploy RASP

There are two basic models for deploying RASP. These models differ not only technically, but in what teams take ownership and control of RASP.

Traditional RASP

This model is used by “traditional” organizations that are simply looking for a better technology to protect applications and APIs in operations. These organizations have an operations team that owns security in production, and they will own installing, configuring, and monitoring the RASP. There may also be a security operations center (SOC) that monitors the output from the RASP and investigates and responds to incidents as necessary.

In these organizations, RASP can be deployed widely using tools like Chef, Puppet, Ansible, and other enterprise tools — anything that can operationalize running an installer. Generally, you’ll want to start in “log mode” to verify that protected applications work correctly. Alternatively, you can install RASP in “block mode” in test environments to build confidence before going to production.

DevSecOps RASP

This model is for “DevOps” organizations that are looking to include RASP in the development of applications and APIs. In these organizations, a single team handles both development and operations, and should be responsible for the RASP, as well. The primary difference is that they can include RASP as part of applications and APIs and it will be tested and deployed along with the other software. Because it lives with the application throughout the lifecycle, you can start with RASP in “block mode” from the beginning.

In these organizations, RASP can be deployed in numerous ways. RASP can be included in standard builds, built into applications during CI/CD, made part of containers like Docker and Kubernetes, and deployed with Ansible or other solutions. Some products have plugins or tiles available for environments like Pivotal, AWS, Azure, and the like. The best approach is to include RASP as part of the way that software is already deployed.

Deploying RASP and WAF

Many organizations already have WAFs in place, have tuned them carefully, and rely on them to stop basic attacks. RASP and WAFs can co-exist peacefully, and the combination may be a good fit for many organizations.

Because RASP has more application context, it may be more accurate at stopping attacks than a WAF. So, one strategy is to tune the WAF so that the ruleset only enforces the rules that are the least likely to false alarm. This will block most scans and simple attacks, as well as filter out noise from reaching applications and APIs. RASP, then, provides a second layer of protection to prevent any more sophisticated attacks from succeeding.

In theory, the RASP and WAF could coordinate on application metadata, routes, threat intelligence, dangerous IP addresses, and the like. However, for most products, this integration would likely involve a SIEM and some custom integration steps.

All the RASP products on the market are a little bit different, so in this section, we’ll explore a few of the common topics associated with RASP deployment. All RASP products work differently, and you will want to evaluate them to ensure that they work in your environment.

You’ll want to include a number of different stakeholders:

• Security: Obviously, security plays a key role in any defenses. With RASP, you want to be sure that they understand the benefits not only to operations, but also to development and how RASP can help them manage the security workload more effectively.
• Operations: In most organizations, the operations team is responsible for ensuring that applications and APIs are operating normally and responding to incidents. They are often overwhelmed by false alarms, so ensuring that they understand the benefits of RASP and getting their endorsement is key.
• DevOps: As DevOps teams take over more and more of the security and operational aspects of their applications and APIs, they should also be deeply involved in using RASP to both prevent attacks and provide threat intelligence to development teams to help prioritize defenses.
• Executives: If your organization is undergoing a digital transformation initiative, a strategic shift to DevOps, or a move to the cloud, you should try to get them involved in the decision to move to RASP. Not only will it be important for them to understand RASP and what it can do, but their involvement can be critical for a successful deployment.

Some primary technical considerations include:

• Languagesupport: Different vendors support different languages, so you’ll want to ensure that they cover the languages that your important applications and APIs are written in.
• Framework support: Just as important as language coverage is application framework coverage. Unless your RASP supports your frameworks, it will not be effective against attacks.
• Rulesetcoverage: Look for a broad ruleset that covers the types of attacks that you are concerned with. This should include both common vulnerabilities classes as well as disclosed vulnerabilities (CVEs).
• Accuracy: You’ll want to evaluate accuracy by using an application a realistic set of real vulnerabilities. Test carefully that the RASP prevents exploits without interfering with application use.
• Performance: RASP latency varies widely, from just a few microseconds up to many milliseconds. Simply test your application’s performance both with and without RASP in place.
• Scalability: Be sure to evaluate whether RASP will scale to hundreds or thousands of applications and APIs. How do alerts and notifications work? How do integrations with SIEM work?
• Visibility: Does the RASP have its own dashboard? Or does it rely on SIEM only? What alerts, notifications, and reports are available? Are SIEM plugins available?
• Installation: Most RASP products are simple to install and use as they don’t require any network changes. Can installation be automated? Can RASP be added to containers and images so that it is automatically present for new applications?
• Configuration: Does RASP require static or dynamic analysis of the application, configuration, or database schema in order to provide protection? Can RASP be installed in default configuration in block mode without adversely affecting applications?
• Administration andupdates: Is there a centralized way to update RASP rules and functionality? Are software updates automatic? Does RASP include enterprise features like LDAP integration, strong authentication, enterprise grade access control, encryption of data in transit and at rest, and full security logging?
• Integration: Does RASP provide plugins for common security and DevOps technologies? Is there a full API for all data collected? Does the API also include functions enabling administrator to take actions?

RASP can be evaluated quickly because it doesn’t require complex network changes. You can deploy RASP on a few applications, run some tests, check some features, and decide.

In this section, we explore how to use RASP to solve common security problems.

Preventing Exploits

In general, RASP can deal with attacks on vulnerabilities in the software itself, not container, operating system, or network attacks. Every product is different, but RASP can protect typically protect against attacks like:

• Cross-site scripting
• Path traversal
• Command injection
• SQL injection
• NoSQL injection
• HTTP method tampering
• Expression language injection
• Untrusted deserialization
• XML external entities
• OGNL injection
• Cross-site request forgery
• Server-side request forgery
• Regex DOS
• Padding Oracle

RASP does not typically work on network layer attacks such as:

• Distributed denial of service (DDOS)
• Insecure SSL configuration

Using RASP to Protect New Custom Code

In a world of high-speed software development, performing full software verification of all new code before it is deployed is often impossible. RASP can provide strong protection in the gap between deployment and completing security testing. Having RASP in place can provide the extra protection that will allow you to deploy safely at high speed without security bottlenecks.

Using RASP to Reduce Application Vulnerability Backlog

Whether you have one application or tens of thousands, everyone has vulnerabilities in their codebase. Working through this backlog could take many years of development. RASP shouldn’t be used as an excuse to give up on writing secure code, but it can provide significant protection during the “window of exposure” before vulnerabilities are remediated.

Using RASP to Protect APIs

APIs are difficult to protect for two reasons. First, from a protocol standpoint, they are far more complex than simple web sites. APIs are often HTTP with a JSON, XML, binary, or other payload. APIs might also use a non-HTTP protocol such as WebSocket. The second reason is that API data and control flows within software are often far more complex than simple websites. Most APIs use a software framework with features like automatic payload parsing and object mapping. Many use annotations to route data to the appropriate methods.

Web API attacks are generally similar to normal web application attacks (including various types of injection, XML, and JSON parser flaws), and RASP is ideal for solving these challenges because it works at the application layer, after protocol and data format issues have been resolved. This approach allows APIs to be protected against attacks, just like full web applications.

Using RASP to Protect “Internal” Applications

As the “perimeter” crumbles, the difference between “internal” and “external” applications disappears. “Internal” applications are generally only intended for employee and partner use, while “external” applications are for public access. However, internal web applications and APIs are increasingly exposed to the same threat-facing external applications. Often, the applications only intended for employees include more sensitive data and have more powerful capabilities than their public-facing brothers and sisters. Because RASP is software and can be easily and widely deployed, it’s now possible to protect all applications and APIs in your portfolio.

Using RASP to Protect Backend Interfaces

RASP is not limited to frontend interfaces or HTTP. RASP can protect the entire attack surface, including all kinds of attacker-controlled data sources. For example, RASP can protect against databases, message queues, socket connections, file shares, mainframes, ftp sites, and other sources that you can’t fully trust. You could try to use a perimeter approach, but no such devices exist. And even if they did, imagine the complexity of interrupting all backend connections coming from an application or API. RASP is protocol-independent, so it can protect all front and back doors at once.

Using RASP to Protect Open Source

While open-source vulnerabilities often seem like a flood, the situation is usually considerably worse than it appears. There are millions of open-source libraries in existence, and only a handful of security experts testing them. RASP can protect open-source against both newly disclosed vulnerabilities (CVEs) and latent vulnerabilities that are still undiscovered. In either case, if the vulnerability is of a known class, like SQL injection or cross-site scripting (XSS), RASP prevents it from being exploited. So, your open source is protected regardless of whether or not the vulnerability has been disclosed. In this way, RASP keeps the “window of exposure” to an absolute minimum.

Using RASP to Protect against Novel Vulnerability Classes

No security solution can claim to protect against types of vulnerability that haven’t been discovered yet. Historically, new classes of vulnerability have emerged at a rate of about one or two a year. And there are also occasionally specific vulnerabilities that only apply to a single library or component. Because it takes so long for organizations to learn about these new issues, the window of exposure for these novel vulnerabilities is often months or more despite attacks starting within days. However, RASP provides the infrastructure to deploy protection quickly and effectively, regardless of what measures are required. The new defense might come in the form of a new sensor, rule, or capability, or a virtual patch. RASP allows these updates to be made across an entire application portfolio within hours. The alternative is to scan for problems, wait for software updates, replace libraries, recode applications, retest, and redeploy all affected applications. 

Threat Intelligence

Most organizations are completely blind when it comes to application threat intelligence. They do not know who is attacking them, what attack vectors are being attempted, which applications are being targeted, and which parts of the attack surface are affected. If an organization does have information, it is almost always buried in a mountain of false positives.

Using RASP to Create Visibility

RASP is excellent at identifying application layer attacks and creating visibility. RASP continuously provides information about who is attacking you, what techniques they are using, and which of your applications are being targeted. In addition to full HTTP request details, RASP provides application details including the exact line(s) of code associated with a vulnerability, exact backend connection details (like SQL query), transaction information, and currently logged-in user.

Collecting threat and attack information is just half the problem. The other half is making it useful to all the employees that need the information through the tools they are already using. Some RASP solutions simply send their data into a SIEM, which will require custom reports to make sense of the data. In some cases, a SIEM plugin is provided to help interpret the data. Other RASP providers also provide an integrated console/dashboard.

Enhancing Logs With Security Telemetry

Most applications do not perform sufficient security logging. Logs are full of exceptions and debug information but aren’t complete enough to identify attacks or diagnose their impact. Some RASP implementations can enhance security logging without requiring changing software or redeploying. Essentially, RASP weaves enhanced security logging into the application as it loads, without requiring code changes or redeploying. With more complete security logs, your SIEM can be more effective at identifying attacks and breaches. This can create much better visibility around what is occurring in the application layer for the SOC.

RASP Is Not For Vulnerability Discovery

Discovering vulnerabilities is not a use case for RASP. Some organizations have tried to claim that if you use dynamic scanning (DAST) and RASP together, they form an effective vulnerability detection solution — even suggesting that the combination constitutes IAST. This is nonsense. At best, this might help confirm some of the vulnerabilities that the DAST tool identifies. But it has all the problems and limited coverage of a DAST scanner, and RASP does very little to improve coverage or accuracy. If you’re interested in vulnerability analysis, interactive application security testing (IAST) is very compatible with RASP, and some vendors are offering integrated IAST/RASP agents.

As software development projects move towards DevOps, the process of moving software into production accelerates, which makes WAFs increasingly difficult to keep up-to-date. RASP is ideally suited for DevOps, as it is just part of the software that gets deployed.

Because RASP isn’t a hardware box, it can be deployed easily to all environments, including development and test. Using RASP provides instant visibility to the entire development team that will help to prioritize work on security defenses. Furthermore, using RASP during development and test will prove that the application functionality works with RASP engaged. You deploy exactly what you tested… including RASP. This is a DevOps principle for ensuring reliability in production.

RASP is well established in the market, with numerous vendors and many large deployments. But there is still significant room for innovation in the RASP market. Look for vendors to expand language/framework coverage, expand protection capabilities, and even add novel techniques that are brand new for the application security industry.

Here are some sources of additional information.

• Gartner RASP Definition
• What Is an IAST?
• Gene Kim, “The Phoenix Project”
• Security at DevOps Speed and Portfolio Scale
• Ed Amoroso, “Explode, Offload, Reload”
• Securosis, “Understanding and Selecting Runtime Application Self-Protection”