Updated 9-13 to include business requirements

The primary function of RASP is to protect web applications against known and emerging threats. In some cases it is deployed to block attacks at the application layer, before vulnerabilities can be exploited, but in many cases RASP tools process a request until it detects an attack and then blocks the action.

Astute readers will notice that these are basically the classic use cases for Intrusion Detection Systems (IDS) and Web Application Firewalls (WAFs). So why look for something new, if other tools in the market already provide the same application security benefits? The answer is not in what RASP does, but rather in how it does works, which makes it more effective in a wide range of scenarios.

Let’s delve into detail about what clients are asking for, so we can bring this into focus.

Primary Market Drivers

RASP is a relatively new technology, so current market drivers are tightly focused on addressing the security needs of two distinct “buying centers” which have been largely unaddressed by existing security applications. We discovered this important change since our last report in 2017 through hundreds of conversations with buyers, who expressed remarkably consistent requirements. The two “buying centers” are security and application development teams. Security teams are looking for a reliable WAF replacement without burdensome management requirements, and development teams ask for a security technology to protect applications within the framework of existing development processes.

The security team requirement is controversial, so let’s start with some background on WAF functions and usability. It’s is essential to understand the problems driving firms toward RASP.

Web Application Firewalls typically employ two methods of threat detection; blacklisting and whitelisting. Blacklisting is detection – and often blocking – of known attack patterns spotted within incoming application requests. SQL injection is a prime example. Blacklisting is useful for screening out many basic attacks against applications, but new attack variations keep showing up, so blacklists cannot stay current, and attackers keep finding ways to bypass them. SQL injection and its many variants is the best illustration.

But whitelisting is where WAFs provide their real value. A whitelist is created by watching and learning acceptable application behaviors, recording legitimate behaviors over time, and preventing any requests which do not match the approved behavior list. This approach offers substantial advantages over blacklisting: the list is specific to the application monitored, which makes it feasible to enumerate good functions – instead of trying to catalog every possible malicious request – and therefore easier (and faster) to spot undesirable behavior.

Unfortunately, developers complain that in the normal course of application deployment, a WAF can never complete whitelist creation – ‘learning’ – before the next version of the application is ready for deployment. The argument is that WAFs are inherently too slow to keep up with modern software development, so they devolve to blacklist enforcement. Developers and IT teams alike complain that WAF is not fully API-enabled, and that setup requires major manual effort. Security teams complain they need full-time personnel to manage and tweak rules. And both groups complain that, when they try to deploy into Infrastructure as a Service (IaaS) public clouds, the lack of API support is a deal-breaker. Customers also complain of deficient vendor support beyond basic “virtual appliance” scenarios – including a lack of support for cloud-native constructs like application auto-scaling, ephemeral application stacks, templating, and scripting/deployment support for the cloud. As application teams become more agile, and as firms expand their cloud footprint, traditional WAF becomes less useful.

To be clear, WAF can provide real value – especially commercial WAF “Security as a Service” offerings, which focus on blacklisting and some additional protections like DDoS mitigation. These are commonly run in the cloud as a proxy service, often filtering requests “in the cloud” before they pass into your application and/or RASP solution. But they are limited to a ‘Half-a-WAF’ role – without the sophistication or integration to leverage whitelisting. Traditional WAF platforms continue to work for on-premise applications with slower deployment, where the WAF has time to build and leverage a whitelist. So existing WAF is largely not being “ripped and replaced”, but it is largely unused in the cloud and by more agile development teams.

So security teams are looking for an effective application security tool to replace WAF, which is easier to manage. They need to cover application defects and technical debt – not every defect can be fixed in a timely fashion in code.

Developer requirements are more nuanced: they cite the same end goal, but tend to ask which solutions can be fully embedded into existing application build and certification processes. To work with development pipelines, security tools need to go the extra mile, protecting against attacks and accommodating the disruption underway in the developer community. A solution must be as agile as application development, which often starts with compatible automation capabilities. It needs to scale with the application, typically by being bundled with the application stack at build time. It should ‘understand’ the application and tailor its protection to the application runtime. A security tool should not require that developers be security experts. Development teams working to “shift left” to get security metrics and instrumentation earlier in their process want tools which work in pre-production, as well as production.

RASP offers a distinct blend of capabilities and usability options which make it a good fit for these use cases. This is why, over the last three years, we have been fielding several calls each week to discuss it.

Functional Requirements

The market drivers mentioned above change traditional functional requirements – the features buyers are looking for.

• Effectiveness: This seems like an odd buyer requirement. Why buy a product which does not actually work? The short answer is ‘false positives’ that waste time and effort. The longer answer is many security tools don’t work well, produce too many false positives to be usable, or require so much maintenance that building your bespoke seems like a better investment. RASP typically provides full capabilities without the need for run-time learning of application functions, offers broader coverage of application threats by running in the application context, and can run in blocking mode. This last is especially important in light of current application threats, such as the Capital One cloud hack.
• API Support & Automation: Most of our readers know what Application Programming Interfaces (API) are and how they are used. Less well-known is the rapidly expanding need for programatic interfaces in security products, thanks to application delivery disruptions brought by cloud services and DevOps. APIs are how we orchestrate building, testing, and deployment of applications. Security products like RASP offer full platform functionality via API – sometimes as build server plug-ins or even as cloud services – enabling software engineers to work with RASP in their native metaphor. And they provide agents, containers, or plug-ins which work within the application stack.
• Coverage & Language Support: This is still the biggest issue, and one that hampered RASP adoption for the first few years of existence. Learning an application and being able to analyze and block requests is often language specific. The biggest divide between RASP providers today is their platform support. For each vendor we spoke with during our research, language support was a large part of their product roadmap. Most provide full support for core platforms like Java and .NET; beyond that support still a little spotty with Python, PHP, Node.js, and Ruby. Another part of the problem is the complexity of the environment; not just the server side but the client side as well. Over the last few years we have witnessed an expanding universe of frameworks, client side utilities, web-facing APIs and changing fashions for data encoding. Consider that RASP needs to parse XML and JSON, handle diverse clients running Javascript and Angular.js, micro-service architectures and possibly multiple versions of APIs all at the same time. The diversity of application environments makes it challenging for all RASP vendors to provide full support. If your application doesn’t run on a standard platform you will need to discuss support in great detail with the vendors prior to purchase. Within the next year or two we expect this issue to largely go away, but for now it is a key decision factor for buyers.
• Pre-Deployment Validation: The earlier in the production cycle errors are discovered, the easier – and cheaper – they are to fix. This is especially important for expensive of dangerous technologies such as cars and pacemakers. So testing in general, and security testing in particular, works better earlier in the development process. Rather than relying on vulnerability scanners and penetration testers after application deployment, more and more application security testing is performed pre-deployment. Of course this is possible with other application-centric tools, but RASP is easier to build into automated testing, can often determine which parts of an application have vulnerabilities, and is commonly used during red-team exercises and pre-production ‘blue/green’ deployment scenarios.

Business Requirements

We want to add some additional nuance to the use case above, and look at some of the business drivers to invest in this type of technology. These topics lead directly to selection criteria which we discuss later in this series.

• Integration with Trouble-Ticketing: Pretty much every security platform must now integrate with internal systems for tracking security issues as they are discovered, investigated, fixed, tested and then re-deployed. As trouble ticketing systems for the backbone of these efforts, and how tasks get assigned to the appropriate party, this type of integration is essential. We still get user requests for integration with Syslog, SIEM or Splunk, which is usually in addition to tracking software, and these features are provided by most vendors.
• Application Awareness: As attackers continue to move up the stack, from networks to servers to applications, attacks tailored to application frameworks and languages are becoming the norm. RASP differentiates on its ability to include application context in security policies. Many WAFs offer ‘positive’ security capabilities (whitelisting valid application requests), but embedding within applications provides additional application access and instrumentation to RASP. Further, some RASP platforms assist developers by referencing modules or lines of suspect code. For many development teams, better detection capabilities are less important than having RASP pinpoint vulnerable code.
• Compliance: WAF was widely adopted as PCI-DSS contractually mandated security for systems that processed credit card data, and specifically listed web application firewalls as an appropriate control for web facing applications. As WAF’s popularity wanes, but the PCI requirement remains, RASP is being looked upon as a compensating control.
• Scalability and Elasticity: RASP embeds within the application or the supporting application stack. In this way RASP should scale with the application, in the same manner as the application. For example, if the scalability model means more copies of the application running on more server instances, RASP — being embedded in the application — will be run atop more server instances as well. If deployed on virtual or cloud servers, RASP benefits from added CPU and memory resources along with the application. From a latency perspective, RASP enforcement rules — both how they operate and the number of checks employed — needs to be considered. The more analysis applied to incoming requests grants better security, but comes at a cost of latency. If third party threat intelligence is not cached locally, or or external lookups are used, latency increases. If the sensors or integration points are purely event collection, and the events are passed to another external server for analysis, you balance added services with increased latency. As we recommend with all security products, don’t trust vendor supplied numbers, rather run tests in your environment with traffic that represents real application usage.
• Virtual Patching: Most firms have a ton of ‘technical debt’ as applications and the platforms they are build upon have more security flaws than the development team can fix in short order. Keeping development, QA, and production versions of underlying software up to date with basic security patches is a challenge, much less fixing all of the vulnerable code. RASP helps with these problems. First by detecting which versions of application libraries are out of date, and second by offering ‘virtual’ patches by blocking attacks against those supporting services. As most development and operations teams do not track the never ending stream of security patches, having a tool automate discovery and reporting is helpful. Second, in cases where patching a defect is not possible, blocking threats specific to known vulnerabilities provides a workaround and speeds deployment. Seldom is this function in the top 5 list of requirements for firms, but it is still common for most Request For Procedure (RFP) documents.
• Shift-Left: In DevOps, they say that if you do not have metrics, you’re just another guy/gal with an opinion. Metrics are key to determining if you have a problem, where you should direct your resources, and if your security investments are actually working. RASP can catalog application functions, open source usage, understand the correct number and type of parameters, and then apply policies within the code of the running application. But it also can understand runtime code paths, server interaction, nuances of frameworks, library usage, and custom code. This also offers security teams the ability to visualize security issues in code, and better tailor how they wish to respond. And when deployed in pre-production, it allows the discovery of defects prior to rollout into production. Finally, several of the RASP platforms function as IAST, or rather deploy at the developers desktop, to work before code gets checked into the main code repositories, finding and allowing developers to fix issues earlier in the process.

When we wrap up this series with a buyer’s guide, we will examine other technical differentiators which come into play during evaluation.

Next we will discuss the three major architectural approaches RASP vendors employ to deliver their solutions.