What’s in a Name? RASP Smells like a Rose
“What’s in a name? That which we call a rose by any other name would smell as sweet.” — William Shakespeare
RASP was first defined by Gartner analysts in April 2012 as an acronym for Runtime Application Self-Protection. By their definition, RASP technologies are embedded directly into the application itself, providing web applications with capabilities to defend and protect themselves from attack. This seems straightforward enough, but it’s not quite that simple. Here’s what you really need to know about RASP — and how to choose the right one for your business.
A RASP is a RASP is a RASP … except when it’s not
The first step to understanding RASP technologies, how they operate, and what they provide to enterprise users is to define exactly what it is they are protecting. The term “application” turns out to be a gray area when discussing RASP deployments. Exactly where does an application itself begin and end? It obviously includes the code that the developer writes, but what about the Java or .NET runtime, or the web server instance itself, or the underlying infrastructure that supports the overall application stack? In a modern application architecture, everyone has a different opinion as to where the infrastructure ends and the application begins.
For the sake of this article, let’s limit our discussion to modern web applications as opposed to mobile technologies or other application types. Let’s also assume that modern web applications, microservices, and APIs are generally made up of the same fundamental underlying technologies: a web server, a runtime, and custom-developed code. This three-tier stack makes up nearly all modern web applications in production today.
Fundamentally, web protection offerings, such as RASP, do three things. First, they have to acquire data into the protection system. Then, they have to provide analytics and decision-making capabilities on that data. Finally, like any security tool, they have to produce actionable security-related output. One thing that differentiates one RASP from another is that first step, the location where the data to be analyzed is acquired.
Deployment models must provide a menu of options
Our definition of an application gives us a few points at which a RASP can be deployed to gather data to guide security decisions. Some RASP vendors simply operate as a reverse-proxy process for the app, while others gather data by embedding libraries into the application code itself. Some RASPs modify or “hack” the runtime layer to trap application request data, and still others embed at the server instance as a simple-to-install web server plugin. All of these locations are part of the application stack and considered part of the RASP technology market.
What really matters to enterprise buyers isn’t where the technology deploys into the application stack, though. What they care about is whether the CISO or application security director can take a variety of deployment options to their development and operations team and let them choose how to deploy the protection technology into their particular application stack.
Each RASP deployment model has its strengths and weaknesses for particular situations. A legacy commercial-off-the-shelf (COTS) application with no source code would not work well with a RASP that requires library-based code injection. The process overhead that comes with deep JVM and CLR hacking may not be ideal for the highest scale deployments supporting an extremely high transaction rate API. You should consider the full range of models and give preference to vendors that can provide a broad array of data collection approaches, making it easier to gain coverage over all of your applications, not just the one Java-based system that you have source code for.
The decision engine is the brains of the operation
Just as there are a number of ways that data can be ingested into a RASP solution, the analysis that is performed on the data once it enters the system, and the accuracy of the findings, are extremely important when evaluating a RASP solution. Different analysis models exist within the RASP universe, all with pluses and minuses. It’s not necessarily the type of detection done that matters, but rather, the accuracy and usability of the results, along with the overhead impact on the application itself.
Designed appropriately, decision engines should have little to no impact on the latency and efficacy of an application deployment. As long as the RASP is designed with a cloud back end in mind and uses asynchronous connections for data transfer, the decisions can remain highly accurate while operating in isolation from the enforcement of the current protection set. The ability for a RASP technology to operate without being directly inline with the transaction ensures that it won’t take down the production environment.
Security wins when it becomes embedded into the process
Application security technologies are useless if all they do is dump a huge stack of flaw data, vulnerability information, and attack false-positives onto the desk of the security analyst. These guys are already overworked, and information overload makes them all too likely to miss real attacks and threats against your applications. For successful attack detection and proper response, the workflow and processes must be highly automated, only bringing the most important and highly probable attack data to the analyst’s attention.
RASP gives the enterprise the opportunity to democratize security data by providing consumable, usable, actionable data to the people that need it the most. To do so, the technology must integrate into the workflows and processes that already exist within the security, development, and operational teams in the enterprise, such as ChatOps, incident tracking, CI/CD, automated alerting, and SEIM data aggregation engines. This makes the number and usefulness of the integrations a key consideration. If the RASP you’re evaluating doesn’t integrate cleanly into your current and future development, operations, and security stacks, keep looking.
What really matters — and what RASP buyers really want
What really matters when you buy a web application security solution is security and business value. It’s not about the technology types and terms, like RASP, next generation Web application firewall (NGWAF), or even a traditional WAF; it’s about how well the technology provides security visibility, protection from attack, and help with mitigation and event handling. How well does the technology scale? And can it truly support your business growth and initiatives? When the enterprise CISO, VP of engineering, and operations executives gather in a room, this is what they can all agree on. Don’t buy a RASP or any other solution because it’s an interesting and disruptive technology. Buy it because it improves your security and your business.
Signal Sciences provides web application security solutions that encompass both Next Generation WAF and RASP technologies. Signal Sciences was built in response to our own frustrations of trying to use legacy application security approaches while enabling business initiatives like DevOps, cloud adoption, and CI/CD.
