Home page logo

isn logo Information Security News mailing list archives

ITL Bulletin for April 2009
From: InfoSec News <alerts () infosecnews org>
Date: Fri, 1 May 2009 04:39:31 -0500 (CDT)

Fowarded from: Elizabeth Lennon <elizabeth.lennon (at) nist.gov>



Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
U.S. Department of Commerce

The most effective way to protect information and information systems is to integrate security into every step of the system development process, from the initiation of a project to develop a system to its disposition. The multistep process that starts with the initiation, analysis, design, and implementation, and continues through the maintenance and disposal of the system, is called the System Development Life Cycle (SDLC).

The Information Technology Laboratory of the National Institute of Standards and Technology (NIST) recently updated its general guide that helps organizations plan for and implement security throughout the SDLC. The revised guide provides basic information about the comprehensive approach that NIST has developed for managing risks to systems and for providing the appropriate levels of information security based on the levels of risk. Federal agencies are directed to incorporate security controls and services into the SDLC under the Federal Information Security Management Act (FISMA) and Office of Management and Budget (OMB) Circular A-130, Appendix III.

NIST Special Publication (SP) 800-64, Revision 2, Security Considerations in the System Development Life Cycle

Revision 2 of NIST SP 800-64, Security Considerations in the System Development Life Cycle, was developed by Richard Kissel, Kevin Stine, and Matthew Scholl of NIST, with the expert assistance of Hart Rossman, Jim Fahlsing, and Jessica Gulick, of Science Applications International Corporation (SAIC). In addition, many individuals in the public and private sectors contributed to the revision by reviewing it and providing constructive comments.

The guide focuses on the information security components of the SDLC. One section summarizes the relationships between the SDLC and other information technology (IT) disciplines. Topics discussed include the steps that are prescribed in the SDLC approach, and the key security roles and responsibilities of staff members who carry out information system development projects.

NIST SP 800-64 helps organizations integrate specific security steps into a linear and sequential SDLC process. The five-phase method of development that is described in the guide is also known as the waterfall method, and is one process for system development. Other methodologies can be used as well. Detailed charts and tables in the guide present specific activities for each step of the SDLC, and the security activities associated with each step.

Another section of NIST SP 800-64 provides insight into IT projects and initiatives that are not as clearly defined as SDLC-based developments. Projects such as service-oriented architectures, cross-organization projects, and IT facility developments often require a somewhat different approach to security integration than the traditional system development efforts.

The guide includes detailed supplemental information in seven appendices. Appendix A provides a glossary of terms used in the guide. Appendix B presents a comprehensive list of acronyms. Appendix C lists references cited in the publication. Appendix D matches the security-related steps in each phase of the SDLC to the relevant NIST publications that provide guidance for the security activities. Appendix E gives an overview of other SDLC methodologies. Appendix F discusses additional planning considerations for the development and acquisition phase of the SDLC. Appendix G provides a view of the security considerations in the SDLC in a graph format.

The System Development Life Cycle

The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases. For any SDLC model that is used, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system will transmit, process, and store.

Applying the risk management process to system development enables organizations to balance requirements for the protection of agency information and assets with the cost of security controls and mitigation strategies throughout the SDLC. Risk management processes identify critical assets and operations, as well as systemic vulnerabilities across the organization. Risks are often shared throughout the organization and are not specific to certain system architectures.

Some of the benefits of integrating security into the system development life cycle include:

* Early identification and mitigation of security vulnerabilities and problems with the configuration of systems, resulting in lower costs to implement security controls and mitigation of vulnerabilities;

* Awareness of potential engineering challenges caused by mandatory security controls;

* Identification of shared security services and reuse of security strategies and tools that will reduce development costs and improve the system ’s security posture through the application of proven methods and techniques;

* Facilitation of informed executive decision making through the application of a comprehensive risk management process in a timely manner;

* Documentation of important security decisions made during the development process to inform management about security considerations during all phases of development;

* Improved organization and customer confidence to facilitate adoption and use of systems, and improved confidence in the continued investment in government systems; and

* Improved systems interoperability and integration that would be difficult to achieve if security is considered separately at various system levels.

Initiation Phase. During the initiation phase, the organization establishes the need for a system and documents its purpose. Security planning should begin in the initiation phase with the identification of key security roles to be carried out in the development of the system. The information to be processed, transmitted, or stored is evaluated for security requirements, and all stakeholders should have a common understanding of the security considerations. The Information System Security Officer (ISSO) should be identified as well.

Security considerations are key to the early integration of security, and to the assurance that threats, requirements, and potential constraints in functionality and integration are considered. Requirements for the confidentiality, integrity, and availability of information should be assessed at this stage. Federal agencies should apply the provisions of Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. These standards require agencies to categorize their information systems as low-impact, moderate-impact, or high-impact for the security objectives of confidentiality, integrity, and availability and to select appropriate security controls. Any information privacy requirements should be determined as well.

Early planning and awareness will result in savings in costs and staff time through proper risk management planning. In this phase, the organization clearly defines its project goals and high-level information security requirements, as well as the enterprise security system architecture.

Devlopment/Acquisition Phase. During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. A key security activity in this phase is conducting a risk assessment and using the results to supplement the baseline security controls. In addition, the organization should analyze security requirements; perform functional and security testing; prepare initial documents for system certification and accreditation; and design the security architecture.

The risk assessment enables the organization to determine the risk to operations, assets, and individuals resulting from the operation of information systems, and the processing, storage, or transmission of information. After categorizing their systems in accordance with FIPS 199 and 200, federal agencies should meet the minimum security requirements by selecting the appropriate security controls and assurance requirements that are described in NIST SP 800-53, Recommended Security Controls for Federal Information Systems.

Another essential element is the development of security plans, which establish the security requirements for the information system, describe security controls that have been selected, and present the rationale for security categorization, how controls are implemented, and how use of systems can be restricted in high-risk situations. Security plans document the decisions made in the selection of controls, and are approved by authorized officials.

The developmental testing of the technical and security features and functions of the system ensure that they perform as intended, prior to launching the implementation and integration phase.

Implementation Phase. In the implementation phase, the organization configures and enables system security features, tests the functionality of these features, installs or implements the system, and obtains a formal authorization to operate the system. Design reviews and system tests should be performed before placing the system into operation to ensure that it meets all required security specifications. In addition, if new controls are added to the application or the support system, additional acceptance tests of those new controls must be performed. This approach ensures that new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests should be fully documented, updated as new reviews or tests are performed, and maintained in the organization’s official records.

Operations/Maintenance Phase. In this phase, systems and products are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and software components are added or replaced. The organization should continuously monitor performance of the system to ensure that it is consistent with pre-established user and security requirements, and that needed system modifications are incorporated.

Configuration management (CM) and control activities should be conducted to document any proposed or actual changes in the security plan of the system. Information systems are in a constant state of evolution with upgrades to hardware, software, firmware, and possible modifications in the surrounding environment. Documenting information system changes and assessing the potential impact of these changes on the security of a system are essential activities to assure continuous monitoring, and prevent lapses in the system security accreditation.

Disposal Phase. In this phase, plans are developed for discarding system information, hardware, and software and making the transition to a new system. The information, hardware, and software may be moved to another system, archived, discarded, or destroyed. If performed improperly, the disposal phase can result in the unauthorized disclosure of sensitive data. When archiving information, organizations should consider the need for and the methods for future retrieval.

Usually, there is no definitive end to a system. Systems normally evolve or transition to the next generation because of changing requirements or improvements in technology. System security plans should continually evolve with the system. Much of the environmental, management, and operational information for the original system should still be relevant and useful when the organization develops the security plan for the follow-on system.

The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. The removal of information from a storage medium, such as a hard disk or tape, should be done in accordance with the organization’s security requirements.

Additional Security Considerations

Some IT development projects are service-based and may involve other organizations, such as public-private sector supply chain endeavors. Other projects are facility-oriented, such as the establishment of a data center or a hot site. Organizations developing projects such as these should follow the principles for integrating security into the SDLC, as they examine and address the additional security considerations involved in these projects.  See NIST SP 800-64 for more details.

More Information

NIST SP 800-64 is a reference document that should be used in conjunction with other NIST publications throughout the development of the system.

Publications developed by NIST help information management and information security personnel in planning and implementing a comprehensive approach to information security. The general security of information systems depends upon attention to basic issues such as security planning, certification and accreditation, risk management, categorization of systems, and use of security controls. Organizations can draw upon NIST standards and guidelines to carry out their SDLC activities, including the following:

Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules.

FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.

FIPS 200, Minimum Security Requirements for Federal Information and Information Systems.

NIST SP 800-18 Revision 1, Guide for Developing Security Plans for Information Technology Systems.

NIST SP 800-30, Risk Management Guide for Information Technology Systems. NIST SP 800-64 complements the Risk Management Framework discussed in NIST SP 800-30 by providing a sample roadmap for integrating security functionality and assurance into the SDLC. NIST SP 800-64 also provides further detail on additional activities that are valuable for consideration in different system and agency settings.

NIST SP 800-33, Underlying Technical Models for Information Technology Security.

NIST SP 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems. This publication is being revised.

NIST SP 800-39, Draft Managing Risk from Information Systems: An Organizational Perspective. This publication is being revised.

NIST SP 800-53, Recommended Security Controls for Federal Information Systems. This publication is being revised. Security architectures should implement the security control families that are outlined in NIST SP 800-53 and that protect the confidentiality, integrity, and availability of federal information and information systems.

NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems.

NIST SP 800-60 Revision 1, Guide for Mapping Types of Information and Information Systems to Security Categories.

NIST SP 800-65, Integrating Security into the Capital Planning and Investment Control Process. The CPIC process is defined by OMB Circular A-130 as “a management process for ongoing identification, selection, control, and evaluation of investments in information resources. The process links budget formulation and execution, and is focused on agency missions and achieving specific program outcomes.” This publication described a seven-step methodology to help organizations integrate security into the CPIC process and to assure that capital planning and information security goals and objectives are met.

NIST SP 800-88, Guidelines for Media Sanitization.

NIST SP 800-95, Guide to Secure Web Services.

NIST Interagency Report (NISTIR) 7298, Glossary of Key Information Security Terms.

For information about NIST standards and guidelines that are listed above, as well as other security-related publications, see NIST’s Web page: http://csrc.nist.gov/publications/index.html


Any mention of commercial products or reference to commercial organizations is for information only; it does not imply recommendation or endorsement by NIST nor does it imply that the products mentioned are necessarily the best available for the purpose.

LayerOne 2009, Information Security for the discerning professional. 
May 23-24 2009 @ The Anaheim Marriott in Anaheim, California 
Visit http://layerone.info for more information

  By Date           By Thread  

Current thread:
  • ITL Bulletin for April 2009 InfoSec News (May 01)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]