Application Security vs. Time to Market

One of the biggest challenges, Security Analyst face is maintaining a balance between the App Security and time to market.

Both are crucial, if balance is not maintained, any one of it is bound to suffer. Once we agree to this fact, then comes the next question how to maintain the balance.

Use Case 1

Security Analyst: Scans the application, triage it and comes out with the Security Assessment report.

Developer: Receives a report, works on it, remediate the vulnerability reported. Plans for re-assessment.

Security Analyst: Re-assess the application, comes out with a re-scanned and re-assessed report.

Concern: :Old issues/vulnerability is successfully closed, but tool has identified few more new issues, issues are of high risk and need to be fixed before production deployment as per the organisation policy.

In this example, many questions will hit your brain, why re-assessment has more findings, why it is not reported in first go, is anything wrong with the tools, so on…

Hold on, Security Analyst and Security Market is always on toes to upgrade their kitty with newly identified vulnerabilities and so the product organisation, they frequently come up with the updated patches and updated rule pack to be applied to the tools.

If you have done an assessment before the patch is updated and re-assessment after the updated rule pack applied, there are changes that re-assessment report has new vulnerability findings which was not reported in earlier report.

Recommendations:

Make the management or business owner aware about this kind of inconsistency. If Risk is high, Security should always be given priority, to decrease the SDLC time alternative compensatory controls should be thought of as an alternative way of mitigation and thus to obtain a security clearance.

But ignoring or hiding the High Risk Vulnerability for that release should never be an option to be considered.

Use Case 2

Security Analyst 1: Scans the application, triage it and comes out with the Security Assessment report.

Developer: Receives a report, works on it, remediate the vulnerability reported. Plans for re-assessment.

Security Analyst 2: Re-assess the application, comes out with a re-scanned and re-assessed report.

Concern: Old issues/vulnerability is successfully closed, but Analyst 2 has identified few more new issues, issues can be of high/medium risk and need to be fixed before production deployment as per the organisation policy.

In this use case, the problem highlighted is about the skills and understanding of two Security Analyst at a similar role. They can have different understanding about the issues and assessment can deviate up to some extent, which should be acceptable up to some extent. But what if high or medium vulnerability is identified in assessment by another Analyst 2, was not reported in initial scan. With this kind of in consistency application development time is exceeding.

Recommendations:

Application Security team should practice below guidelines to minimise the delta.

  1. Prepare a common checklist of vulnerabilities and define its risk level (High, Medium and Low) as per the organisation impact on the application. So that analyst refer to the common checklist and high the issue in a correct category.
  2. Try to do a peer review of the assessment report before publishing, so that others are also on same page and agree on the published assessment report.
  3. Re-assessment to be done by a same analyst if possible, if not they should refer or consult the earlier version of report published.

Conclusion

By incorporating some basic but effective best practices, we can maintain the balance between application security and time to market by not attributing much in the increased SDLC time but at the same time promoting secured development culture.

Authored by Rajeshwari Mishra

Rate this article: 
Average: 2.4 (7 votes)
Article category: