Secure software development lifecycle: An approach for SMBs

Small businesses that lack the resources to implement the full MSDL can use its basic tenants to provide more secure software development.

The iPhone App Store has generated a resurgence in the bedroom programmer, last seen en masse in the early 1980s. Many solo programmers and small development teams have successfully created highly popular apps. The investment appetite for small start-ups developing new and original software has also recovered in the last couple of years, which means there are a lot of programmes being developed on a tight budget and on short timescales. These two factors tend to create an environment where writing eye-catching features takes precedence over writing secure code, and the secure software development lifecycle  tends to be an afterthought -- if it is considered at all.

But any application that is to be used in a business environment, that processes personal or sensitive information, or that communicates over the Internet needs to be subjected to some form of vulnerability assessment and testing. So when it comes to security, how does the smaller business implement an assurance process as grand and demanding as the Microsoft Security Development Lifecycle (SDL)?

The Microsoft SDL aims to reduce the number and severity of vulnerabilities in software, making security and privacy a priority throughout all phases of the development process. But implementing all the security activities that comprise the Microsoft Security Development Lifecycle requires people, time and money that are beyond the wherewithal of most smaller firms. A compromise is to base the software development process on the Microsoft SDL, adopting those activities deemed essential and following the three core concepts -- education, continuous process improvement and accountability -- at a level that matches the organization’s resources.

Considering, security at the start of a project is a fundamental aspect of secure software development. Defining minimum security requirements for a project during the planning stages allows developers to integrate security controls far more effectively than trying to bolt them on later. A risk assessment identifies those components of the application that should be subjected to closer inspection, code reviews, fuzzing or penetration testing. Threat modelling also helps you identify and mitigate potential security issues while they are relatively easy and cost-effective to resolve. Microsoft’s free SDL Threat Modelling Tool is a resource that provides guidance on creating and analysing threat models.

An application's creation stages are also the time to establish quality gates -- minimum acceptable levels of security. So, for example, before a development phase is considered complete, there must be no compiler warnings when the programme is built. Certainly before the release version is signed off, all security issues must be addressed and tests successfully completed. As applications are now so complex, security checks benefit from automated scanning. There are plenty of good open source vulnerability scanners such as OpenVAS and skipfish, so this doesn’t need to be a costly addition to secure software development.

Somebody should be appointed to oversee each phase of the software development process and be responsible for signing off the successful completion of each security requirement. Whenever possible, this person should be independent from the development team and should be free from undue pressure to approve any sub-standard work, merely to allow the next phase to start. Positive confirmation that a security control is working as expected is essential, as it’s quite easy to implement security features, which are, in fact, insecure. For example, security vendor Secunia recently found many popular software applications had not properly implemented various mitigation technologies (.pdf) introduced by Microsoft in Windows Vista.

Before any project is started, the development team must understand the concepts of secure design. The team should be familiar with topics such as threat modelling, secure coding, security testing and relevant privacy regulations such as the Data Protection Act. Because security risks are continually changing and evolving, the ongoing education and training of developers is essential. They should be up to date on the latest threats and mitigation technologies that are available; both Microsoft and Secunia have reported a low implementation rate of ASLR (Address Space Layout Randomisation), a mitigation technology against buffer overflow exploits.

If developers don’t know what they’re protecting, what they’re protecting it from and how to protect it, then applications will never be secure. Another good reason to identify and catalogue security and privacy issues present in an application during the design phase is that you can ensure individuals within the team have, or acquire, the necessary skills to mitigate them.

Despite  best efforts, vulnerabilities in an application may well come to light once it is released. The Microsoft SDL takes this into account and requires an incident response plan to be in place. The plan needs to identify the appropriate developers and management employees that should be involved in remediating the flaws, as well as a person to act as a point of first contact in an emergency. To improve the effectiveness and speed of your response, you need to keep at hand any pertinent information and data that can help post-release bug fixing. This includes source code, binaries, threat models and documentation, as well as any licence and support agreements for third-party components used in the application.

As with any methodology, incorporating the Microsoft SDL requires discipline. Microsoft’s Simplified Implementation of the Microsoft SDL covers the core concepts of the SDL and discusses the individual security activities that businesses need to adopt in order to follow the SDL process. An accompanying Excel spreadsheet lists 16 mandatory SDL security practices, along with implementation details and resources for each practice that Microsoft sees as the minimum threshold for compliance. It also discusses the SDL Optimization Model and offers guidance on how to move from lower to higher levels of development process maturity. Even if you only manage to implement some of the security practices into your software development process, the overall security of the application will benefit.

About the author:
Michael Cobb, CISSP-ISSAP, CLAS is a renowned security author with more than 15 years of experience in the IT industry. He is the founder and managing director of Cobweb Applications, a consultancy that provides data security services delivering ISO 27001 solutions. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.Cobb serves as’s contributing expert for application and platform security topics, and has been a featured guest instructor for several of’s Security School lessons.

Read more on Application security and coding requirements