The what, why, and who of runtime application self-protection (RASP)

Why RASP?

Organizations are turning to runtime application self-protection because zero-day defects are on the rise. Researchers at Forrester discovered 3,623 new open source component vulnerabilities in 2016 alone, representing a 10% increase over 2015. RASP tools can thwart attacks that target these newly discovered vulnerabilities.

Also, some applications can’t be sufficiently secured prerelease. Security stakeholders can run into cases where applications can’t or won’t benefit from prerelease application security testing, as in these examples:

• Older applications not under active development
• Code developed by third parties
• Applications that are too costly to fix

Who can benefit from RASP solutions?

Security leaders. Runtime application self-protection tools use their deep analysis of an application to block potentially malicious behavior without the learning period that web application firewalls (WAFs) need, and with potentially greater accuracy. Security leaders can use this deep analysis to understand common vulnerabilities and attack techniques and adjust their policies, technical controls, and other mitigation efforts accordingly.

Application security stakeholders. RASP tools can be used to track attempted exploits on vulnerabilities in applications. This data can help stakeholders train developers on secure coding, report defects back to third-party software vendors, and evaluate a vendor’s code quality going forward.

Developers. RASP tools typically give more information than WAFs about where a vulnerability resides in a codebase. Developers need this kind of actionable data to remediate existing vulnerabilities, as well as to learn how to avoid creating such vulnerabilities in the future.

What should I look for in a RASP solution?

To invest in a versatile and well-designed runtime application self-protection solution, select a product with the following attributes:

Visibility into the application beyond what a WAF provides. Because of the way a WAF is positioned on a network, it analyzes only web traffic passed to and from a web server. Thus, it doesn’t have any knowledge of the context of the applications it’s deployed to protect. WAFs operate on data in transit, so they must decode that data before they can properly analyze it for malicious content.

By contrast, RASP tools have an architecture that provides code-level visibility, so they can accurately identify attacks, reducing false positives in the process. They can also analyze all incoming data (after it has been properly decoded or decrypted by the application), resulting in fewer false negatives.

Both passive and active incident response features (e.g., monitoring/alerting and blocking modes). Users should be able to configure a fully featured RASP product to log, alert, and block what it identifies as attacks.

Support for many languages and platforms. Any capable RASP product should offer support for common enterprise languages (e.g., Java, .NET), as well as newer languages and associated frameworks (e.g., PHP, Python, Ruby).

Autonomous operation. Many users have mixed feelings about RASP products that rely on cloud connectivity for data storage and analysis. RASP products using a cloud solution have some unique features and benefits. A cloud server (on- or off-premises) that collects data from multiple deployed RASP agents can analyze data over time to (1) detect potential automated attacks like password guessing and user enumeration attacks and (2) identify typical user behavior, eventually gaining the ability to detect anomalous behavior.

On the other hand, the use of an off-premises cloud introduces some concerns:

• Potential security issues. These may be introduced when private data is sent to the cloud. There’s also the risk associated with opening internal servers up to the internet to establish a connection with the cloud service.
• RASP product failure modes. How well does the RASP product continue to function, if at all, when network connectivity to the cloud is lost or the cloud infrastructure goes down for some reason?
• Configuration complexity. There’s additional overhead to configure enterprise networks to open connections between internal servers and an internet-based cloud service.

Given these concerns, we prefer a RASP product with an on-premises remote server or no remote connectivity whatsoever, even at the expense of losing certain capabilities (e.g., temporal and behavioral analysis and detection).

Coverage for a sufficiently broad set of vulnerabilities. This includes coverage for common web application vulnerabilities, such as cross-site scripting and SQL injection, and for general request validation and behavioral analysis (e.g., detection of automated password guessing attacks).

The right RASP solution is ideal for organizations needing to solve key persistent issues facing AppSec and DevSecOps teams charged with monitoring applications and protecting them from vulnerabilities, whether applications are homegrown or purchased and integrated.