RASP, also known as Runtime Application Self Protection, is one of the most modern technologies that protect running applications. Compared to the WAF perimetral approach, a RASP protects the applications from the inside. This means that a RASP has much better visibility of the dataflow and the consequences of each input that the application receives. This post will describe how a RASP works, the key advantages, how it compares to perimetral defenses (WAFs, Web Application Firewalls), and also how it can be leveraged by the key teams involved in the Software Development Lifecycle (SDLC).
Table of contents
What is RASP? Runtime Application Self Protection
How does RASP work?
What are the main benefits of a RASP
WAF vs RASP
What is a WAF?
How are RASPS typically used (RASP use cases?)
What are the main drawbacks of RASPs?
What types of risks can a RASP protect from?
What is Hdiv protection (RASP)
What is RASP? Runtime Application Self Protection
RASP, Runtime Application Self Protection, is a modern Application Security technology that protects web applications from attacks during runtime. Its goal is to prevent malicious actors from compromising internet applications and APIs by abusing coding vulnerabilities such as SQL Injection, Insecure Deserialization, XSS, etc.
Additionally, the best RASPs in the market also offer protection from design flaws (parameter tampering, workflow abuse, etc.) also known as business logic flaws.
RASPs are an effective complement and/or upgrade from WAF products, a mainstream protection technology that is not adapting well to the new development approaches such as cloud deployments and DevOps methodologies. They are particularly recommended for systems where security is paramount because a RASP brings security-in-depth and dramatically reduces the chances of security breaches.
RASP systems typically provide different modes of operation: the “block” mode stops malicious requests to vulnerable points, and the “monitor” mode records and notifies attacks to vulnerable points but does not block requests.
How does RASP work?
The RASP protection philosophy is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. In general, it works by inserting sensors in the existing application code to monitor and control certain critical execution points, in real-time. By means of those techniques, RASPs become part of the system so your applications remain protected wherever they go. As the acronym indicates, a RASP enables applications to protect themselves.
One of the main advantages of the RASP technology is its privileged point of view to conduct security analysis. This point of view combines full visibility of the internal architecture details of the applications and full visibility of the execution flow during runtime. This means that a RASP can make very smart decisions about what is an attack and what is not.
A positive consequence of this architecture is that a RASP will only intervene if a payload hits a truly vulnerable point of the application, resulting in better performance and no false positives.
Many serious OWASP Top 10 risks, such as insecure deserialization and XML External Entity can only be protected effectively by a RASP, due to its combination of static and dynamic point of view. For more details about the main RASP benefits see the next section of this document.
What are the main benefits of a RASP?
1. Dramatic false positive reduction
RASPs avoid false positives because they make informed decisions thanks to the rich information from the application architecture (static view) and the runtime execution (dynamic view). This means that they are right in the overwhelming majority of cases, which is critical to preserve the final user experience. This compares to WAF, a mainstream perimetral protection technology discussed in detail later in this document, which experiences much more frequent false positives. In fact, 3% of Ponemon [1] respondents indicate that their WAFs are in “Detection/Alert only mode” because of the frequent false positives.
2. Strong protection, including zero-days
RASPs protect from many types of security risks above and beyond injections, including several OWASP Top 10 risks such as insecure deserialization, IDOR, Weak Randomness, CSRF/SSRF, and untrusted client activity. Why is this important?
According to a survey of WAF users by Ponemon, 65% of respondents say attacks are bypassing the WAF. Even worse, only 9% of the survey respondents indicate that their WAFs have never been breached.
Many of these risks can only be protected by a RASP approach.
3. Easy maintenance
RASPs are frequently “set and forget” addons. There are no traffic rules to configure, no learning processes, and no blacklists. Operations teams love this reliability and CISOs appreciate the resource savings. Applications become self-protected and remain protected wherever they go.
4. Adaptability to new standards
RASPs adapt easily to application architectures that do not rely on HTML standards such as JSON and SOAP. RASPs can even protect non-web standards such as XML or RPC.
5. Cloud support
Self-protected applications means that the code is protected wherever it goes. The configuration of a RASP tool can be incorporated in the build scripts that generate and containerize an application, so it will remain protected anywhere it is deployed. No need to update network and firewall rules.
Protection-as-code means that the applications can scale effortlessly.
6. DevSecOps support
Popular security industry best-practices such as “push left,” which means that the implementation of application security should happen earlier in the SDLC, are great on paper. In reality, developers lack helpful advice on the security of their code to fully adopt push left practices. RASPs close this gap by providing actionable security information (including file, line, type, and severity) back to the developer so that vulnerabilities can be fixed quickly. Most RASPs integrate natively with bug tracking tools (Jira, Asana), CI/CD (Jenkins), SIEMS, and other ops management tools (Syslog).
WAF vs RASP
What is a WAF?
Web Application Firewall (WAF) is a mainstream web protection technology that has enjoyed broad market penetration over the past decade. The WAF protection approach is based on defining a perimeter controlled by a chokepoint that monitors and analyzes all incoming web traffic, looking for predictable data patterns associated with known attacks. This protection technique is called input validation, and the data patterns, WAF protection rules.
A WAF is not aware of the true weaknesses of the application, so it must validate all input before it reaches the application itself. Similarly, a WAF is unable to see the consequences of a payload. For instance, a very dangerous consequence of an SQLi payload would be to have two SQL statements, as opposed to one. To circumvent this lack of context, some WAFs implement machine learning systems to detect anomalies in the traffic that might indicate attacks. They require a training process so that legitimate traffic can be identified. All this introduces delays and increases the chances of accidentally blocking legitimate traffic, which damages the user experience.
Being external and technology-agnostic (i.e. the programming language of the protected platform is irrelevant), WAFs are relatively easy to connect to any web application. However, the same characteristics drive insufficient coverage, poor performance, complex expensive management, and lack of native cloud support.
Application security risk types
To better understand the benefits of runtime application security protection technology, it is important to first review the different types of risks. For each of the four families of risks, the table below describes the protection level of WAFs and RASP approaches.
Architecture design
WAFs and RASPs protect the applications using two very different approaches. The differences include the point of view (external vs internal), the protection techniques, and the deployment flexibility. The table below compares WAF and RASP from an architectural and design perspective.
| WAF | RASP | ||
| Technology | Architecture Philosophy | External (perimeter) A WAF will review all the input and compare a blacklist of known attacks. |
Internal (app server agent) Hdiv analyzes the consequences of the traffic |
| Protection Technique | Input Validation The protection is based in pattern-matching |
Instrumentation It is aware of the vulnerabilities of the app and the consequences of each payload in real time |
|
| Zero day protection | No A WAF Requires specific patches for each new vulnerability |
Good Many zero-days are prevented by design |
|
| Deployment | Cloud-friendly | No | Yes |
| Overhead | High All input is validated always |
< 5% Only runs when necessary |
|
How are RASPs typically used (RASP use cases?)
Different teams approach the application protection problem with different needs and pain points. RASPs provide flexibility to accommodate the main teams involved in the Software Development Lifecycle (SDLC)
| DEVELOPMENT TEAMS | |
|---|---|
| Main motivations | ”Secure applications begin with secure code, but fixing vulnerabilities takes time. In the meantime, it would be great if my apps are protected” John, developer at bank |
| Main pain points | – Lack of awareness of the code protection performance – WAFs don’t make your code safer – Dependence on ops |
| RASP as a Solution | 1. Feedback loops: attack visibility means that developers understand precisely how the application is being attacked, just as it happens. Developers can review full attack information, with tools that they already use, such as Jira, or syslog. 2. Actionable advice: The attack information includes the frequency of the attacks, and the severity, which helps triaging and prioritizing patches. 3. Protection becomes code: code is easier to maintain than infrastructure. It can be checked in traditional repositories, and becomes simply another code artifact. This means great portability, and cloud support. Developers appreciate that the applications are protected wherever they go. |
| QA ENVIRONMENT | |
|---|---|
| Main motivations | ”Before I approve this application for production deployment, I want peace of mind that its vulnerabilities will not be exploited” Anonymous, QA team member at healthcare org |
| Main pain points | – Tight deadlines – Frequent code changes driven by CI-CD pipelines – Expensive and slow penetration testing |
| RASP as a Solution | 1. Immediate reporting: No need to wait for pentesting or lengthy scanners result 2. DevOps, no problem: RASP protection is DevOps-friendly and it works well with CI/CD tools. Once the application deploys, it is automatically protected from the inside. 3. Realistic testing conditions: QA teams want to experience the apps as closely as possible as the production runtime. RASP can be easily integrated in the QA builds so that all validation and approvals can be as realistic as possible |
| OPERATIONS | |
|---|---|
| Main motivations | “Automatic protection from as many as possible types of attacks is what made me recommend Hdiv RASP” Mikel, Site Reliability Engineer at a government agency |
| Main pain points | – False positives – Imperfect WAF protection – Difficult configuration – Single point of failure – Performance latency |
| RASP as a Solution | 1. “SPF 100” Broad spectrum protection: RASP technology protects from most types of application-level attacks, including those that can not be detected with AST tools, and are invisible to perimetral WAF defenses. 2. No false positives: ops teams care about the reliability and overall user experience. The worst possible case is to block legitimate activity because of a false positive attack identification. RASPs avoid this damaging situation. 3. Better performance: RASPs only consume precious CPU execution time when it’s strictly necessary. Better application visibility means faster execution and less latency. |
What are the main drawbacks of RASPs?
RASPs maintain an intimate relationship with the systems being protected, which requires mutual compatibility. RASP tools are built with a programming language in mind. For instance, a RASP designed to protect a Java system will not work in a .NET or PHP application. In any case, the most common programming languages used in web applications are broadly supported by modern RASPs.
What types of risks can a RASP protect from?
Risks [1], [2], [3], [5], [7], [8], [9], [10], [11] y [12] are protected by Hdiv using vulnerability detection + payload grammar analysis. The [13] risk is protected by Hdiv using automated random token generation. The [14] and [15] risks are protected by Hdiv using automatic whitelist.
What is Hdiv Protection (RASP)
Hdiv Protection (RASP) is a fully-instrumented RASP solution that blocks and monitors attacks to the applications. The protection includes most of the OWASP Top 10 risks, including those that are considered design flaws (also known as business logic flaws).
The Hdiv protection technology is designed to be fully integrated with agile SDLC methodologies such as DevSecOps. It can be incorporated into the applications automatically and it adapts well to ever-changing cloud environments.
Since Hdiv Protection (RASP) is aware of the true vulnerabilities of the application, it will only act when a payload can cause damage to the system. This eliminates false positives and improves performance. Hdiv RASP helps to implement compliance requirements, such as PCI, GDPR, and NIST.
Hdiv Protection (RASP) is one of the most mature products in the RASP category. Its ample Production installed base includes Government institutions, Military organizations, Banking firms, and eCommerce companies.
Sources
[1] The Top 5 Reasons Why WAF Users Are Dissatisfied, via Ponemon data