RASP, or Runtime Application Self Protection, has been around since at least 2012 as coined by Gartner in this article. The technology essentially seeks to move traditional inline protections such as those provided by a web application firewall (WAF) closer to the application. In addition, RASP provides additional context to make more intelligent decisions about application attacks. This is not unique to web application attacks, as RASP can function for any instrumented application. Depending on who one talks to, RASP is either complementary to or a direct replacement for WAF.

As the marketing around these technologies tends to be a bit confusing, it is important to clarify a few things before we get started with a comparison of the two. There are many ways that WAF can be deployed: either traditionally inline in reverse proxy or transparent bridge mode, passively decrypting out of band, as an embedded on-host solution, and even via hybrid architectures such as cloud-based CDN WAF. Other techniques include a distributed WAF or virtual WAF hosted in a cloud environment. Comparably, RASP products are not all architected in the same manner either. The primary difference between RASP and a traditional WAF is the added context, as the analysis engine is driven by instrumentation, not observed traffic. As a technology, RASP has not matured to the point where WAF is today. Nor is RASP supported by such standards as WAFEC. So much of this is very opaque to potential RASP consumers.

The Argument for WAF

When comparing RASP to WAF, be sure to include all WAF or RASP deployment scenarios in the assessment. In some cases RASP is installed as an agent, or possibly exposed as a SDK that developers must make use of when coding their projects. In some instances, mitigation occurs by throwing exceptions and allowing the application’s exception-handling mechanisms to manage the issue. In other cases, inputs and outputs are scrubbed before they can do too much damage. In early versions, RASP was only protecting against legacy attacks such as XSS and SQLi, much the same as a WAF would. In fact, some of these products still function the same way today. When looking at RASP vendors, make sure they are not simply moving WAF logic inwards inside the runtime environment. Compliance frameworks such as PCI DSS do not recognize RASP as an acceptable application security control and attempts to replace WAF with RASP in 2016 may result in backwards momentum for compliance objectives, regardless of actual security impacts.

RASP brings to the table a very compelling argument; that the protection layer occurs as close to execution of code as possible, inside runtime environments such as .NET or Java JVM, and that it is required to install an agent on the server. RASP proponents stipulate that this makes them better suited to stop attacks that are occurring. But that also means these agent-based protections are not useful for applications based on PHP, Ruby, Python, or other languages that do not utilize a runtime environment. Many RASP technologies require that all or at least some of the functionality requires custom development work if you want to utilize the full benefits of their technology. This means custom development is usually required for all the capabilities that the agent alone will not provide.

However, RASP or WAF are, at best, compensating controls. I’m not comfortable with excessive development time spent on compensating controls when that time could be better utilized simply fixing the application vulnerabilities. This is especially important, considering that you may be locked into a code version that brings with it additional RASP licensing costs. This also increases the attack surface, added application complexity and increases overhead on the application server. By focusing on an external component such as a WAF, this creates a philosophical separation of control that allows for a more layered, yet centrally managed control, as opposed to an integrated approach that has multiple management points, scalability concerns, and a potential for human error to impact the consistency of controls. Additionally, WAF products are generally more configurable, but this also speaks to the maturity of the product space as these capabilities have evolved over time due to customer feature enhancements.

RASP also does not provide the same benefits a WAF brings for virtually patching application architectures. When the next TLS bug gets announced with a trendy new name, you will want the protection of a robust reverse proxy that can mitigate that issue in one place until the backend servers can be patched – RASP will not help there. It is also a very dangerous precedent to set that developers no longer need to write secure code, as you will be virtually patching all of their code with an agent inside the runtime environment or by utilizing this new set of SDKs required by the RASP vendor.

The Argument for RASP

On the other hand, RASP is very good at providing visibility into what a request or database response looks like to the application. WAF is usually several layers removed from the application where the request is destined, and after normalization the application may see a very different version of that same request. The WAF will never see the database response coming back to the application, only the http response that is being delivered to the end user. The WAF will never be able to understand data flows inside the application, unless that application is making additional web requests through the WAF to another application. The WAF has no understanding of how the application actually works. Finally, the WAF has no visibility into unhandled exceptions. This is where RASP starts making a lot more sense.

RASP technologies do not suffer from the same issues with false positives or tuning as they typically identify malicious activities that are occurring in real time. The WAF will see a user input the name “O’Malley” in a contact form and flag the blacklisted ‘ character, while RASP never needs to be tuned to ignore that in the last name variable because it did not result in an actual attack. There was no SQL injection attack, and the RASP will not flood the analyst with false positives that must be reduced. WAF typically has very little context other than what is observed from the actual requests passing through it. WAF has to be heavily tuned to understand what is and what is not acceptable. RASP on the other hand, has full visibility and context for what the application is processing, and can simply focus on what is actually impactful.

RASP is also largely protocol agnostic, as it does not rely on network traffic. It is purely driven by instrumentation and a set of rules that governs what an attack looks like from the standpoint of abuse of library calls, or queries and responses with the database. Inside an application, data flows and functions work largely the same regardless of what network protocols data is sent over. That means, in many instances, RASP technology can be extended outside the traditional web application stack that WAF protects to include AJAX, SQL, SOAP and more.

The other area that makes RASP very interesting is that WAF innovation has largely stalled. WAF vendors are not creating many new detection techniques or mitigation mechanisms, but are instead focused on keeping pace with changing architectures and cloud deployments. This is due to the fact that the WAF product space is relatively mature, but is very dependent on the application deployment architecture to function properly. In contrast, RASP is newer and more focused on integrating with server operating systems and application frameworks and languages. Many of the RASP vendors vying for market dominance are being much more forward thinking in their approach as they seek to differentiate themselves as the market leader.

Conclusions

My contention is that the marketing around RASP is very short-sighted as the vendors know most organizations have a limited security budget and they’d rather you buy their RASP product then continue renewing your WAF maintenance. My personal opinion is that RASP offers a very complementary feature set for traditional WAF deployments. The best of both worlds is to deploy both. But, if you can only afford one, utilize the points made above and decide what makes the most sense for your organization.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.