Gaining truly self-defending application protection requires more than RASPs
RASPs over promise and under deliver
The concept of making applications self-protecting is powerful as cyberattacks continue to grow in frequency and severity. Advanced threat visibility across applications would enable teams to respond to threats in real time.
Original concept was SAST/DAST/IAST application security
The original concept for Runtime application self-protection – RASP – security was to extend static/dynamic/interactive (SAST/DAST/IAST) application security testing technologies to secure web applications against attacks with greater accuracy and deeper insight into application execution. RASPs also promise less overhead than conventional Web Application Firewalls (WAFs). And RASPs also commit to moving security from the network to inside the application during runtime.
While these are all desirable and necessary objectives, in practice, RASPs fall short of making these things happen. RASPs can’t deliver solution completeness, coverage, performance, or manageability – and the lack thereof then places more demands on scarce SecOps resources.
RASPs produce high false positives, demand high expertise, bring high costs
Some of this burden comes because RASPs are heavily dependent on security specialists maintaining rulesets and heuristics. RASPs require technically qualified staff to manage them and generally require integration with application code, resulting in performance impact on the protected runtime environment. Without constant expertise, as well as frequent updates and tuning, these solutions can deliver high levels of false positives (See Prediction Series #6: Alert fatigue undermines security, exhausts SOC teams), overwhelming security teams and distracting from real threats. This dramatically raises operational costs and makes RASPs poorly suited for fast-paced SecOps environments.
RASP technology only protects a small slice of the application stack at the web and interpreted code level. While most RASP solutions inspect HTTP packets to identify known OWASP Top-10 attacks, they do not detect zero-day vulnerabilities, uncommon attacks targeting OS and third-party libraries, or file system attacks. Skilled attackers routinely use these sophisticated methods to bypass RASP security entirely. RASPs can also require extensive support and management for detecting uncommon threats and the results of these settings can dramatically degrade application performance.
In 2019 RASPs won’t measure up
In general, RASPs are proving to be less accurate, more limited, and more difficult to deploy and manage than vendors claim. At best, they are only effective at protecting web applications on specific platforms and for a small portion of the full application surface. True self protection means defending the entire web application stack, including web apps, servers, back-end applications, file systems, process memory and binary code.
In 2019, SecOps teams will increasingly be disappointed in RASP performance and lack of full protection. They will realize they need to move beyond RASPs to find true self-defending application security that protects the full application surface.