RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.
What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?
A deeper dive into RASP
Gartner defines RASP as “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.” Many IT organizations already deploy them, often in conjunction with other security solutions.
An ideal RASP promises:
- Deeper-rooted code-level visibility into applications
- Passive and active incident response features such as monitoring/alerting and blocking modes
- Configurable options to log, alert, challenge, or block malicious behaviors
- Support for many languages and execution platforms
- Autonomous operation without manual tuning
- Coverage for a broad set of vulnerabilities, including OWASP top 10
- Integration with secure software development lifecycle (SSDLC) and monitoring tools.
RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.
RASP advantages
Watches rather than predicts
Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.
DevOps-centric attack visibility with better SSDLC integration
RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.
No training required
An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.
Provides time to fix vulnerabilities
Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.
Cloud agnostic
The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.
RASP disadvantages
Confined context
Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained; they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.
Use case abuse
We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.
| Normal API request by Robby to fetch his profile |
BOLA Attack: Robby changes his user id in the
request and reaches Ava’s profile |
<code>
REQUEST
===============
GET /customer/
12548
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12548
“fName”: “Robby”
“lName”: “Saxton”
“phone”: “202-555-0128”
“ssn”: “987-65-4325”
“address”: “3454 Crummit Lane,
Omaha, NE
68114”
}
</code> |
<code>
REQUEST
===============
GET /customer/
12549
/profile
Host: shop.store
Cookie: session=
5015ee5d-6133-cab4874b
Accept: application/jsonRESPONSE
===============
HTTP/1.1 200 OKContent-Type: application/json{“id”:
12549
“fName”: “Ava”
“lName”: “Rose”
“phone”: “340-5556-577”
“ssn”: “449-26-2109”
“address”: “4702 Gordon
Street, Chino, CA
91710”
}
</code> |
Missing distributed protection
Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.
Intrusive deployment
RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.
Deployment challenges
Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.
Unintended consequences
Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.
Performance degradation and impact on service level agreements
In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.
Too much reliance
RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.
You deserve better
RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.
There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.
