Wresting free from a software straitjacket

Typical developers have almost no training on secure development. Even if they did, software engineers are usually compensated for adding software functionality and meeting deadlines, not eliminating software vulnerabilities.

As a result of all of this buggy code, IT is often forced into building a post-development security strategy. Security safeguards like firewalls, application gateways, packet filtering, behavior blocking and patching are put in place to overcome software attacks against software vulnerabilities, open interfaces, and insecure features. In a medical setting, this approach might be described as "treating the symptoms rather than the disease."

This backward methodology to security is inefficient and exceedingly expensive. To keep valuable assets protected, IT staffers must constantly track software vulnerability databases in order to stay one step ahead of the bad guys. Each vendor patch release leads to an IT fire drill of testing and remediating all vulnerable systems. It is estimated that fixing software security problems in production environments can be more than 100 times more costly than doing so in the development cycle.

Enough is enough! The issues around insecure software development are finally getting some attention at academic and government institutions. For example, Carnegie Mellon University's Software Engineering Institute (SEI) has developed a software development process model that emphasizes quality and security. The SEI standards are also baked into the Department of Homeland Security's Build Security-In initiative.

Efforts like these are a great start, but what's going on with enterprise customers who build and consume billions of dollars in software each year? Sadly, most enterprise ISVs pay only lip service to developing secure software. The result? Layers upon layers of insecure software is already installed or added each day. Something has got to give!

"This backward methodology to security is inefficient and exceedingly expensive."

Interestingly, the biggest exception to this enterprise laissez-faire attitude toward secure software development is Microsoft?-a company frequently accused of being way more security problem than solution. Long before Bill Gates' famous Trustworthy Computing e-mail manifesto in 2002, Microsoft was adding security into its software design and testing processes.

The 1998 "Internal Security Task Force" effort became the Secure Windows Initiative in 2000, the "security push" through 2004, then, finally, the full-fledged Security Development Lifecycle (SDL). SDL is a comprehensive soup-to-nuts series of 12 stages, beginning with developer training and proceeding through ongoing secure response execution. Mandated by Microsoft executive management in 2004, all Microsoft software used in business activities, exposed to the Internet, or containing any private data was subject to SDL.

Microsoft admits that SDL ain't free. For users with significant legacy code, SDL can add 15 to 20 percent to development costs and projects. Nevertheless, Redmond claims that SDL more than pays for itself--Microsoft points to a 50 percent decrease in vulnerabilities for products that have gone through the SDL process and SQL server has not had a single database vulnerability in over three years.

What can enterprises learn from Gates & Company? Microsoft's SDL results should demonstrate just how important and effective secure software development can be. Certainly Redmond saved money by embracing SDL, but more importantly, Microsoft provided its customers with better software and lower security operating costs.

This should be a model for enterprises. Henceforth, enterprise organizations should demand that their internal developers, ISVs, and outsourcers implement demonstrable secure software development best practices. Users should ask for and be provided with documentation that outlines all secure software development processes and should receive metrics from ISVs that report on secure develop process results.

In other words, users should demand that their independent software vendors (ISVs) provide the same type of transparency with software development as they do with their financial results.

What's next? Secure software development will likely come to fruition through regulations and international standards like ISO over the long term--the Payment Card Industry (PCI) is already preparing banks and retailers for this in the PCI Security Standard Specification 2.0 some time in 2007.

In the meantime, smart enterprises should take the initiatives and start pushing ISVs ASAP. Give them a deadline: implement secure software development processes by 2008 or lose our business. This may appear a tad draconian, but I suggest that enterprises start soon, as it may take some time to awaken and motivate some of the more reactive ISVs and outsourcers doing almost nothing about secure software development today.