Dear RASP: We Need to Talk About the Friction in Our Relationship
Dear RASP,
It is finally time for me to write you this letter. When we first met you were something new and exciting. I had never seen anything in application security (AppSec) like you before. You were a different and promising solution to mitigate the risks we all worry about as AppSec practitioners. When you told me your name, Runtime Application Self-Protection (RASP), and what you did, all I could say was “wow!” I sure did want to get to know you better.
But the more I got to know you, the more I realized things between us would not work out. I’m sorry about that. Given my decade of experience in large enterprise AppSec, we should have been a perfect match. But the reality is that the approaches taken by most RASP vendors have some issues that I just can’t cope with. I wish I could say it was me, not you, but I’ve been hearing similar concerns from other practitioners that have attempted to deploy you. Even though I’ve moved on from the purist approach to RASP, I want to explain these issues to you and highlight what others have experienced. It’s necessary so you understand how real development and operations teams work to help turn your academic approach into something more pragmatic.
What You Promised
You promised protection from common OWASP injection attacks like SQLi, XSS, Code Injection, Traversal, etc., by hooking into the application at runtime. I admit I was seriously intrigued by this approach of hooking into the runtime. Technically very cool as well as seemingly effective placement in order to ensure detection is accurate and avoids false positives. Analyzing function calls as data flows through the application — very cool. But, after all of this wooed me, reality began to take over.
Friction
For starters, the thought of negotiating with application teams across the enterprise to modify their application runtimes is a very daunting thought. The implementations you offer such as library replacement, modifying bytecode at runtime, or even a full JVM replacement puts me at the bottom of the hill in what will be a long “uphill battle” conversation. I will be challenged on performance and stability concerns. Sure, you claim you’re optimized for performance, but with the parsing and tracing you have to do, your impact is far from zero. Also, any bug in your code could result in disrupting transactions or even bring the application down. If these performance and stability risks are ever realized, I’ll be to blame, and you’ll be removed from the application. Even if a performance or stability incident is not your fault, you’ll be suspect and removed by the application team. I’ll be stuck spending more time persuading application teams to put you back in.
From the financial services industry, other practitioners have said, “We’ve looked at RASP, but we want a layer of protection we can apply that doesn’t introduce so much friction into the process.” In my conversations across enterprises large and small, this sentiment has been echoed repeatedly. In some cases, this friction isn’t even directly related to causing problems in the application itself. For example, in the case of another enterprise attempting to deploy RASP, they found it broke other services that their development team relied upon such an application performance monitoring (APM) tool. The best word that describes you is friction. Your implementation introduces too much friction from both a process and technical perspective.
Too Limited
Even if I invested the effort and political capital to overcome the friction, what am I getting in return? Protection against just OWASP injection attacks is not a great trade-off. I’ve worked hard to establish a mature, secure development lifecycle with SAST, IAST, DAST, and other processes to mitigate the risk of injection attacks. If I’m going to add another layer of protection, especially in production, I want to be able to raise the bar above and beyond OWASP injection attacks. For example, I want to address risks associated with the business context of the application, e.g. sensitive and high-risk transactions. You leave me hanging on this.
You also leave me hanging on the types of applications I’m able to get coverage on. Your language support is limited. Sure we have .NET and Java applications that you support, but we also have applications in other languages like PHP, Node.js, Perl, Python, and, yes, even Cold Fusion. You put me in a situation where I can have coverage on perhaps most applications, but I have to forgo coverage on the remaining applications you don’t support.
Coverage matrix based on information published on the respective vendor’s website as of November 2018. Please report any inaccuracies or omissions.
These issues apply to those trying to deploy RASP regardless of industry vertical. For example, in speaking with practitioners in the insurance industry you left them hanging as well, as they explained, “At this point, we are not really using [a RASP solution] much, and are considering other vendors in the same space.” This was the situation after their development teams migrated their applications to a different application stack.
Inability to Scale
In the end, despite being a different approach to AppSec, the friction you introduce coupled with limitations in coverage results in your inability to scale. In environments where development is moving increasingly faster, I need scalability from both a deployment and resourcing perspective. I can’t waste time and resources debating nuanced runtime conflicts for limited coverage gains.
My feelings about you are only confirmed by the experience of a company in the media industry. A RASP solution was brought in because security resources were limited, and input validation was a primary concern. A year after attempting to deploy to dozens of applications, the effort was abandoned. After the first three deployments, they encountered issues including the RASP solution breaking the application while they attempted to tune it. An AppSec practitioner from this company stated, “It’s hard to get time on the development team calendars, but if they’ve heard that what you want to do has broken things for other teams, it becomes nearly impossible.”
You should also be aware that others are starting to take notice. For some context, see this blog post “RASPing It Up: The What, Why and How” by David C. Thompson of WhiteSource. In particular, the section “Is there a downside?” covers community reservations on performance and per application RASP policy management. Per application RASP policies add overhead to security teams, and moreover, hinder scalability. They don’t work in agile development environments where the code is constantly changing. In some instances, you’ve introduced a “learning mode.” But if the application is always changing, you’re always learning which potentially results in inconsistent protection.
What I want, and what I need, is frictionless RASP that raises the bar in AppSec and scales out across all applications regardless of technology stack or language. In my role as an AppSec practitioner in the financial services industry, I had a choice and I chose frictionless runtime application self-protection. When taking the next step in my career I also had a choice, and I chose frictionless runtime application self-protection.
That was two and a half years ago. Today I see first hand how customers benefit from a truly frictionless RASP solution. Across large and mid-sized enterprises, application teams are able to quickly deploy security with their applications. Moreover, they are able to defend against the threats they face in the real world, beyond just OWASP injection attacks. They have the ability to defend against account takeovers, enumeration attacks, and attacks on business logic (e.g., sensitive or high-risk transactions), which is a critical capability for any application security solution to provide. Having seen all this, I know I made the right choice.
Originally published at labs.signalsciences.com.
