The System Development Life Cycle

Table of contents:

A framework for system development can make the development process much easier and more structured. Many different models exist; although some have more steps than the others, overall the goal is the same: to control the process and add security at each level of the process. Two examples of this include NIST 800-64, "Security Considerations in the Information System Development Life Cycle," and NIST 800-14, "Generally Accepted Principles and Practices for Securing Information Technology Systems." NIST 800-14 separates the development into five distinct steps:


Project initiation









Project Initiation

This step of the process usually includes a meeting with everyone who is involved with the project. This is a good opportunity to make sure everyone gets a chance to meet and that everyone understands the goals of the project. A plan must be developed to map the process and develop deadlines and submission dates.

A sensitivity assessment should also be conducted. This should help identify the type of information that will be processed and its level of sensitivity. Discussions should be held to determine the level of risk involved in handling this data and to establish the results from its accidental exposure. These items must be completed before the system design specifications are locked in.

Development and Acquisition

In this step, the system is designed, developed, programmed, and acquired. Programmers work to develop the application code. Security should be the focus here, as the programmers work to ensure that input and output controls, audit mechanisms, and file-protection schemes are used. Examples of input controls include dollar counts, transaction counts, error detection, and correction. Example output controls include validity checking and authorizing controls. It's important that programmers don't assume that systems are always installed and operated in trusted environments.

Acceptance Testing/Implementation

This step occurs when the application coding is complete. The acceptance testing and implementation should not be performed by the programmers. Testing should be performed by a different group of individuals. These tasks are usually assigned to auditors or quality assurance engineers. The important concept here is separation of duties. If the code is built and verified by the same individuals, errors can be missed and security functions can be bypassed.

When the issues and concerns have been worked out between the QA engineers and the programmers, the application is ready for deployment.


At this step, the application is prepared for release into its intended environment. Certification and accreditation are the final steps involved in accepting the application and agreeing that it is ready for use.

Certification is a technical evaluation and analysis of the security features and safeguards of a system, to establish the extent to which the security requirements are satisfied and vendor claims are verified.

Accreditation is the formal process of management's official approval of the certification, that the application or system operates as specified in the environment it was designed to be used in.



This step of the process is reached when the application or system is no longer needed. Those involved in this step of the process must consider the disposal of the application, archiving of any information or data that might be needed in the future, disk sanitization (to ensure confidentiality), and the disposal of equipment. This is an important step that is sometimes overlooked.

Disposal Is a Big Problem

Computer forensics investigators at the University of Glamorgan in England examined more than 100 drives purchased at random on eBay. Only two of the drives contained no data. All of the remaining drives contained various amounts of residual information. One contained psychological reports on school children, and several others contained confidential information.

If hard drives are not destroyed, they should be wiped and sanitized. One standard is Department of Defense standard 5220.22-M. It recommends overwriting all addressable locations with a character, its complement, and then a random character to verify that the residual data has been cleared and sanitized.

The CISSP Cram Sheet

A Note from Series Editor Ed Tittel

About the Author


We Want to Hear from You!



The CISSP Certification Exam

Physical Security

Security-Management Practices

Access-Control Systems and Methodology

System Architecture and Models

Telecommunications and Network Security

Applications and Systems-Development Security

Operations Security

Business Continuity Planning

Law, Investigations, and Ethics


Practice Exam 1

Answers to Practice Exam 1

Practice Exam 2

Answers to Practice Exam 2

CISSP Exam Cram 2
CISSP Exam Cram 2
ISBN: 078973446X
EAN: 2147483647
Year: 2003
Pages: 204
Authors: Michael Gregg © 2008-2020.
If you may any questions please contact us: