DoD_-_Guidebook,_Cybersecurity_Risk_Management_Framework,_v1.08,_Sep_2015_(1).pdf

Department of Defense

DoD Program Manager’s

Guidebook for Integrating the Cybersecurity Risk Management

Framework (RMF) into the System Acquisition Lifecycle

September 2015

VERSION 1.0

OFFICE OF THE UNDER SECRETARY OF DEFENSE FOR ACQUISITION, TECHNOLOGY, AND LOGISTICS

WASHINGTON, D.C. 20301-3140

DISTRIBUTION STATEMENT A. Approved for public release.

ii

Cleared for Open Publication

May 26, 2015

DoD Office of Prepublication and Security Review iii

Executive Summary Department of Defense (DoD) systems and networks are constantly under cyber attack. Nearly all defense systems incorporate information technology (IT) in some form, and must be resilient from cyber adversaries. This means that cybersecurity1 applies to weapons systems and platforms; Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) systems; and information systems and networks. Cybersecurity is a critical priority for the DoD, and is a vital aspect of maintaining the United States’ technical superiority. DoD recently revised several of its policies to more strongly emphasize the integration of cybersecurity into its acquisition programs to ensure resilient systems. This guidebook is intended to assist Program Managers (PM) in the efficient and cost effective integration of cybersecurity into their systems, in accordance with the updated DoD policies.

The guidebook is based on the following DoD policies:

• Department of Defense Instruction (DoDI) 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), March 12, 2014; cancels the previous DoD Information Assurance Certification and Accreditation Process (DIACAP) and institutes a new, risk-based approach to cybersecurity.

• DoDI 8500.01, Cybersecurity, March 14, 2014; establishes that cybersecurity must be fully integrated into the system lifecycle.

• DoDI 5000.02, Operation of the Defense Acquisition System, January 7, 2015; includes regulatory cybersecurity requirements in the following Enclosures: 3 – Systems Engineering (SE), 4 – Developmental Test and Evaluation (DT&E), 5 – Operational and Live Fire Test and Evaluation (OT&E and LFT&E), and 11 - Requirements Applicable to all Programs Containing IT; establishes that cybersecurity RMF steps and activities should be initiated as early as possible and fully integrated into the DoD acquisition process, including requirements management, systems engineering, and test and evaluation.

Additionally, the Joint Capabilities Integration and Development System (JCIDS) Manual, updated February 12, 2015, implements a robust cyber survivability requirement within the mandatory system survivability Key Performance Parameter (KPP). This new requirement will enhance system resilience in a cyber-contested environment or after exposure to cyber threats.

The risk management framework (RMF) brings a risk-based approach to the implementation of cybersecurity. Transition to the RMF leverages existing acquisition and systems engineering personnel, processes, and the artifacts developed as part of existing systems security engineering (SSE) activities. Unlike a compliance-based checklist approach, the RMF supports integration of cybersecurity in the systems design process, resulting in a more trustworthy system that can dependably operate in the face of a capable cyber adversary. This guidebook emphasizes integrating cybersecurity activities into existing processes including requirements, SSE, program protection planning, trusted systems and networks analysis, developmental and operational test and evaluation, financial management and cost estimating, and sustainment and disposal.

1 The revised policies and this guidebook reflect the Department’s decision to adopt the term cybersecurity in place of information assurance.

iv

This guidebook is based on a set of key tenets that form the basis for the guidance that follows.

The following tenets are not exhaustive, but do outline some of the more important concepts and principles that should be followed to successfully implement the RMF process into acquisition systems:

• Cybersecurity is risk-based, mission-driven, and addressed early and continually.

• Cybersecurity requirements are treated like other system requirements.

• System security architecture and data flows are developed early, and are continuously updated throughout the system lifecycle as the system and environment (including threats) change, to maintain the desired security posture based on risk assessments and mitigations.

• Cybersecurity is implemented to increase a system’s capability to protect, detect, react, and restore, even when under attack from an adversary.

• A modular, open systems approach is used to implement system and security architectures that support the rapid evolution of countermeasures to emerging threats and vulnerabilities.

• Cybersecurity risk assessments are conducted early and often, and integrated with other risk management activities.

• As the system matures and security controls are selected, implemented, assessed, and monitored, the PM collaborates with the authorizing official (AO), the individual responsible for ensuring the cybersecurity risk posture of the system is managed and maintained during operations, to ensure the continued alignment of cybersecurity in the technical baselines, system security architecture, data flows, and design.

• Reciprocity is used where possible through sharing and reuse of test and evaluation products i.e., “test once and use by all.”

Comments, suggestions, questions, and proposed changes to this document should be emailed to DoD.PM.Cybersecurity.comments@mail.mil.

v

Table of Contents 1 Introduction

1.1 Purpose

1.2 Applicability

1.3 Background

2 PM Cybersecurity Basics

2.1 General Expectations for Program Managers

2.1.1 Cybersecurity Basics

2.1.2 PM Cybersecurity Responsibilities

2.1.3 ISSM Roles and Responsibilities in Support of the Program Manager

2.1.4 Cybersecurity Strategy Requirement

2.2 Functional Activities

2.2.1 Cybersecurity Requirements Analysis and Definition

2.2.2 Categorization by Confidentiality, Integrity, and Availability Impact Levels

2.2.3 Functional Decomposition and Allocation of Cybersecurity Requirements

2.2.4 Design and Development

2.2.5 Configuration Management

2.2.6 Risk Assessment

2.2.7 Threat Analysis

2.2.8 Cybersecurity Validation, Test, and Evaluation

2.2.9 Test Plans and Reports

2.3 Risk and the RMF Governance Structure

2.4 Resolving Conflict Arising from Cybersecurity Implementation

3 Acquisition Lifecycle Cybersecurity Activities and Process Flow

3.1 Requirements

3.2 Development

3.3 Authorization

3.4 Operations

Annex A - Cybersecurity Throughout the Acquisition Lifecycle

A.1 Materiel Solution Analysis (MSA) Phase

A.1.1 Cybersecurity Assessment Criteria for Analysis of Alternatives (AoA) vi

A.1.2 Develop Initial Cybersecurity Strategy and Include Cybersecurity in MS A Documentation

A.2 Technology Maturation and Risk Reduction (TMRR) Phase

A.2.1 Include Cybersecurity in System Design and Development RFP Release Decision Documentation

A.2.2 Include Cybersecurity in Preliminary Design and Final MS B Documentation

A.3 Engineering and Manufacturing Development (EMD) Phase

A.3.1 Include Cybersecurity in Detailed Final Design

A.3.2 Test Cybersecurity Requirements in a Cyber Threat Environment and Assess Cyber Risk to Support Initial Deployment Decision

A.4 Production and Deployment Phase and Operations and Support Phase

A.4.1 Production and Deployment: Operationally Test Cybersecurity to Support Full or Final Deployment Decision

A.4.2 Operations and Support: Monitor Cybersecurity and Risk after Authorization to Operate to Maintain Security Posture until Disposal

Annex B - Cybersecurity Roles and Responsibilities

Annex C - Cybersecurity Engineering Considerations

C.1 Introduction

C.2 Background

C.3 Roles and Responsibilities

C.4 Cybersecurity Engineering References

C.5 Program Protection Planning

C.6 TSN Analysis

C.7 Requirements Traceability and Security Controls

C.8 Selecting and Tailoring Security Controls

C.9 Engineering Trade Analyses

C.10 Systems Engineering Technical Reviews

Annex D - Cybersecurity Test and Evaluation Considerations

D.1 Introduction

D.2 Cybersecurity Test and Evaluation

D.2.1 Developmental Test and Evaluation

D.2.1.1 Understand Cybersecurity Requirements

D.2.1.2 Characterize the Cyber Attack Surface

D.2.1.3 Cooperative Vulnerability Identification vii

D.2.1.4 Adversarial Cybersecurity DT&E

D.2.2 Operational Test and Evaluation

D.2.2.1 Cooperative Vulnerability and Penetration Assessment

D.2.2.2 Adversarial Assessment

D.3 Overarching Cybersecurity T&E Guidelines for the PM

Annex E - Cybersecurity Lifecycle and Sustainment Considerations

Annex F - Cybersecurity Risk Assessment Process

F.1 Cybersecurity Risk Assessments

Annex G - Summary of Cybersecurity-Related Artifacts

Annex H - Cybersecurity Request for Proposal Considerations

H.1 Overview

H.2 Request for Proposal (RFP) Language

H.3 Additional Request for Proposal Information

Annex I - Cybersecurity Glossary of Terms and Acronyms

Annex J - Training

J.1 DoD Risk Management Framework (RMF) Training

J.1.1 DISA Training

J.1.2 Defense Acquisition University (DAU) Continuous Learning Modules

J.1.3 DAU Courses

J.2 Other DoD Training Resources

J.3 Non-DoD Cybersecurity Training Open to DoD Personnel

Annex K - References and Resources

K.1 References

K.2 Additional Resources

K.3 Other Reports, Publications and Products

Annex L - Other Cybersecurity Considerations

L.1 Risk Management Framework Background Information

L.2 Cross Domain Solutions (CDS) Information

L.3 Questions Program Managers Can Ask to Determine if Cybersecurity is Integrated into Defense Acquisition Programs

L.4 Information Systems and IT Products

L.5 Platform Information Technology (PIT) and Platform Information Technology Systems viii

Annex M - Examples of Risk Management Framework (RMF) Implementation

M.1 Example 1 –– Unmanned Aerial Bomber System (UABS)

M.1.1 Introduction

M.1.2 Step 1: Categorize System [per Reference (b)]:

M.1.3 Risk Management Framework Step 2: Select Security Controls

M.1.4 Risk Management Framework Step 3: Implement Security Controls

M.1.5 Risk Management Framework Step 4: Assess Security Controls

M.1.6 Risk Management Framework Step 5: Authorize Information System

M.1.7 Risk Management Framework Step 6: Monitor Security Controls

M.2 Example 2 – Practical Automobile Example

M.2.1 The Requirement

M.2.2 Material Solution Analysis Phase

M.2.3 Technology Maturation and Risk Reduction Phase

M.2.4 Engineering and Manufacturing Development Phase

M.2.5 Production and Deployment ix

Table of Figures Figure 1. RMF Process

Figure 3. Conflict Resolution

Figure 4. Acquisition Lifecycle High-Level Cybersecurity Process Flow

Figure 5. DoD Acquisition Lifecycle

Figure 6. MSA Phase of DoD Acquisition Lifecycle

Figure 7. Relating Capabilities/Requirements/Specifications and Security Controls

Figure 8. TMRR Phase of DoD Acquisition Lifecycle

Figure 9. EMD Phase of DoD Acquisition Lifecycle

Figure 10. P&D O&S Phases of DoD Acquisition Lifecycle

Figure 11. TSN Analysis

Figure 12. Traceability of Requirements to Controls

Figure 13. Security Control Selection and Tailoring Process

Figure 14 - Cybersecurity T&E Process Mapped to the Acquisition Lifecycle

Figure 15. Risk Assessment within the Risk Management Process

Figure 16. Generic Risk Model with Key Risk Factors

Figure 17. Risk Assessment Process

Figure 18. PIT and PIT Systems

Figure 19. DoD Plan of Action and Milestone x

Table of Tables Table 1. Meanings for RASCI Matrix

Table 2. Acronyms for RASCI Roles

Table 3. RASCI Matrix for the DoD Acquisition Lifecycle

Table 4. Security Control Identifiers and Family Names

Table 5. Level of Risk Combination of Likelihood and Impact

Table 6. Cybersecurity-Related Artifacts

Table 7. Terms

Table 8. Acronyms

Table 9. Relationship between Types of Information Systems and IT Products

Table 10. DoD Information Systems and PIT Systems (Assess & Authorize)

Table 11. Other DoD -IT (Assess Only)

Table 12. Examples of PIT Systems and Associated PIT

Table 13. Information Type Impact Values

Table 14. Applicable Overlays

Table 15. Security Control Identifiers and Family Names

Table 16. Assumptions

Table 17. Applicable CCIs

Table 18. Likelihood of Threat Events

Table 19. Overall Likelihood and Level of Impact

1 Introduction

1.1 Purpose

The goal of this Program Manager’s Guidebook for Integrating the Cybersecurity Risk Management Framework (RMF) into the System Acquisition Lifecycle document is to help program managers (PM) understand how to integrate cybersecurity into their programs throughout the system lifecycle in accordance with the Risk Management Framework (RMF) and through collaboration with their Authorizing Official (AO), the individual responsible for ensuring the cybersecurity risk posture of the system is managed and maintained during operations. Per DoDI 5000.02 and DoDI 8500.01, building cybersecurity into the system early and throughout the lifecycle is required to enable operational and technical cybersecurity risks to be identified and sufficiently mitigated throughout the acquisition process leading to decreased program costs, shortened schedules, and improved system performance, resilience, and trustworthiness.

PMs need to be aware of steps they can take to identify, evaluate, and affordably address cybersecurity vulnerabilities based on risk throughout the system lifecycle. Doing so will ensure systems are adequately and affordably protected against external and internal threats and can maintain their mission capabilities in a cyber-contested operational environment. This guidebook synthesizes applicable Department of Defense (DoD) policies with Federal guidance for PMs to apply within their programs. Cybersecurity management support is typically provided to PMs from their Program Executive Office (PEO) staff. Other external personnel with cybersecurity responsibilities are assigned by the Service/Agency in which the PM resides.

This guidebook describes an approach to integrate key cybersecurity activities during all phases of the system lifecycle, including the definition, design, development, assessment, deployment, operation, maintenance, and disposal of the system. These activities include identifying, assessing, monitoring, and mitigating cybersecurity risks to an acceptable level for systems and the missions they support. PMs need to ensure cybersecurity risks are actively managed consistent with system performance requirements, and are acceptable to the Service-designated AOs, who provide the system Authorization to Operate (ATO). Close coordination between the PM and AO is critical to the management of cybersecurity risks throughout the entire acquisition process. The failure to do so early in the system lifecycle impacts the AO’s authorization decision as well as system performance, and program cost and schedule. Without the ATO, a system cannot be operated. PMs should work with their AO to discuss the impact of trade decisions and to reach agreement on the tailored documentation required to support the AO’s authorization decision.

The guidebook is organized to provide PMs an understanding of the changes that DoD has implemented in policy to build robust cybersecurity into acquisition programs.

• Section 1 contains background information on recent cybersecurity and acquisition policy changes and information about the applicability of this document.

• Section 2 contains expectations for PMs concerning cybersecurity, including general expectations, some key functional activities that the PM needs to understand, a brief description of the RMF governance structure, and information for PMs on how to resolve and escalate issues related to cybersecurity conflicts.

• Section 3 describes a high-level process flow of building cybersecurity into programs throughout the acquisition lifecycle.

Annex A examines each phase of the acquisition lifecycle, and highlights cybersecurity-related activities and products in more detail than presented in Sections 2 and 3. Annex B describes cybersecurity-related roles and responsibilities associated with the cybersecurity activities at each phase in the lifecycle and provides a detailed matrix of typical cybersecurity activities and the corresponding stakeholders that are responsible, accountable, supportive, consulted, and/or informed for or by each activity.

Additional annexes provide detailed information for specific cybersecurity-related acquisition considerations, including: engineering, test and evaluation, sustainment, the risk assessment process, sample Request for Proposal (RFP) language for cybersecurity, training, resources, and examples of RMF implementation.

1.2 Applicability

This guidebook is applicable to all acquisitions containing information technology (IT),2 including programs at all stages in the lifecycle and all acquisition categories. The RMF applies not only to information systems (e.g., computer networks/enclaves and major applications/defense business systems (DBSs)) but to all IT, which includes information systems, weapons systems, Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems, other platform IT (PIT) systems3 and PIT (e.g., embedded IT, test and diagnostic equipment, mission planning and support systems, and any other information or IT that connects to or accesses weapons and C4ISR systems). There is no difference in the application of the RMF to DBS information systems from non-DBS information systems (e.g., National Security Systems). PIT systems must be secured and assessed and authorized just like information systems under the RMF; however, PIT systems do not have to be entered into the DoD IT Portfolio Repository (DITPR) and undergo Federal Information Security Management Act (FISMA) compliance/oversight. Both information systems and PIT systems must be registered at the DoD Component level. While DoD did not accredit PIT systems under DIACAP, DoD now authorizes PIT systems (e.g., ships, missiles, airplanes, tanks/vehicles with IT) in accordance with the RMF, due in large part to the interconnected nature of embedded IT in these systems.

Program managers will structure, tailor, and phase their programs to best reflect their program’s specific cybersecurity needs. Therefore, some of the acquisition processes and artifacts discussed in the guidebook may not be required for every program or activity. The intent of this guidebook is not to give a precise set of instructions on how to integrate cybersecurity for all programs, but rather to help PMs and their staffs understand the policies, requirements, constraints, and relationships to help them integrate cybersecurity within their own program

2 DoD instructions use the definition for IT from Committee on National Security Systems Instruction (CNSSI) 4009; that definition is included in Annex K.

3 See Annex L for information on PIT and PIT systems.

activities and throughout the program lifecycle. Detailed RMF and cybersecurity implementation guidance for security practitioners is available on the RMF Knowledge Service at https://rmfks.osd.mil, an online resource that serves as the definitive source for RMF implementation guidance for DoD, a repository for templates and tools, and a collaboration space for the RMF community.

1.3 Background

The DoD is increasingly reliant on information technology (IT) and its interconnections in major weapons, C4ISR, facilities, and information systems. DoD systems that have significant vulnerabilities threaten the confidentiality, integrity, and availability (C-I-A) of critical information and functionality supporting DoD missions, operations, assets, and personnel.

Skilled adversaries target DoD systems, networks, users, and interfaces, seeking opportunities to obtain information and disrupt or alter operations. Building robust cybersecurity capabilities into programs is vital to protecting the Department’s critical information, networks, and systems, and to enabling mission success. To guide the integration of robust cybersecurity in the acquisition process, the Department has developed and updated several key policies.

The Under Secretary of Defense (USD) for Acquisition, Technology and Logistics (AT&L) memorandum, January 7, 2015, accompanying the DoD Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System, states that successful defense acquisition depends on careful thinking and sound professional judgments about the best acquisition strategy to use for a given product. It emphasizes tailoring of program structures, content, and decision points to the product being acquired and that programs must deal with the increasingly serious problem of designing for, and managing, cybersecurity in programs. It states that DoD must do a better job of protecting our systems and everything associated with them from cyber threats.

In March 2014, the DoD Chief Information Officer (CIO) published two important documents:

DoDI 8500.01, Cybersecurity, and DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT). DoDI 8500.01 establishes that the term “cybersecurity”4 replaces the term “information assurance” within the DoD. DoDI 8510.01 establishes that the RMF replaces the DoD Information Assurance Certification and Accreditation Process (DIACAP) as the process to manage the lifecycle cybersecurity risk to DoD IT.

The RMF transitions DoD from a historically compliance-based process to a risk-based, full-lifecycle approach. DoD cybersecurity policy as implemented through the RMF process is based on the application of security controls, the selection and implementation of which are based on cybersecurity risk assessments and other SSE activities conducted throughout the system lifecycle. A security control is “a safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements.”5 Security capability requirements are explicitly defined as part of the system survivability key performance parameter (KPP) and other capability requirements document attributes and are derived as technical requirements in system requirements documents and system and item specifications. PMs are

4 See the glossary in Annex I for definition of cybersecurity.

5 NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, April 2013.

https://rmfks.osd.mil/ encouraged to tailor their cybersecurity approach according to system attributes and to base trade-off design decisions on the System Survivability KPP, other KPPs, and derived cybersecurity requirements of their systems.

The RMF enables the design and integration of cybersecurity early in the system development lifecycle to assist in the development of a trustworthy system that can dependably operate in the face of a capable cyber adversary. Security controls are integrated with system requirements through SSE activities, including applying overlays to the baseline set of controls based on system attributes, system/mission assurance security risk assessments and mitigations, and design trades that factor in cybersecurity along with all other program cost/schedule/performance constraints and risks. Cybersecurity requirements need to be matured and maintained throughout the system lifecycle.

Figure 1 describes the six steps of the RMF process. The following sections describe PM specific activities for implementing these steps and Annex M provides examples of RMF implementation in the acquisition lifecycle.

Figure 1. RMF Process

2 PM Cybersecurity Basics

2.1 General Expectations for Program Managers

The PM ensures the program meets statutory, regulatory, and system requirements, balancing lifecycle cost, schedule, system performance, risk, and system security. In doing so, PMs must understand, plan for, and integrate cybersecurity into their programs in a cost-effective manner.

PMs need to tightly coordinate requirements generation, systems security engineering, ongoing risk assessments, program protection planning, and test and evaluation. At the same time, PMs need to understand the motivation of adversaries and the system vulnerabilities that may be exploited to disrupt the operation of their systems and the missions their systems enable on the battlefield. PMs must design, develop and produce DoD systems that will be dependable in the face of a sophisticated cyber adversary.

2.1.1 Cybersecurity Basics

The PM is responsible for meeting cybersecurity requirements throughout the lifecycle of the program. DoDI 8500.01, Cybersecurity, replaced the term information assurance with cybersecurity and defines cybersecurity as:

“Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation”

PMs and Chief Engineers/Lead Systems Engineers who are unfamiliar with the details of the DoD cybersecurity regulations and policies should consider the following three security objectives when trying to balance specific cybersecurity requirements with the other requirements that apply to their system:

• Confidentiality – The property that information is not disclosed to system entities (users, processes, devices) unless they have been authorized to access the information. NIST SP 800.53: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

• Integrity – The property whereby an entity has not been modified in an unauthorized manner. NIST SP 800-53: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

• Availability – The property of being accessible and useable upon demand by an authorized entity. NIST 800-53: Ensuring timely and reliable access to and use of information.

It is critical to understand that cybersecurity extends beyond the bounds of information security, to include:

• Solid engineering that includes design features that promote stability and security.

• Training and awareness to provide users, operators, and sustainers with proper training to ensure they are vigilant.

• Response, recovery, and restoration to actively respond to internal and external malicious attacks, as well as recover from system failures caused by inadvertent operator error, internal and external malicious attack, and major calamities.

2.1.2 PM Cybersecurity Responsibilities

Early resourcing and planning is essential to ensure cybersecurity activities, which protect against the full array of applicable external and internal threats, are adequately resourced, executed, and assessed throughout the acquisition lifecycle. While the process assumes that the program is following the guidance provided in DoDI 5000.02 and Defense Acquisition Guidebook (DAG), that does not imply that every system is an acquisition category (ACAT) program (e.g., deployed system in sustainment), or part of an ACAT program. For those systems that are not required to comply with DoDI 5000.02, the Risk Management Framework artifacts (Security Plan, Security Assessment Report (including risk assessment results or separate Risk Assessment Report), and Plan of Action and Milestones (POA&M)) serve as the reporting templates for tracking cybersecurity compliance for the delivered capability. For cybersecurity implementation into acquisition programs, the requirements and acquisition processes can be divided into three sub-processes, each having specific documentation in which cybersecurity should be clearly articulated. These three sub-processes are described in the following sections.

2.1.2.1 Requirements Generation

Requirements generation is described within the Joint Capabilities Integration and Development System (JCIDS). Requirements generation includes the identification of required capabilities, KPPs, key system attributes (KSAs), and additional performance attributes, which are included in the Initial Capabilities Document (ICD), the Capability Development Document (CDD), the Capability Production Document (CPD), the Concept of Operations (CONOPS), the Information Support Plan (ISP), and the Test and Evaluation Master Plan (TEMP). KPPs include the cybersecurity element of the System Survivability KPP and other KPPs as required.

The PM team and requirements developers must be cognizant of the mandatory System Survivability KPP, which includes cyber survivability requirements. The JCIDS Manual, updated on February 12, 2015, requires development of cyber survivability requirements within the System Survivability KPP, if applicable to the operational context. PMs will need to deliver systems that are able to operate and complete their missions in a cyber-contested environment.

In practice, this KPP requirement will ensure sponsors devote resources to aid in the development of rigorous cyber survivability analysis and ultimately KPP values, and to ensure minimum cyber survivability-related requirements will be met.

2.1.2.2 Acquisition and Program Management

Acquisition and program management provides oversight of the key acquisition and program management processes and documentation, to include, but not limited to: the Acquisition Strategy (AS); Acquisition Program Baseline (APB); Cybersecurity Strategy; Program Protection Plan (PPP); legacy System Threat Assessment Report (STAR) or other threat source documentation (e.g. Validated Online Lifecycle Threat (VOLT)); Systems Engineering Plan (SEP); Cost Analysis Requirements Descriptions (CARD) for Major Defense Acquisition Programs (MDAPs) and Major Automated Information Systems (MAISs) only, and rationale for lifecycle cost estimate for other programs; contracts; Requests for Proposal (RFP); Training

Plan; Life Cycle Sustainment Plan (LCSP); Independent Logistics Assessments (ILA) (for weapon system MDAPs only); etc.

PMs must address cybersecurity in program reviews, including Deep Dives, In-Process Reviews, and Overarching Integrated Product Team (OIPT) meetings, Defense Acquisition Executive Summary (DAES) meetings, and Milestone and Decision Point Defense Acquisition Boards/Milestone Decision Authority (MDA) reviews. The PM needs to build an IPT structure that includes cybersecurity expertise. The Program Management Office (PMO) team should work with external stakeholders6 to build an effective cybersecurity capability. Cybersecurity impacts system and mission performance. For this reason, the PM and acquisition leadership, along with the resource sponsor/capability requirements validation authority, user representative, and the systems engineering (SE) and test communities make cybersecurity trade-offs based on risk and in concert with cost, performance, and schedule constraints. PMs must negotiate risk trade-offs with relevant stakeholders, e.g., AO, Information System Security Manager (ISSM), and others. The PM and AO are the key authorities for most cybersecurity decisions throughout the acquisition lifecycle.

2.1.2.3 Systems Engineering and Test and Evaluation

Implementation of a disciplined systems engineering process that includes cybersecurity is required from requirements analysis through design, test and evaluation, fielding, sustainment, and decommissioning. The cybersecurity design is part of the system’s functional design and it is captured in design documentation, such as the System Design Document (SDD)/System Design Specification (SDS)/System Performance Specification (SPS)/System Requirements Document (SRD) and other lower level technical specifications. Cybersecurity will be reviewed along with all technical documentation during prescribed program technical design reviews governed by the System Engineering Technical Review (SETR) processes.

As systems mature throughout implementation and assessment, the PM, in coordination with ISSM and SSE personnel, needs to ensure the continued alignment of cybersecurity requirements in the technical baselines, the system security architecture, information flows, design, and the security controls. The PM needs to coordinate periodically with the AO to maintain awareness of these activities as they affect the security state and risk posture of the system throughout the Production and Deployment and Operations and Support phases. The PMO will develop and implement a continuous monitoring plan to assure the effectiveness of security controls over time, as changes are made to the system and within the operational environment, including the evolving threat. Annex A, section A.4 describes the Production and Deployment and Operations and Support acquisition lifecycle phases and provides more information on the monitoring of security controls.

PMs also need to develop and maintain a PPP and a detailed Cybersecurity Strategy, and utilize them as the program’s integrating and central point for cybersecurity. The PM must develop a cybersecurity Test and Evaluation (T&E) strategy, allocate resources for cybersecurity T&E, and ensure they are described in the TEMP. PMs need to consider and integrate cybersecurity, including required resources, in the system’s acquisition lifecycle activities including systems

6 The roles and responsibilities of cybersecurity stakeholders are described in Annex B security engineering risk assessments, SETRs, cybersecurity T&E, cost estimation, and artifacts including the SEP, TEMP, and RFP.

2.1.3 ISSM Roles and Responsibilities in Support of the Program Manager

The PM is responsible for appointing an Information System Security Manager (ISSM) for each assigned system with the support, authority, and resources to satisfy the responsibilities established in DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT). In accordance with DoDI 8500.01, Cybersecurity, the ISSM needs to be assigned in writing. The PM should ensure that the designated ISSM has the support, authority, and resources to satisfy the responsibilities established in DoDI 8500.01. Assignment of a qualified ISSM is one of the most important steps and should be accomplished as early as possible to ensure that applicable cybersecurity requirements are addressed in the system architecture and detailed design.

DoD Directive 8570.01, Information Assurance Training, Certification, and Workforce Management, current edition, provides guidance for the identification and categorization of positions and certifications of personnel conducting cybersecurity functions within the DoD workforce and should be used for selecting an ISSM. As the PM’s agent for ensuring compliance with DoD cybersecurity policies and regulations, the ISSM’s roles and responsibilities include:

• Ensure compliance with cybersecurity requirements in accordance with DoD and DoD Component cybersecurity and information assurance policies and guidance.

• Support the PM in development of a POA&M and budget that addresses the implementation of cybersecurity requirements throughout the lifecycle of the system.

• Identify a cybersecurity team; the PM can designate the ISSM to chair a Cybersecurity (may be called Information Assurance) Working-level Integrated Product Team (WIPT) or sub-WIPT, executed under the authority of the Systems Engineering WIPT.

• Support implementation of the RMF.

• Maintain and report systems assessment and authorization status and issues in accordance with DoD Component guidance.

• Provide direction to the Information System Security Officer (ISSO) in accordance with

DoDI 8500.01.

• Coordinate with the organization’s security manager to ensure issues affecting the organization's overall security are addressed appropriately.

• Continuously monitor the system or information environment for security-relevant events and configuration changes that negatively affect security posture.

• Periodically assesses the quality of security controls implementation against performance indicators, such as: security incidents; feedback from external inspection agencies, e.g., Office of the Inspector General (OIG) DoD, Government Accountability Office (GAO);

exercises; and operational evaluations, including Director, OT&E cybersecurity assessments.

• Immediately report any significant change in the security posture of the system, and recommended mitigations, to the Security Control Assessor (SCA) and AO.

• Recommend to the SCA or AO a reassessment of any or all security controls at any time, as appropriate.

• Ensure that SSE processes are aligned to, and adequately documented in the program’s SEP and PPP, and are executed with sufficient rigor to ensure required security controls are implemented, resulting in the lowest level of residual risk to system operation.

• Ensure that cybersecurity inputs to program acquisition documents are prepared.

• Ensure that the program’s contractual documents, such as specifications, statements of work, or Contract Data Requirements Lists (CDRLs) incorporate appropriate cybersecurity language and requirements.

• Support SETRs by ensuring that entry and exit criteria include cybersecurity and are satisfied, and that design documentation meets the specified cybersecurity requirements.

• Ensure that security controls and requirements are properly allocated and documented in design specifications, technical publications and manuals, etc.

• Ensure security controls and requirements are properly allocated and implemented in logistics or program planning documents.

• Ensure that security controls and requirements have been communicated and appropriately resourced by program budget documents and are reflected in the program’s requirements database.

• Ensure that integrated logistics support documentation (e.g., LCSP) incorporate cybersecurity considerations throughout the lifecycle of the system.

2.1.4 Cybersecurity Strategy Requirement

Under the Clinger-Cohen Act, a Cybersecurity Strategy is a statutory requirement for mission critical or mission essential IT systems. Per Table 2, page 51, of DoDI 5000.02, the Cybersecurity Strategy is a regulatory requirement for all acquisitions of systems containing IT, including National Security Systems (NSS), PIT, and PIT systems. It is an iterative document that reflects both the program’s long-term approach for, as well as its implementation of, cybersecurity throughout the program lifecycle. The Cybersecurity Strategy should be used as a tool for PMs, AOs, cybersecurity, and acquisition oversight authorities to plan for, document, assess, mitigate, and manage risks as the program matures. The PM updates and maintains the Cybersecurity Strategy and ensures it matures with the system design throughout the system lifecycle. The Cybersecurity Strategy consolidates elements of various program initiatives and activities relating to cybersecurity planning guidance and efforts. The reuse of existing analysis and documentation is strongly encouraged where practical for the development of the Cybersecurity Strategy to reduce duplication of content and effort. It is incumbent on the submitting Program Management Office (PMO) to ensure that any such information is readily available to the document review/approval chain by providing copies of any supporting documents upon request, including acquisition baselines, systems engineering analyses, test and evaluation, and RMF documentation.

The Cybersecurity Strategy is used by the AO, and reviewed and approved by the Cognizant Chief Information Officer (CIO) prior to milestones and decisions points. For ACAT I programs, the DoD CIO reviews and approves it. The Cybersecurity Strategy elaborates on the approach and cybersecurity risks and countermeasures employed on the system. Additional information, including the prescribed template and authoritative guidance can be found on the Defense Acquisition Guidebook and the RMF Knowledge Service.

2.2 Functional Activities

2.2.1 Cybersecurity Requirements Analysis and Definition

DoD and DoD Component policy requires all programs to implement cybersecurity. All programs should start with the baseline set of security controls based on the system categorization. There are a number of factors that impact the selection of a system’s high-level cybersecurity requirements:

• Results of cybersecurity threat analysis for the system under development.

• Potential impact values for the information types processed, stored, transmitted, or protected by the system; and for the system as they relate to confidentiality, integrity, and availability.

• Functional decomposition and allocation of security controls delineated in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Security and Privacy Controls for Federal Information Systems and Organizations (also called the security control catalog), to the system security architecture (also referred to as the solution architecture) for the system, including all system access points and connections.

• The mission the system is supporting.

• System design features (KPPs, KSAs, and additional performance attributes) that promote stability and security.

• Operating environment (including threat) of the system under development.

• Operational and procedural solutions that may mitigate threats to the system.

The government retains the responsibility and authority for identifying, selecting, and approving the appropriate cybersecurity requirements for consideration in the system design; however, industry expertise may be called upon to evaluate the many factors impacting the cybersecurity design, and to make recommendations as to which cybersecurity requirements should be incorporated into the design of the system. To ensure cybersecurity requirements are considered in the functional design of the system, contracts, Statements of Work, and RFPs need to delineate specific tasks and deliverables in support of cybersecurity. Once the high-level cybersecurity capability requirements have been identified, they should be included in the Draft CDD, CDD, and CPD. In parallel, the requirements should be captured in the program’s requirements management database, e.g., Dynamic Object Oriented Requirements System (DOORS) that permits development of a requirements traceability matrix (RTM).

2.2.2 Categorization by Confidentiality, Integrity, and Availability Impact Levels The determination of system categorization impact levels for the confidentiality, integrity, and availability security objectives is described in Committee on National Security Systems Instruction (CNSSI) 1253, Security Categorization and Control Selection for National Security Systems. System categorization by C-I-A replaced the use of Mission Assurance Category (MAC) and Confidentiality Level (CL), used under DIACAP. The system categorization drives the baseline set of security controls from CNSSI 1253. DoD uses CNSSI security control baselines for all systems (NSSs and non-NSSs). There are three security objectives and each has three possible values (Low, Moderate, or High). Refer to the RMF Knowledge Service at https://rmfks.osd.mil for more information on security control baselines.

2.2.3 Functional Decomposition and Allocation of Cybersecurity Requirements The security controls, KPPs, KSAs, and additional performance attributes, including cybersecurity design features, will be functionally decomposed and allocated to various elements within the system, consistent with system security architecture, e.g., the solution architecture.

Even if a cybersecurity requirement will be inherited from an enterprise system, it still needs to be documented in the requirements database so that the program RTM accurately reflects the cybersecurity requirements flow down from the system security architecture to the system under development. The program RTM also needs to consider any access points and interconnections, as interconnections to these mission planning and support systems/devices (e.g., test and diagnostic equipment), may impose cybersecurity requirements on the system.

In addition to the elements normally found in the RTM, cybersecurity unique tracking elements should be maintained within the RTM. These cybersecurity unique elements will support development of RMF artifacts, if needed. It is important to note that the cybersecurity elements in the RTM should not be treated as a separate set of requirements, but rather a subset of the program’s RTM. The ISSM should exercise caution to ensure that the cybersecurity subset of the RTM is always generated from the program’s RTM. Cybersecurity requirements should be updated using a single, authoritative requirements database that is under strict configuration management.

The program ISSM and SSE need to provide rationale for all cybersecurity requirements that cannot be met or are identified as not applicable.

2.2.4 Design and Development

Systems engineers need to ensure that functional design considerations integrate cybersecurity functional requirements and that these requirements are included throughout the development process. The SETR process requires entrance and exit criteria for each design review.

Cybersecurity-specific criteria are a subset of the entrance and exit criteria. The design review chairperson validates that the cybersecurity technical requirements are included in design documentation and that all entrance and exit criteria, including the subset of entrance and exit criteria for cybersecurity, are satisfied. System trades consider and prioritize cybersecurity requirements against all other system design requirements. Technical requirements that cannot be met, including cybersecurity requirements, should be assessed for the risk to the program, risk to the performance of the system, and risk to the mission. Risk assessments should be conducted and the results brought to the attention of the PM, Resource Sponsor (also called the Mission Owner), and user representative.

Commercial-off-the-shelf (COTS) cybersecurity products and cybersecurity-enabled products should be certified compliant with Committee on National Security Systems Policy 11, National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology Products, June 2013, as amended, by laboratories accredited under the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme or National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Cryptographic Module Validation Program (CMVP). Similarly, government-off-the-shelf (GOTS) cybersecurity products or cybersecurity-enabled products the system employs should be evaluated by the National Security Agency (NSA) or in accordance with NSA approved processes.

2.2.5 Configuration Management

Configuration management is critical to ensuring a successful system design and development process. Controlling and documenting changes in design throughout the analysis, development, and testing process requires strict adherence to an established configuration management process. The configuration management process needs to include changes made to the cybersecurity configuration and associated documentation. Failure to include cybersecurity considerations in the configuration management and engineering change control processes could adversely affect the program’s ability to integrate and maintain cybersecurity in the functional design of the system.

2.2.6 Risk Assessment

PMs are responsible for managing risk in accordance with the mandatory requirements contained in the DoDI 5000.02, Operation of the Defense Acquisition System, and are required to outline their risk management strategy in accordance with the SEP Outline (2011).

Paragraph 6.d. of Enclosure 2 to DoDI 5000.02, discusses program risk: “The Program Manager is responsible for implementing effective risk management and tracking to include the identification of all known risks, key assumptions, probability of occurrence, consequences of occurrence (in terms of cost, schedule, and performance) if not mitigated, analysis of mitigation options, decisions about actions to mitigate risk, and execution of those actions.” DoD Risk Management Guide for Defense Acquisition Programs, 7th Edition (Interim Release), December 2014, provides risk management guidance for PMs. The following paragraphs describe how a program performs cybersecurity risk assessments for the system security architecture, including all system access points and connections. The analysis of cybersecurity risks, in addition to supporting the cybersecurity program, supports the program’s risk management process, and is utilized in the SETRs.

Cybersecurity risk assessment is the process of identifying, analyzing, and assessing system performance and mission consequences of cybersecurity risks. Assessing risk requires the careful analysis of threat and vulnerability information to determine the extent to which circumstances or events could adversely impact an organization and the likelihood that such circumstances or events will occur. A risk model identifies risk factors. The risk factors of concern are threat sources, threat events, likelihood, vulnerabilities predisposing conditions, and impact.

The ISSM and SSE provide the subject matter expertise to plan and execute cybersecurity risk assessment and structured testing that demonstrates satisfaction of cybersecurity requirements.

Per the RMF, selection/tailoring of security controls is a risk- and mission-based process to inform requirements, architecture, design, implementation, integration, test and evaluation, and sustainment. The selection, tailoring and implementation of security controls are enabled by the Chief Engineer/Lead Systems Engineer, SSE, ISSM, and Mission Owner.