NASA Procedural Requirements

NPR 2810.1F Effective Date: January 03, 2022 Expiration Date: January 03, 2027

Subject: Security of Information and Information Systems

Responsible Office: Office of the Chief Information Officer

Appendix E Requirements Matrix with respect to system lifecycle

E.1 Overview

E.1.1 This appendix provides an overview of information security artifacts and processes mapped to stages in the NPR 7120 project and program development life cycle.

E.1.2 This appendix is included to provide information regarding the application of information security principles and the requirements this directive in the context of programs and projects primarily governed by the NPR 7120 lifecycles.

E.1.3 Given the wide range of projects and activities, the timelines and artifacts outlined in this appendix are to be regarded as informative rather than restrictive.

E.1.4 Figure E 1 provides a visual representation of the information security artifacts related to the program or project lifecycle.

Figure E 1. Mapping of artifacts to stages of the NPR 7120 life cycle

E.2 IT System Security Plan

E.2.1 Overview

(1) The SSP is the critical cybersecurity plan for information systems in any given project or program. It addresses the threats and associated risks faced by the system as provided in section 2.3.5.3. This is the primary artifact that will define cybersecurity risk and processes throughout the life of an information system. This artifact and the information system are registered with the OCIO in the Risk Information Security Compliance System (RISCS).

(2) The AO or the AODR has primary responsibility for the approving the SSP, but the ISO prepares the plan. Supporting roles include the CIO, SAISO, and IO, and ISSO.

(3) The Program or Project Manager's role is to ensure adequate planning (to include resource planning) and effort is applied to this vital document and associated processes per sections 1.2.3.11a, 2.3.3.4a, and 2.4.2.7b.

E.2.2 Advance preparation

(1) Before preparing preliminary SSP, projects and programs should begin consideration of IT resource and security requirements and processes. The Analysis of Alternatives (AoA), preliminary system concept, and acquisition strategy should inform this planning.

(2) In general, the system concept development, including preliminary IT requirements are reviewed at SRR. Information useful at this stage includes:

(a) network diagram;

(b) data flows; and

(3) system interconnections.

E.2.3 Preliminary SSP

(1) In general, at MDR a preliminary SSP is provided.

(2) Examples of items in the Preliminary IT SSP include:

(a) Responsibilities;

(b) System environment;

(c) Connections;

(d) Internet security assessment;

(e) Data categorization based on Information and Privacy Threshold Analysis (IPTA) or Privacy Impact Assessment (PIA), and other analysis;

(f) Controls, planned or in place;

(g) Overlays;

(h) POA&M implementation plan and resources;

(i) System status (operational, under development, under major modification);

(j) Maintenance Plan for Authorization and Accreditation; and

(k) Update Schedule.

E.2.4 IT System Security Plan Approval

(1) In general, at PDR the AO or AODR approves the SSP.

(2) The approval package includes the following information:

(a) Responsibilities;

(b) System environment;

(c) Connections;

(d) Internet security assessment;

(e) Data categorization based on IPTA or PIA, and other analysis;

(f) Controls, planned or in place;

(g) Overlays;

(h) Plan of Action and Milestones (POAM) implementation plan and resources;

(i) System status (operational, under development, under major modification);

(j) Maintenance Plan for Authorization and Accreditation; and

(k) Update Schedule.

E.2.5 Security Control Documentation

(1) Document the security control implementation, as necessary, in the IT System Security Plan, providing a functional description of the control implementation, including:

(a) planned inputs;

(b) expected behavior; and

(c) expected outputs.

E.2.6 Key Updates

(1) Update the IT System Security Plan, security assessment report, and plan of action and milestones based on the results of the continuous monitoring process.

E.3 Security Assessment Plan

E.3.1 Overview

(1) The primary way that an authorizing official can assess mitigated and residual risks is the results of testing the security controls described in the Security Assessment Plan (SAP). The testing described in this plan will identify vulnerabilities as well as confirm adequate implementation of the security controls. Like other test plans, this is evaluated in the Test Readiness Review (TRR).

(2) The Security Control Assessor has primary responsibility for the SAATP. Supporting roles include the AO, AODR, CIO, SAISO, ISO, ISSO, and IO.

(3) The Program or Project Manager's role is to ensure test planning and testing are conducted.

E.3.2 Assessment Preparation

(1) Develop, review, and approve a plan to assess the security controls. This plan would include planned testing such as:

(a) Vulnerability Assessment;

(b) Static Testing; and

(c) Dynamic Testing.

(2) This plan would also include:

(a) Cyber Modeling and Simulation (Live, Virtual, Constructive);

(b) Event Command and Control (C2) Management;

(c) Fault Management and Mitigation;

(d) Event Exercises and Gaming;

(e) Mission Rehearsal;

(f) Threat Representation; and

(g) Cyber Training.

E.4 Security Control Assessment Report(s)

E.4.1 Overview

(1) The Security Control Assessment Report (SAR/SCAR) documents the results of the testing performed, particularly highlighting vulnerabilities remaining in the information system.

(2) The Security Control Assessor has primary responsibility for the SAR/SCAR. Supporting roles include the ISO and ISSO.

(3) The Program or Project Manager will submit SAR/SCAR along with a plan or action to remediate remaining vulnerabilities as part of their ATO package to receive an Authorization to Operate.

E.4.2 Security Control Assessment Report

(1) In general, at ORR the SAR/SCAR is prepared.

(2) The SAR/SCAR documents the issues, findings, and recommendations from the security control assessment.

E.4.3 SAR/SCAR Update

(1) The SCAR is updated annually or with major system changes upon conclusion of further system testing.

E.5 Plan of Action and Milestones/Risk-Based Decisions

E.5.1 Overview

(1) A POA&M identifies plans to remediate any documented information security deficiencies or vulnerability in an information system. Depending on the criticality of the deficiency or vulnerability, an AO is unlikely to give Authorization to Operate until elements of this plan are complete.

(2) The ISO has primary responsibility for the POA&M under sections 2.4.2.5b and c. Supporting roles include the ISSO and the IO.

(3) The Program or Project Manager's role in the POA&M process is to ensure the actions required in this plan are incorporated into overall project plans and tracked to completion as well as to ensure accepted risks are captured in the Project Risk database.

E.5.2 Plan of Action and Milestones (if applicable)

(1) In general, at Operational Readiness Review (ORR) the plan of action and milestones is prepared.

(2) The POA&M is based on the findings and recommendations in the security assessment report excluding any remediation actions taken.

E.5.3 Risk-Based Decisions

(1) Decide to accept an information security risk within the context of the overall understanding of the security posture of an information system.

E.5.4 Updated Plan of Action and Milestones

(1) Update the plan based on remediation, further testing, or a major system change.

E.6 Authorization to Operate

E.6.1 Overview

(1) A signed ATO is required for operation of an information system under section 2.4.2.5i. This signature is final confirmation that the AO considers that risks are adequately mitigated and the residual risk to Mission operations and Agency personnel is acceptable compared with the value of operating the information system.

(2) The AO has responsibility to approve the ATO package under section 1.2.3.8a, and the AO may not delegate this responsibility (see section 1.2.3.8c). The AODR and SAISO play supporting roles in the approval process of an ATO.

(3) Approval of this package is the Program or Project Manager's primary indication that a system under their control is compliant with this directive under section 1.2.3.11b. The PM role in the ATO process is to ensure the project team has prepared a complete authorization package that correctly identifies the state of information system described.

E.6.2 Risk Acceptance

(1) ATO package has the following elements:

(a) IT System Security Plan;

(b) Security Control Assessment Report(s); and

(c) POA&Ms and risk-based decisions.

(2) The AO determines if the cybersecurity risk to organizational operations, organizational assets, individuals, other organizations, or the Nation is acceptable.

DISTRIBUTION:
NODIS

This document does not bind the public, except as authorized by law or as incorporated into a contract. This document is uncontrolled when printed. Check the NASA Online Directives Information System (NODIS) Library to verify that this is the correct version before use: https://nodis3.gsfc.nasa.gov.