How RASP Complements Application Security Testing to Minimize Risk
Want to learn how to minimize risk other than just through application security testing? Check out this post on RASP solutions.
Join the DZone community and get the full member experience.Join For Free
In the era of agile development and outsourcing, implementing a secure software development lifecycle (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, runtime application self-protection (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 and 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. However, they differ 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 the 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.
Published at DZone with permission of Steve Cohen, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.