How RASP complements application security testing to minimize risk

Jul 14, 2018 / 2 min read

Table of Contents

Traditional AppSec testing + RASP

In the era of agile development and outsourcing, implementing a secure software development life cycle (SSDLC) is critical. However, it may not help you achieve the level of risk mitigation you desire. You may need to extend your software security approach to provide an additional layer of protection for applications once they have been deployed. That’s where runtime application self-protection comes in.

As I mentioned in my prior blog post, RASP security products integrate with an application to prevent attacks at runtime by analyzing traffic and end user behavior. When RASP products detect an attack, they issue alerts, block application execution for individual requests, and sometimes virtually patch the application to prevent further attack. They typically integrate with an application at either the language runtime or application server layer, providing function-level code visibility into the application. This allows them to identify attacks more accurately, reducing false positives and reporting or blocking only those actions that constitute legitimate threats.

The question is, should you replace any of your application security testing tools with a RASP solution? The answer is no. RASP should complement, rather than replace, your testing strategy.

Traditional AppSec testing + RASP

Gartner’s 2018 Magic Quadrant for Application Security Testing defines the three traditional types of application security testing as follows:

Static analysis, or SAST, analyzes application code directly during development or testing.
Dynamic analysis, or DAST, analyzes running applications during testing or operations by simulating attacks and observing the application’s reaction.
Interactive application security testing, or IAST, “combines elements of SAST and DAST simultaneously.” IAST analyzes running applications (as DAST does), but it does so through a runtime agent that has visibility into the code (as SAST has).

RASP supplements static and dynamic analysis by providing an additional layer of protection for applications once they have been deployed (typically in production). However, RASP is not intended to replace those activities, for a few reasons:

Certain types of issues are detectable only through manual testing (e.g., certain types of business logic flaws).
Some weaknesses cannot be patched at runtime even if they are detected, since a patch would likely break application functionality (e.g., detection of weak cryptographic algorithms in use).
RASP products are optimized to run in production with minimal latency. Since SAST and DAST are not bound to this timing restriction, they are designed to be more thorough in their detection approach.

RASP and IAST use similar technologies; they both run on the web server and hook into an application’s runtime to detect vulnerabilities more accurately. They differ, however, in their purpose, approach, and output. For example, IAST executes a suite of tests against an application and reports detected vulnerabilities; RASP does not perform comprehensive scans of applications but instead runs in the background, analyzing all application traffic and activity. And whereas IAST runs in test environments, often as part of a broader security testing program geared toward detecting vulnerabilities for remediation, RASP runs in production and reports on or blocks attacks as they occur.

While the benefits of delivering more features to market faster are clear, fewer and fewer organizations will accept the risk of using AppSec testing alone to ensure software moved to production is appropriately secure and compliant. Achieving your risk mitigation goals may require a strategy of blending both testing and protection approaches. RASP solutions complement your AppSec testing strategy, creating the perfect blend of traditional testing and cutting-edge runtime protection.