CHAPTER 14:
AUTHORIZATION AND THE SYSTEM LIFE CYCLE (SLC)
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.110
Douglas Adams, author of The Hitchhiker’s Guide to the Galaxy
In this chapter:
Phases of the system life cycle
The phases and associated documentation
When do you really have to start paying attention to security requirements for your information system? The answer is – from the very earliest stages of planning for the system to its final disposal. By considering security early in the information system life cycle (SLC)111, you might avoid higher costs later on and even have a more secure information system.
Federal agencies spend millions of dollars each year on the acquisition, design, development, implementation, and maintenance of information systems essential to their mission and day-to-day operations. The need for safe, secure, and reliable information systems is heightened by the increased need for these systems to provide services and develop products, administer daily activities, and perform short- and long-term management functions. There are also additional mandates to ensure privacy and security when developing and operating information systems, to establish uniform privacy practices, and to develop acceptable implementation strategies for these practices.
Sound system life cycle management practices include planning and evaluation in each phase of the information system life cycle. The level of planning and evaluation should be commensurate with system cost, the stability and maturity of the technology under consideration, how well defined the user requirements are, the level of the program’s stability, user requirements, and security considerations.
The SLC is applicable to all information technology (IT) environments (e.g. mainframe, client, and server) and applies to contractually and in-house developed applications. The participants in the life cycle process, the necessary reviews and approvals, and the security requirements will vary from project to project.
There are several views of the system life cycle and the relationship to the authorization process. The following figure depicts the NIST view of the system life cycle as described in National Institute of
111 Also called the system development life cycle (SDLC). Since the relationship between systems and authorization extends beyond development, we will use the term system life cycle (SLC).
Standards and Technology (NIST) Special Publication 800-64, Security Considerations in the Information System Development Life Cycle.
Figure 39: NIST’s view of the system life cycle
Source: Adapted from the National Institute for Standards and Technology
NIST SP 800-64 describes five stages and the security actions associated with each phase:
Initiation
Development/acquisition
Implementation/assessment
Operation/maintenance
Disposal.
NIST’s guidance is extremely useful; however, we will expand upon these five stages in the SLC to give you a better idea of how to integrate security and associated authorization requirements. By providing greater detail to NIST’s five-stage process we present a logical order of events for conducting system development and integrating authorization that is controlled, measured, documented, and ultimately improved.
Figure 40: The 10-phase SLC and the authorization process
Source: Adapted from the National Institute for Standards and Technology
Phases of the system life cycle (SLC)
The SLC we present involves ten phases, during which defined SLC-related work products are created and/or modified. The last phase occurs when the information system is removed from operation and the tasks performed by the system are either eliminated or transferred to other systems.
The tasks and work products for each phase are described in the following sections. Not every project requires you to execute it sequentially; however, the phases are interdependent. Depending upon the size and complexity of the information systems project, phases may be combined or overlapped.
Here is an introduction to the individual phases and the associated system security/authorization considerations.
Initiation phase
The initiation of an information system starts when an agency identifies a business need or opportunity. As soon as it is initiated, a project/program manager should be appointed to manage the system development. The agency’s business need is documented in a concept proposal. After the concept proposal is approved, the system concept development phase begins.
During this initial phase, security is not necessarily paramount. Nevertheless, it is not too early to start looking at some security considerations. These include:
Probable sensitivity of the information to be processed.
Threats to the information system and information based on probable deployment environments.
Possible interdependencies of the information system.
Legal or regulatory requirements/restrictions.
System concept development phase
Once a business need is approved, possible approaches for the system development are reviewed for feasibility and appropriateness as the system concept is refined. The system’s boundary document identifies the scope of the system and requires senior official approval and funding before beginning the planning phase.
As the system concept itself is refined, the security requirements should also acquire additional detail. Here you would start to think about the security features that need to be included in the design.
Planning phase
The concept evolves to planning as it is further developed to describe how the business will operate once the approved system is implemented, and to assess how the system will impact employee and customer privacy. Project resources, activities, schedules, tools, and reviews are defined to ensure the products and/or services provide the required capability on-time and within budget.
At this time, formal security certification and authorization activities can begin with the further identification of system security requirements and the completion of a high level risk assessment.
Requirements analysis phase
Functional user requirements are formally defined and requirements in terms of data, system performance, security, and maintainability are established. All requirements are refined to a level of detail sufficient for the system’s design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the initiation phase.
Design phase
The physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are identified, and resources are allocated. Everything requiring user input or approval must be documented and reviewed. The physical characteristics of the system are specified and a detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system.
The design phase should include the process for integrating the security requirements into the system development. The program manager should involve the information assurance manager in all of the design discussions. The IAM will ensure that the architecture and engineering documents and all design proposals include security considerations. Some of the security and authorization related considerations at this phase include:
Required technical and operational controls (the management controls can be considered, but these are often solidified later).
Security specifications (e.g. encryption, access authorization).
Process for conducting the security control assessments.
Personnel security requirements.
Risk analysis and risk management process.
Security documentation requirements.
Development/acquisition phase
The detailed specifications produced during the design phase are translated through development into hardware, communications, and executable software. Software shall be unit tested, integrated, and retested in a systematic manner. Hardware is assembled and tested.
Only reliable and/or authorized sources should be used for the acquisition of information systems and software. Additionally, at this time specialized security hardware, firmware, and software should be procured and integrated into the development. Be sure to acquire only DOD and/or NIST authorized security-related system components.
During this phase, the identified security safeguards (e.g. security controls) should be integrated into the system development process. NOTE: There may be several security controls that cannot be applied until after deployment.
Integration and test phase
The various components of the system are integrated and systematically tested. The user tests the system to ensure that the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and authorization activities.
During the development process, programs will generally conduct a series of tests to verify that the information system is operating as intended. Security related tests can also be built into this process, which will also assist in mitigating the costs of security testing.
Production and deployment phase
The system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.
At the end of the system’s development, a security controls assessment should be conducted and the formal authorization process should be nearing conclusion. Deployment of the system should not begin until it has received an authorization to operate.
Operations and maintenance phase
The system operation is ongoing. The system is monitored for continued performance in accordance with user requirements, and necessary system modifications are incorporated. The operational system is periodically assessed through in-process reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modifications or changes are identified as necessary, the system may re-enter the planning phase.
Security requirements do not end when the system is fielded and operational. In fact, this is where the requirement for continuous monitoring of the security status occurs. Certain security tools, such as vulnerability scanners, can be essential during this phase.
Disposal phase
The disposal activities ensure the orderly removal of the system from operation 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 and protection of the information processed by the system, so that the information can be effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.
As discussed in earlier chapters, the requirement to ensure security doesn’t stop during the process of removing an information system from operation. In fact, you will want to dispose of the information system properly in order to avoid the possibility that information systems will be released with sensitive government data.
Life cycle phases and documentation
Some documentation remains unchanged throughout the system’s life cycle while other documentation will continue to evolve throughout the life cycle. Recommended documents and their project phase are shown in System Life Cycle and Documentation Table on the CD-ROM. Documents directly related to the authorization process are highlighted.
Why link authorization to the SLC?
There are several requirements that link the system security authorization process to the system life cycle. These include:
FISMA: Requires a life cycle approach to continuous security management; evidenced in the mandate to conduct annual reviews.
OMB 130-A, Appendix III: Focuses security across the life cycle and gives NIST the authority to develop and publish guidance.
FIPS 200: Mandatory security standard that specifies minimum security requirements for information systems and requires a risk-based process for selection of security controls to meet the minimum system security requirements.
NIST 800-53 Security Control SA-3: A security control directly related to the requirement to link security and the system life cycle. It states: “The organization manages the information system using a system development life cycle methodology that includes security considerations.”
DODI 8510.01, DIACAP: States that the program manager/ system owner is required to “Plan and budget for IA controls implementation, validation, and sustainment throughout the system life cycle, including timely and effective configuration and vulnerability management.”
|
Further reading |
|
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook – A Guide for System Life Cycle Processes and Activities, Version 3 (INCOSE-TP-2003-002-03). Seattle, WA: INCOSE, June 2006. |
|
Lippner, S. et al. The Trustworthy Computing Security Development Lifecycle. Microsoft, March 2005, available at http://msdn.microsoft.com/en-us/library/ms995349.aspx#sdl2_topic1_2 . |
References
Department of Homeland Security: Cyber Security Division. Build Security In website, available at https://buildsecurityin.us-cert.gov/daisy/bsi/home.html .
ISO/IEC 15288: 2002(E), Systems Engineering – system life cycle processes. Geneva, Switzerland: International Organization for Standardization, 1 November 2002.
National Institute of Standards and Technology (NIST) Special Publication (SP) 800-64, Security Considerations in the Information System Development Life Cycle, October 2008.
US Department of Defense Instruction 5000.2, Operation of the Defense Acquisition System, 8 December 2008.