In previous articles, I wrote about the Application Security Testing tools SAST, DAST and IAST, which are designed to help engineers fix problems during the development lifecycle. In this article, I write about a technology designed to protect applications in a production environment. This technology is known as Runtime Application Self-Protection (RASP).
Once an application has been deployed into a production environment, the level of real-time protection moves from proactive preventative measures associated with developing secure products, to reactive remedial measures. For example, traffic to your applications can be monitored by Web Application Firewalls (WAF) for potentially malicious activity and prevent certain payloads from reaching your applications. However, this is a wide-angle approach to a problem that requires a more narrowed focus. Runtime Application Self-Protection (RASP) is designed to run alongside (or even inside) an application to offer protection from malicious activity in real time. Since RASP is able to contextualise the data in relation to the application, it provides more granular protection than that offered by WAF.
From a technology perspective, RASP is an instrumentation tool that typically operates within the language runtime. It’s not unlike IAST tools in this regard. Indeed, some IAST vendors offer RASP as part of their product portfolio. Because RASP interacts within the language runtime, it is able to work at lower levels of an application, giving it an advantage over WAF. For example, where WAF would automatically block strings that look like a SQL injection attack, RASP tracks the string through the application to see whether it is executed within the code before deciding whether to block the value. This focus on the application provides RASP with greater accuracy compared to WAFs.
RASP typically has two defence mechanisms: a passive monitoring and alerting system; and an active system that attempts to directly stop an attack. In passive mode, when it identifies a potential attack or unusual user behaviour, it can send alerts out to engineers who can assess and potentially fix the problem. As mentioned above, since RASP operates within the application runtime, it determines whether the code already handles a malicious payload, and if it does, will not alert engineers. This reduces the risk of alert fatigue while still offering a level of protection for the application. In active mode, the RASP tool actively blocks traffic being sent to a running application if it observes that the malformed data is not handled correctly by the application.
A key benefit to using RASP is its ability to protect applications that may not necessarily be actively supported by development teams. Some RASP tools are able to virtually repair the application without the need for active development. This is allows organisations to minimise the risk of attacks on unsupported applications. Obviously, there is no substitute for fixing the underlying vulnerability, but this technology can provide protection until unsupported applications are finally killed off and taken offline.
Another advantage of using RASP relates to the detection of zero-day exploits that have not yet been fixed by engineers as part of their normal delivery lifecycle. Zero-day exploits occur when a newly found vulnerability is exploited before a patch has been released. These normally appear in third party libraries used within the application. RASP is able to mitigate against the risks of these zero-days being exploited by creating a virtual patch that prevents the vulnerability from being exploited. Obviously, once a patch is available, engineers should endeavour to roll it out as soon as possible to provide greater protection against zero-day vulnerabilities.
Because RASP targets an application while running in a production environment, it is not designed to be integrated into the CI/CD pipeline, and is not integrated into the engineer’s IDE. However, they offer early insights into how an application behaves while under attack allowing engineers to find longer term solutions to improve the security of an application. RASP is complementary to the Application Security Testing tools I described in the first three parts of these series. RASP is not a substitute for weak security within the development process, so should be implemented as an extra layer of security and not as a silver-bullet solution to your security problems.
In summary, RASP provides contextualised protection for an application in a production environment. Because it is instrumenting at the framework runtime level, it provides greater control than a WAF over the way an application manages traffic. RASP offers a layer of protection for applications that are no longer in active development, while also protecting supported applications from potential zero-day exploits. It should be used to supplement security tools used within the development lifecycle, and not as a replacement for them.
In the next article in this series, I will cover Software Composition Analysis (SCA) tools.