Ascension Blog

In part one of this multi-part post, we started out making the case for integrating security into the system development life cycle (SDLC).  In this post we’ll be looking at SDLC Methodologies, Key Roles and Responsibilities, and providing an overview of the SDLC phases. 

As I stated before the paper was written from the assumption that the reader would be unfamiliar with the technical aspects of information security (as is true of most management types – after all that is what they hired us for isn’t it).  My aim was to illustrate information security without being overly technical and thus risk losing my audience.  So without further adieu – A Beginners Guide to Integrating Security into the SDLC Part Duex. 

The SDLC

Many SDLC methodologies exist.  These methodologies, or models, should not be limited within a particular environment, but rather should be dictated by the system under development.  Certain models lend themselves to certain types of systems and can be, in fact, a significant factor in the return-on-investment calculations for certain systems.  While hybrids of various models exist, the following list covers the main model categories, which exist today.

• Linear sequential model
• Prototyping model
• Iterative development models
• Spiral model
• Component assembly model
• Concurrent development model

For illustrative purposes, I will utilize the linear sequential model because of its simplicity; however, the concepts that I’ll cover are applicable to any SDLC Model. 

Key Roles and Responsibilities within the SDLC

It is important to clearly define the roles and responsibilities of all the key players at the onset of any successful project.  While the titles of each role may vary or be combined as appropriate, the delineation of responsibility is important.  It is also vitally important to involve the Information Security department at the onset of the SDLC.  Security concerns and implications should be addressed as early in the process as possible, preferably in the initiation phase, in order to avoid costly and inefficient re-engineering during time critical phases of the SDLC.  

Security Properties

Integrating security into the SDLC begins with being able to articulate the security properties desired within the system.  This process is typically cyclical in refinement beginning at the top level and drilling down into what will eventually be security specifications.  There are many ways to express the high-level security requirements, among them the International Organization for Standardization (ISO) 15408: Common Criteria for Information Technology Common Criteria Security.  Other such high-level requirements exist and should be used as appropriate.

Because the security characteristics of a system evolve over time, the system requirements (including the security requirements) documentation needs to be under configuration management, as is any other system related documentation that evolves over time. 

Phases of the SDLC

Security in the SDLC

Each phase of the SDLC aims to achieve specific goals or milestones that must be reached during the systems development.  These are illustrated in Figure 1 and briefly defined below. 

Initiation Phase

• The need for a system is expressed, and the purpose of the system is documented and a cost/benefit analysis is conducted.

Acquisition/Development (A/D) Phase

• The system is designed, purchased, programmed, developed, or otherwise constructed.

Implementation Phase

• The system’s security features are configured and enabled,
• The system is tested and installed, or fielded,
• The system is authorized for processing

Operations/Maintenance (O/M) Phase

• The system performs its intended function.

Disposal Phase

• The system is decommissioned, and its information is either migrated to a new system or sent to archive.

Focusing primarily on the security considerations that need to be incorporated into the SDLC, the following sections will enumerate the appropriate issues. 

In Part Three we’ll look at each of the SDLC Phases and review the security considerations of each.

And in Part Four we’ll wrap it all up into a conclusion. 

I’d be interested in hearing any feedback you may have.  Translating security to management is always a moving target so the more viewpoints that can be incorporated into the approach the better. 

References:

National Institute of Standards and Technology, Special Publication 800-64 – Revision 1, Security Considerations in the Information System Development Life Cycle, June 2004

This entry was posted on Thursday, November 13th, 2008 at 08:46 and is filed under General, Questions.You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.