Since its emergence in 2012, Runtime Application Self Protection (RASP), a term coined by Gartner’s Joseph Feiman, has seen steady growth with RASP vendors penetrating a number of market segments.
Unlike established security technologies that occupy the perimeter space of IT such as Web Application Firewalls (WAF) or those that statically analyze application code during testing (STAST) technologies, RASP based technologies promise to eliminate false positives, reduce the complexity of securing applications and to lock down the most common vulnerabilities being exploited today.
Security Embedded Within the Application
The proponents of RASP can make these claims as they argue the security intelligence is embedded directly within the application and enabled at runtime. As such, the security intelligence can differentiate between application and user data allowing it to identify illicitly injected code or to detect unusual application activity (indicators of intrusion) with an unprecedented degree of precision.
Furthermore, these security rules can be configured to prevent attempts to access protected compute resources such as file systems and network sockets. Depending on the capabilities of the specific implementation of RASP, these rules can be simple, generic and dynamically adjustable at runtime, without impacting the normal application lifecycle or expected application operation in any way.
RASP technologies protect against some of the most exploited vulnerabilities (as classified by OWASP) including SQL Injection, Command Line Injection and Cross Site Scripting. One may ask how all of this is any different to WAF protection? The distinction comes from of the generic nature of RASP configuration which is a direct product of embedding security intelligence within the application, as opposed to traditional pattern matching techniques employed by WAF.
For example, some RASP technologies can mitigate 100% of SQL Injection attacks with no false positives simply by defining a single one-line rule. Compare this to the complex pattern matching rules employed by WAF which, given their highly specialized nature, result in both large numbers of rules that need to be constantly updated.
While these advantages alone make the case for including RASP in a comprehensive cybersecurity strategy, recently two other significant benefits have come to the fore namely zero day vulnerability mitigation and virtual patching.
Mitigating Zero Day Vulnerabilities
The generic nature of the rules that can be configured for RASP technologies means that they can disable the most common execution vectors exploited by zero day attacks. For example, a RASP enabled Java Virtual Machine can be configured to deny the creation of client and server sockets or file descriptors, either entirely if the application has no need of them or within accepted port ranges and specific file locations respectively.
While the vulnerability still exists in the application logic, exploits are rendered harmless and alerts can be raised for further investigation when illicit attempts are made to access protected resources.
Virtual Patching
Virtual patching is the ability to host legacy code within a virtual container that effectively secures the application as if it was running in an updated and compliant version of the runtime. For example, many enterprises cannot update critical legacy Java applications as they are incompatible with newer versions of the Java Virtual Machine and yet the cost of upgrading the code can also be too prohibitive or the option to upgrade may simply not be possible due to lack of expertise.
Such applications are normally replaced with entirely new applications over time however, until they are replaced they pose a significant risk to the business, one that is potentially legally unacceptable.
RASP implementations with virtual patching capability give the business the option of safely containing legacy applications, running them on up to date and compliant runtime environments but without requiring the recompilation or the code changes that would be demanded by a physical upgrade.
The latest forms of virtual patching can use the same mechanism to replicate critical patch updates giving businesses the option of obviating the need to apply critical binary patches. For large enterprises with 90-day patching cycles that demand considerable orchestration between development teams and operations to organize and system downtime to deploy, this aspect of virtual patching provides considerable cost saving and reduced risk when compared to binary updates.
Evaluating RASP Technologies
Not all RASP implementations are the same and enterprise users need to consider the impact of integrating and deploying RASP technologies in their IT estates. These organizations should carefully measure the impact of any code or configuration changes that may be required to enable RASP on the applications that run on their platforms.
What may seem to be a trivial code or configuration change, when scaled to hundreds or thousands of applications can considerably slow down or reduce the adoption of RASP among application owners who will be responsible for making those changes.
Another common critique of RASP is the expected performance impact runtime analysis and protection. While it is true that early implementation of RASP could cause as much as 10% increase in response times within the application tier, performance is constantly improving with many vendors claiming 5% or less impact on application response times.
It should also be remembered that rewriting insecure code to carry out the kind of protection delivered by RASP will in most instances cause a similar impact to performance.
2015 saw a number of RASP vendors deploy their products into production environments at the enterprise scale and a year on, we find the majority of these deployments to have met the expectations of customers and piqued the interest of their competitors. These early adopters are now driving the refinement of RASP technologies and we can expect the rate of adoption of RASP to continue to increase.