Using RASP Throughout the Software Development Lifecycle

Most often when we think and hear about RASP security solutions, we tend to focus on their primary use of monitoring and protecting production web applications from known and unknown threats and vulnerabilities.  While this is definitely the most prevalent use of RASP solutions, there are benefits to using them throughout the different phases of the software development life cycle.  Having conversations about security early on in the cycle and using tools like these throughout different phases can help to enhance the security posture of the application and ideally allow for correction of issues prior to moving new code to production.  Below we'll outline the place of RASP solutions in each of the different phases.

Requirements

When developing any application, security should be an important consideration from the very beginning of the planning and requirements phase.  While defining requirements, conversations should be taking place about how to secure the application throughout the various stages of development including what tools can be utilized such as a WAF and a RASP solution.

Design

Once the requirements have been established, while developers are testing out various prototypes and frameworks, a RASP solution such as Security Analyzer could be run with a sample or reference applications to uncover vulnerabilities inherent in the foundational code before a single line of custom code is produced. This would allow all teams to begin evaluating alternatives for more secure implementations.

Implementation

During the actual coding phase, Security Analyzer could be run on the developer’s workstation or shared systems as desired. As new code is implemented, Developers could run the unit tests using a RASP solution and evaluate any new security threats that may have been introduced. This would allow the developers to become aware of the issue early on and take measures to correct the problem before passing the code on to the testing teams.

Verification

During the verification phase, when QA and penetration testing takes place, Security Analyzer would help identify events as soon as the QA team started running through their normal UAT use cases.  This information could then be feed to the penetration testing team. Ideally, both QA and dynamic scanning could be combined via automated testing so that manual penetration tests could concentrate on business logic flaws. Any issues identified during this phase would also provide input into WAF rule creation.

Release

When deployed to production, the WAF and Security Analyzer agents would generate events and the SOC would need to review these results on a regular basis so that the WAF could be tuned to prevent even more issues.

Production

As mentioned early, the primary benefit and use case of RASP solutions in for the monitoring of production applications to alert Operations and Security teams in real time of detected security threats and vulnerabilities.  In addition to monitoring, protection capabilities can be enabled to prevent unwanted OS command execution, serialization attempts, and dangerous form parameter inputs as well as the prevention of exploit attempts and possible probing activity coming from a specific IP address which leads to a more secure application.  

OnGoing Support 

Once applications have been released to production, RASP solutions such as Security Analyzer can be used to help provide security training for developers.  Security Analyzer can be placed on a test instance and prior to user acceptance tests can be used to walk new developers through the application and any issues that are identified. Any of the auditing reports can be leveraged as well as sample events from production or other environments. If Security Analyzer has never been run with the application before, then information can be generated via normal UAT.

Security Analyzer could also be used in conjunction with vulnerable web application training platforms such as those provided by OWASP: bodgeit, WebGoat, and Security Shepherd. This way developers could correlate the information seen in the stack trace with the lesson related information. This effort would allow development, operations, and security teams to start the conversation about how the events could be mapped and routed based on vulnerability type, stack trace information, URL, attack vector, or other inputs.