CISO PERSPECTIVES — Guest commentary

The recipe for 'baking in' security in software systems

For many years, security managers have espoused the mantra, “bake security in,” yet how to do so hasn't been particularly obvious. The reverse approach, “bolt security on (as an afterthought),” is easier to understand. Yet, it is often said to cost as much as 100 times more to add security after development than to plan for and include security from the start of the life cycle. This article, the first in a series on the Secure Software Life Cycle, explores what it means to bake security in from a macro perspective, covering the many essential security components. Follow-up articles will each explore an individual facet of the secure software life cycle in more depth.

Today, most organizations acknowledge that security is an important element in doing business. Awareness has been elevated with more public education on security issues such as identity theft. However, questions remain regarding how much security is enough, with much of the discussion driven by cost and business performance issues. These concerns often lead to shortcuts in the application of effective security within the life-cycle process rather than trying to force fit it later. Other reasons are lack of trained staff in security methods and procedures. No matter what software or system development life cycle (SDLC) process is embraced, there are key security components that should be addressed to enable effective security.

The traditional software development process can be implemented using a variety of well-documented models, including the Waterfall, Joint Application Development (JAD) and the Spiral or Iterative models. Let’s briefly review the characteristics of these common models.

The Waterfall model is the oldest and most familiar of the three. It is comprised of a series of sequential phases of life-cycle development, from project initiation and planning through system deployment. Based on individual implementation, organizations may segment the activity into as little as four phases and up to as many as seven.

Later SDLC models relaxed the perceived rigidity and forced sequencing of the Waterfall model, which also has heavy emphasis on documentation at each phase prior to proceeding to the next phase. Variations include more collaboration between end-users and developers through a series of Joint Application Development (JAD) sessions which were very popular in client-server environments in the early 1990s and use of a sequence of prototypes (or proofs-of-concept), prior to final product release, with various prototype iterations before final acceptance (Spiral or Iterative).

There was also a variation allowing for development and testing of software modules in parallel to shortened timelines for deliverables (Incremental) and combining aspects of all of the other methods with heavy emphasis on iterative prototyping, with each iteration introducing new functionality in each stage to minimize risk associated with large, complex applications.

No matter which model is employed, it is essential that the process allow for the integration of required security components. In today’s business environment characterized by wide Internet application deployment and aggressive competition for market share, flexibility in approaching SDLC activities is a necessity.

Regardless of the environmental challenge, common to all models are some basic activities which need to include security input. This article will focus on the ingredients required to bake security in to secure software life-cycle process rather than trying to append security components to the final product. Certainly in the current environment of virtualization and a move toward cloud computing, increased cyber attacks, and malware, this objective must be given high priority.

Baking security into software systems has a lot to do with who is involved in the SDLC process more than any other factor. Clear responsibility for overseeing this activity must be assigned to trained professionals knowledgeable in security methods and techniques. Common titles for such individuals include chief information officer (CIO), chief security officer (CSO), chief information security officer (CISO), and chief risk officer (CRO). A secure software life-cycle process should parallel an organization’s overarching business life-cycle process, overlapping the business process with specific security components and activities. The table below summarizes the major security elements that must be present in any SDLC process and how the two processes are paralleled.

1. Planning & Initiation



General Project Description

High level overview of desired functionality and business goals and objectives to be achieved

High level security goals and objectives

(Confidentiality, Integrity, Availability) based on business goals and objectives.

Selection of project team members with assigned roles and responsibilities

Assignment of security team members

Training of project team

Security team training

Develop candidate system description

Assign system categorization (high, medium, low) based on business impact

2. Analysis & Requirements Development



Collect end-user/stakeholder requirements

Conduct initial risk assessment and select and document baseline security controls

Define any other security requirements in support of defined business requirements

Derive/define application system functionality to be developed

Define security functionality to be developed

Maintain system documentation

Ensure that security components are included in project documentation

3. Design



Define detailed system requirements

Refine/update risk assessment

Update security controls as needed

Define system architecture (information model, database design, platform for development, etc.)

Define security architecture

Develop detailed system documentation

Ensure that security requirements are included in documentation

Update project documentation

Assist with security documentation

Update System Authorization preparation package

Assist with providing security artifacts

4. Implementation



Develop software code

Ensure that security code is included

Develop prototype (if applicable)

Conduct unit and integration testing

Conduct/assist with security control testing

Develop System Authorization Plan

Assist as appropriate

Assimilate Systems Authorization Package

Assist as appropriate

Install the operational system

Submit system to Systems Authorization Process

Perform security risk analysis

Be available as security resource to address any security questions

Achieve System Authorization

Perform role in authorization process as defined by the organization (expert resource )

Deploy the system for business operation

5. Maintenance



Establish Continuous Monitoring Capability

Establish Continuous Monitoring Capability for security components

Perform Configuration Management & Change Control functions (requirement revisions, platform changes, corrections reflecting policy changes, etc.)

Participate in Configuration Management & Change Control discussions with specific focus on security control requirements and any necessary updates/revisions

Update/Revise system functionality as required

Update/revise security controls as required

Perform system re-authorization as required

Perform role in authorization as defined by the organization (expert resource)

6. Disposal



Develop disposal strategy/plan

Assess disposal plan for need to:

· Sanitize media

· Preserve information

· Retain disposition records

Submit disposal requirements to responsible official

Sunset the system

Dispose of Hardware/Software

It has been six years since the National Strategy to Secure Cyberspace was published, citing a “critical area of national exposure” as “the many flaws that exist in critical infrastructure due to software vulnerabilities” and the need to reduce and remediate those vulnerabilities. The Homeland Security Department’s “Build Security In” initiative emphasizes the fact that software security is fundamentally a software engineering problem and needs to be addressed in a systematic manner. Key to this principle is building security in to software in every phase of development. This must be addressed throughout the SDLC. This initiative is based on the concept of community collaboration throughout the SDLC to achieve a high degree of software assurance.

Progress toward secure software has not been rapid, direct or orderly. Rush to market and short-term cost considerations continue to hinder secure software development. However, as mentioned, there is now a clearer understanding of both the software life cycle and where and how security needs to fit into the different phases. Recent discussions of the security life cycle have included the concept of control gates which are critical decision points in each phase of the SDLC, points at which decisions or evaluations regarding project status are made. This subject will be further explored in an upcoming article in this continuing series. Other articles in the series will cover security architecture and security standards, the supply chain influence on software development, barriers to secure software development and the people factor.

inside gcn

  • election security (

    Best practices for election systems security

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group