AMS Lifecycle Phase: Mission Analysis >>> Concept & Requirement Definition (CRD)

Description

The system's Concept of Operations (CONOPs) can be used for presenting the results of the needs determination and requirements analysis. As the system's CONOPs become more recognized, improved communication among stakeholders can occur because a more standardized approach is in use. Particularly, communication of security specifications to potential offerors can be greatly enhanced.

Further, a system CONOPs acts as a record of the security analysis performed during the mission analysis phase. It provides a place to record the threats that are being considered, the security objectives that are being pursued, and the actual security specifications as they are created. The CONOPs should be viewed as an "evolving" document that records the security analysis performed during the course of the requirements generation process.

The CONOPS should contain the following:

• A clear statement of the goals and objectives
• The strategies, tactics, policies, and constraints that describe how security will effect the program
• The organizations, activities, and interactions that describe who will participate and what these stakeholders do in that process
• A clear statement of the responsibilities and authority of the roles played in the process
• The specific operational processes, in overview fashion, that provide a process model in terms of when and in what order these operation processes take place, including such things as dependencies and concurrencies
• Processes for initiating the program, developing the products and components, maintenance of the products, and components, and possibly for retirement of the program and its products and components

The CONOPS should relate a narrative of the process to be followed. It must define the roles of the various stakeholders involved in the process. The CONOPS is not intended to be an implementation or transition plan since it does not provide managers with the detailed steps involved in planning for the transition: establishing accountability, managing risk, scheduling, and budgeting. However, it does offer a clear methodology to realize the goals and objectives of the approach to software development/acquisition of core assets and systems.

The security requirements for enterprise systems should address the following issues:

• the system should not create vulnerabilities or unintended interdependencies in other enterprise systems
• the system should not decrease the availability of other enterprise systems
• the system should not decrease the overall security posture of the entire enterprise
• systems connected to external domains must analyze and attempt to counter hostile actions originating from these domains
• security specifications should be appropriate for the given state of the system
• security specifications should be stated clearly to convey the desired functions and assurances to the enterprise system product team and the developers
• implement specifications that sufficiently reduce the risks to the enterprise system and to the enterprise mission that the system supports

There are six steps in the development of security requirements. The process is outlined below:

Note: The security implications of alternatives are considered in this stage. It is based on the requirements need of the NAS system assessed while it was derived from the security section of the NAS SR-1000.

Tasks

• Meet with stakeholders to ascertain the technical and programmatic security requirements
• Develop, evaluate and select from the list of alternatives
• Develop a preliminary list of security requirements based on the MNS and the selected alternative during the CRD

Resources

• NIST Special Publication 800-64, Security Considerations in the Information System Development Lifecycle
• NAS SR-1000, security section