Strategies for Release-Based Security Testing

Change is the only constant in life. Everything, including the applications, are changing. If we juxtapose decade old page of an application with the recent one, it will be too easy to find the changes. From a simple static html page, we are now in a world of dynamic applications with variety of add-ons, flash players and plugins. 

Consider that an application has been tested properly and all the security issues have been fixed, so it has become a secured application. However, later the application may become vulnerable when a new functionality is added. It becomes imperative to assess this functionality too. This signifies the importance of release based security testing where every release is subjected to security assessment.

Should we have any strategy for Release-Based Security Testing? Absolutely, Yes! However, it differs from application to application and from situations to situations. For example, there are some applications, which need to be updated frequently. These updates can be modifications in the code, user interface or even image. For any such modification security assessment is done. As is evident, these tests don’t take much time as the number of modifications are not significant.

The challenge appears when an application makes a big change. In technical term, it is when a new build is deployed and an application leaps from Version X.0 to Y.0. Such a transition is full of Change Requests (popularly known as CRs). There needs to be a proper plan of doing security assessment in such situation.

Here is a basic plan to carry out security assessment on a new build.

1.  All the CRs are provided to the security team. To have a clear understanding of the changes, it is always advisable to    have a demo of the application, with more focus on the CRs. The security team should be absolute sure of scope of scan.  Scanning out of scope functionalities is a waste of time and effort.

2.       After going through all the CRs, the security team makes a Security Test Plan. Some of the important factors that  should be kept in mind while testing are  

  • How frequently are the builds deployed? More frequently means less time for the plan.
  • Number of CRs to test.
  • Availability of security assessment tools.
  • Size of the Security Team.
  • Deadline mentioned by the client.                                           

3.       The test plan is shared with all the concerned teams.

4.       As per the plan, the security assessment is executed. During the scan, the security team may face problems like  application getting down or user accounts getting locked. The security team should know whom to contact in such  situations. This must be discussed with the development team beforehand.   

5.       The report is shared with the development team. The report should properly mention the test cases. All the steps of  recreating the scenario, mitigations and screen shots should be provided.

6.        After the issues are fixed, the Security Team verifies them. In certain applications, the security team does a Sanity  Testing. A Sanity Testing is basically a complete scan of the application. The issues found during the sanity testing are also reported and it is expected to get them fixed in the next build.

It is evident that for a build having large number of CRs, it is imperative to have a proper plan. A proper plan gives the team the right amount of time to assess the CRs properly, prepare reports and verify the issues. A proper plan also gives time to go an extra mile and do a thorough security check of the whole application. Doesn’t it seem that planning is important? Yes, it does! To conclude, I would like to signify the importance of planning using 6 P’s.

Proper Prior Planning Promotes Peak Performance.

Authored By Santosh Mishra

Rate this article: 
Average: 3 (4 votes)
Article category: