System Development Life Cycle (SDLC)

Abstract

This chapter introduces the system development life cycle (SDLC) and its phases.

Table of Contents

System Development Life Cycle (SDLC)

The goal of this chapter is not to make you the best project manager on the planet, or even to make you an expert on the systems development life cycle. The goal is to expose you to the SDLC, its main phases, how they relate to each other, and the benefits derived from following this cycle. This chapter discusses in depth one of the major challengers to traditional SDLC, the agile development system of development.

It is important to understand these processes, as they are the frameworks used by system developers to create systems and programs. In reality, security professionals implementing the RMF do so in the context of systems growing and being developed; more than one proponent has factually stated that security cannot effectively and economically be “bolted on” to a system after it has been implemented, or even after the system has completed its design process. It is far better to have security (and compliance) “baked in” to a system or program. By “baked in” I mean that, as the system is being developed, security requirements are evaluated and security measures and controls are planned into the system and implemented along the SDLC.

The importance of baking security into a system’s development in order to protect both the system and its information is stated in the introduction of SP 800-64, Security Considerations in the System Development Life Cycle: “Information has become a mission-essential function.” The value of engaging security professionals early in the SDLC cannot be overstated; security professionals are critical to maintaining tight control over the program’s budget, ensuring that the required security controls are implemented, and protections and mitigating deficiencies are put in place to satisfy the authorizing official (AO) and to provide adequate security to the system and its data.

When we discuss the RMF and its phases in part II, we revisit these development tools and see how the older certification and accreditation process and the current RMF interlock with and relate to these processes. For this book’s purpose, we view the SDLC through the lens of NIST SP 800-64, Security Considerations in the Systems Development Life Cycle. We view the agile process through the agile Scrum process, as demonstrated by Arlen Bankston of LitheSpeed, LLC.

Traditional Systems Development Life Cycle (SDLC)

For many people the traditional approach to SDLC, often called waterfall, is the only development process they know, and for good reason. It is the most prominent development process in use today; in fact, the majority of government contracts issued for systems require this process to be followed through the system’s development. An indicator of the widespread acceptance and use of this process is illustrated by the observation that the project management professional (PMP) certification from the Project Management Institute (PMI) is focused on the SDLC waterfall process.

The five-phase cycle, detailed in NIST SP 800-64 and used by a great number of project managers, consists of initiation, development/acquisition, implementation/assessment, operations/maintenance, and disposal. Like other waterfall models, each phase is completed before the next one starts and each is more or less sequential, as illustrated in Figure 5-1. Other models have a varied number of phases and often call them by different names, but the sequential process remains the same.

Phase 1: Initiation

The initiation phase of the SDLC is critical to ensuring that a system is correctly planned for and developed. This phase is initiated by the decision to design and implement the system. The proposed system is evaluated to ensure that it aligns with the organization’s financial plan and that the proposed budget fits within organizational expenditures. The system’s concept is also evaluated to ensure that it is viable, completely achievable, and in line with the organization’s mission. Great effort should be made to ensure that security is integrated into this first phase of the SDLC, which ensures that the business requirements, in terms of the system’s confidentiality, integrity, and availability, privacy requirements, and information categorization and identification, are diligently assessed and planned for. Many times system developers, managers, and even security professionals fail to categorize the information types that will be processed on the proposed system; this is a hazardous position to take, as identification of information types sets the foundation for developing a successful security plan for the system. Failing to adequately plan for the information types that will be processed on the system is an error that will usually introduce system delays and unnecessary costs later.

The categorization of the information types should be paired with a privacy impact assessment (PIA) that is used to determine whether or not the system is a system of record that must be tracked carefully by the organization. Systems of record are those systems that store, process, display, or transmit personally identifiable information (PII), a categorization typically requiring additional security controls be implemented. It is important for the system’s stakeholders, those who will use the system or be impacted by it, to be aware of how the system is planned and, if possible, be available to support the system’s development. The system is also scoped to ensure that it is feasible, and the system’s high-level user requirements should be identified at this point.

Deliverables from this phase include the results of the system’s cost benefit analysis, a listing of information types that will be processed, and a listing of required and requested system features. Various system and group charters are normally developed in this phase, which outline how groups, meetings, and responsibilities will be handled as the system develops. The key deliverable to achieve before leaving this phase of the traditional SDLC is having the project approved by the organization.

Phase 2: Development/Acquisition

The primary goal of phase two is to evaluate the requirements established in phase one and either develop or purchase (acquire) a system that is able to meet or exceed these requirements (both functional and security requirements). Key activities in this phase include developing and reviewing the system’s architectural design to ensure that its planned integration with the organization and other systems is complete and that major factors and assumptions in the design are accurate. The performance of the system is evaluated, if possible, and if not possible, an assessment of the system’s proposed capabilities is performed to ensure that they are in line with the requirements identified earlier. Individual functions are reviewed to ensure that they are, or will be, functioning as intended and are testable for functionality and security.

This phase is also a good time to conduct a review of the system’s status and financial state, as detailed later, and it is important to select and document the security controls required for the system before leaving this phase. A process called tailoring, covered later in the book, is instrumental in ensuring that the correct controls are selected for the system. During this phase, test cases are developed for testing both functional and security requirements of the system.

Major outputs from this phase include a draft systems security plan (SSP) and documents detailing the review of the architecture/design, performance, functions, and financial status of the program or system. An updated risk assessment for the organization and system should be developed as well, to ensure that the system does not introduce unacceptable risks to the organization.

Phase 3: Implementation/Assessment

It would be better to reverse this title and view this phase as it occurs, as “Assessment/Implementation” rather than “Implementation/Assessment,” as the system must be assessed and authorized before it can be placed into production, or implemented, as is discussed later in the book. In a perfect world, systems in this phase of the SDLC are fully functional and housed in a test environment that is isolated from the organization’s production or development infrastructures. In this environment, test engineers and analysts evaluate the functional components of the system to ensure that the system is operating as designed and providing the required functions as defined in phase one. Adjustments to the system are possible early in this phase to ensure that these functional requirements are met.

Once the system is determined to be fully functional and operating as designed, security control assessors begin to evaluate the system to ensure that all of the required security controls are in place and functioning correctly. Each of these groups of testers prepares documentation that details the test results discovered during the test event, which will be used by other individuals and groups to determine the effectiveness of the system and risks to the overall organization. The document produced by the security control assessors is the security assessment report (SAR), a document that will be used by the assessors and the risk executive (function) to provide input to the authorizing official. The authorizing official will use the certifier’s comments as well as the SAR, risk assessment, and other documentation to make an approval determination on the status of the system. If the AO authorizes the system, he or she accepts responsibility for the secure status of the system and the system can then be moved into the next phase of the SDLC. Major artifacts from this phase include functional test results, the security assessment report (SAR), updated system and security documentation including the SSP and the Plan of Action and Milestones (POA&M), a document addressing security deficiencies, and an authorization decision by the AO. It is possible that the AO will decide not to approve the system or may approve the system to operate only under certain restrictions; this topic is discussed later in the book.

Phase 4: Operations and Maintenance

Assuming the system or program has received an approval to operate (ATO), it can be placed into the production environment and begin processing the information it was designed for. It is important to note that, up to this point, the system should not have housed any real information; it should have only been processing dummy or fictional information that was prepared for system functional and security testing and development. This point is covered in greater detail in other chapters. Phase 4 will normally be the longest phase in most systems life cycles and is the phase when the system provides the most benefit to the organization. As the system is used and maintained, it is normal for system settings to be adjusted and configurations to be modified so the system runs as efficiently as possible. During this phase, it is important to conduct reviews of the system’s readiness and implement the program to manage the configuration of the system. For example, a configuration control board (CCB) manages and continually reassesses the security controls levied against the system; if the system undergoes a significant security-relevant change, as determined by the authorizing official, it may be required to undergo the assessment and approval process again. The AO, or the designated representative, is the individual responsible for determining the magnitude of a change that is security-relevant enough to require that the system be reassessed and reauthorized. During this phase, items that were identified on the system’s POA&M are improved to the point that the security control identified is correctly implemented or the system’s remaining shortcomings are accepted by the AO.

Outputs from this phase include updated security documentation such as the SSP and POA&M, change control documents, and continuous monitoring documentation authorization updates provided by the AO.

Phase 5: Disposal

Most, if not all, systems have a limited life expectancy; requirements and technology changes often make systems obsolete or irrelevant. In some cases, the termination of one system is camouflaged by the creation of another system, in essence making one system seem to morph into another. Other cases end with the system being dismantled and disposed of. It is important to plan and develop a process to be followed when a system is no longer viable and must be decommissioned. The main activities in this phase center on securing and managing the data that was processed by the system.

A disposal or transition plan must be developed long before the system is decommissioned to ensure that the information from the system is either transferred to the new system or archived as required by organizational policy, regulation, or law. Media used in the system must be sanitized or destroyed and the system’s hardware and software disposed of according to organizational policy. The configuration control process, plans, and documentation implemented earlier should be closed out and archived, and security closure policies defined by the organization followed. Security professionals and system administrators should conduct a security review of the closure and fully document the system’s disposal. One point often overlooked is that, when system hardware and software are no longer viable for the organization, they may still provide a valuable training platform for educational use, either inside or outside the organization. If correctly sanitized, organizational hardware from decommissioned systems can find a second life in educational institutions. In fact, Title 40 USC states, “Whenever possible, excess equipment and media should be made available to qualifying schools and nonprofit organizations to the extent permitted by the law.” While I wholeheartedly agree with this policy, I strongly caution organizations to ensure that all organizational information is purged from the systems or storage media is removed before this transfer occurs.

Major outputs from this phase are system decommissioning documentation, configuration control logs, and media sanitization and/or destruction logs. As a final step, the system owner should ensure that the system is removed from the organization’s system portfolio.

Traditional SDLC Considerations

The traditional, or waterfall, SDLC process was designed to occur in a linear fashion, with systems completing one phase before entering the next. This would work out well if we lived in a perfect world; however, we know this is not the case. Systems often repeat phases of the traditional SDLC or go back to earlier phases in the cycle, repeating phases and cycling through the process a number of times; this is normal and occurs often. It is important to note changes that occur as a system revisits earlier phases to ensure that the security work and controls completed earlier are not negated when the system revisits phases of the SDLC. Many times, changes and new requirements introduce new information types or technologies that force the system to return to earlier phases in the SDLC.

Agile System Development

While the majority of systems and programs being developed today follow the waterfall SDLC model, it is important to mention another type of SDLC, the agile process. Agile system development does not follow a linear progression like the traditional SDLC, but rather it is cyclic, working in iterations, spins, or sprints. Regardless of the name, one of these cycles consists of a fixed period of time, say two weeks, during which a finite number of functions are added to the system. In some cases, following an agile process can speed up system development; however, it may come at the expense of system security if not implemented correctly. The system’s security staff must work with the system administrator and agile team to ensure that security controls (seen as other system functions) are implemented in the correct sequence and, when required, to ensure that the system is developed in a secure manner. Likewise, system documentation should be developed as the system matures. A full description of agile system development is outside the scope of this book; however, it is important to ensure that security requirements are ingrained into the system development regardless of the process used to develop the system. Agile development requires the security professionals, like the security engineer and the architect, to be more integrated into the system development team.