RASP Adoption: A View From the Trenches: Part III
In Part III of this series, the author focuses on capabilities offered by RASP technology providers and their use.
Join the DZone community and get the full member experience.Join For Free
In part one of this three-part post, I introduced the basic concept surrounding runtime application self-protection (RASP) and how it differs from web application firewalls (WAF). In the part two, I discussed features and use cases that vendors build on top of this information and how it all works.
In this post, I focus on the capabilities offered by RASP technology providers and their use.
What Can You Accomplish with RASP?
Account takeovers (ATO) are a big threat these days and RASP reduces the time to detect stolen accounts. This technology is also critical for today’s rapid DevOps development cycles; the application will be protected even when there is no time to run traditional testing and security methods prior to deployment.
Security methods such as dynamic application security testing (DAST) and interactive security testing (IAST) are used to remediate issues before the app is in production. and RASP is deployed in the production environment to find and protect against vulnerabilities that make it into the production.
How to Evaluate a RASP Solution
There are three key elements to evaluate when choosing a RASP solution:
- Protection. What languages and frameworks are supported, and what categories of vulnerabilities are successfully mitigated?
- Availability of service. How does the technology respond to valid requests? Does it allow the application to operate properly? Does it avoid disrupting valid uses?
- Performance. How does the solution behave with different loads and stresses? How does that compare to analysis of the system without RASP?
Also consider the following:
- Evaluation plan. To create a plan for evaluating a RASP solution, you need ot articulate the business problem you are solving. A complete plan includes a list of criteria you are looking for, applications to protect, resources available to devote to application security, a timeline for the project.
- Buy-in. Share the plan and evaluation criteria with key stakeholders, to help the team understand why you are not building the solution yourselves, why existing technologies (like SAST and WAF) are not valid options or not enough to provide the protection you need.
- Communication. Make sure to share information with stakeholders to keep them involved, as well as providing feedback to vendors, as they learn from every deployment and continue to improve the technology.
Published at DZone with permission of Goran Begic, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.