21 Mar, 2014

A More Secure Development Lifecycle I: Introduction

by Marjorie Meadors

The OWASP Top Ten has rated SQL Injection as one of the top vulnerabilities for many years. Developers are aware of SQL Injection, but it and many other, well-known vulnerabilities still exist on web sites. The focus on hardening networks has reduced network vulnerabilities, but vulnerabilities still occur in many web applications. In fact, the Microsoft Security Intelligence Report (Version 12) states that over 70 percent of vulnerabilities are found in the application layer. This high rate of vulnerabilities means security requirements aren’t met during initial software development, and that means organizations fix issues after their web sites have gone live. This can be quite expensive.

Creating applications using an SDLC has become the standard for software development. Many studies on the benefits of SDLCs have shown that the relative cost of fixing code issues increases the later in the process the issues are found. The Systems Sciences Institute at IBM released the following chart to illustrate these findings.

Some code fixes require a change in the original design of the application, which can result in significant cost.  Making sure all requirements are identified in the requirements stage so they can be incorporated in the design stage is important to avoid significant cost overruns.

Some SDLC processes lack security requirements. To help organizations improve the security posture of their applications, Microsoft has defined their Security Development LifeCycle, which provides instruction on how to design security into an application. Unfortunately, some software development organizations think securing an application is a separate process that just creates documentation for the Information Assurance department or, worse yet, just involves scanning the code before it goes into production. But a better development lifecycle would incorporate security throughout the full development process; security would be integrated into whatever type of SDLC is used.

Since every organization has an SDLC process (waterfall, agile, custom) that suits their needs, I am only going to focus on the requirement, design, and coding stages which usually exist in every SDLC. Often, people believe adding security requirements to the application development will just increase the amount of work but some of the security processes can replace or supplement current SDLC steps.

In future blogs, I will talk about how you can include security requirements in your SDLC process to work towards improving the security of your applications. The next blog will discuss types of security requirements and examples of each type of requirement. A subsequent blog will present processes that help to elicit these security requirements.