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

2. Analysis & Requirements Development

3. Design

4. Implementation

5. Maintenance

6. Disposal

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.