Friday, January 22, 2010

Last Minute Security Tradition and Side-Effects

Having driven Secure SDLC in multiple organizations, one of the common challenges I have always faced is dealing with last minute security assessment request and sign-off.

"We have a deadline for application release. The Quality Auditor (QA) needs security assessment team's approval to allow our application release. We need a quick assessment done to get your sign-off on this activity to move it to production" – This may be familiar for many security professionals.

Such last minute request results in – Lots of pressures on the assessment team to perform a quick and limited assessment within the limited time frame. In most cases it may not be adequate to ensure thorough security assessment coverage.

Assume in such last minute situations where security assessment reveals serious security risks and have immediate catastrophic issues to be addressed, which increase the chances of delaying the release dates by few days or weeks beyond the date committed to the customer. Eventually it results into two-folded actions: (a) Apply a band-aid fix and get the application/product release on time, (b) Apply appropriate fix (irrespective of the release delays) and run it through a round of post-fix security validation before release. However, in the former case application team will run the risks of deploying a weakly fixed application which at anytime may get broken by malicious hackers. In the later case, the application team might make the customer unhappy by slipping the release deadline and loses some credibility. Additionally in this case costs might significantly exceed the project budget.

Cut costs. Save money. Maintain the status quo. With that mantra in mind, many application managers work today. Although a sour economy is certainly to blame for some IT budget woes, but much of it also comes from an "ask and ye shall receive" mindset left over from the dot-com boom days. That's all gone. If you want the money today you've got to show value first.

In most organizations, security sign-off has always been a last minute activity. Today although we have good number of application teams having fair amount of knowledge related to application security but sadly we still see obvious and easy to control security issues still exists in various application.

With the vast majority of software, especially Web applications, becoming blatant targets for hackers everywhere there's really should not be any excuse any more for deploying insecure software. Ideally no software should be deployed without first being assessed for known security issues. There might be cases where software comes under some new attack, but by and large there is no reason that known security issues should not be addressed before a piece of software is deployed.

Hence we can avoid the band-aid like penetrate-and-patch approach to security only by considering security as a crucial system property. Eventually it will results in a happier business customer, no cost overruns due to late security activities.