1. Requirements

1.1 Notes

Space Asset or Enterprise Protection Plans are a source of requirements to identify cybersecurity risks, along with their mitigations, in-flight and ground software systems. Space Asset or Enterprise Protection Plans describe the program's approach for planning and implementing the requirements for information, physical, personnel, industrial, and counterintelligence/counterterrorism security, and for security awareness/education requirements in accordance with NPR 1600.1, NPD 1600.2, NPD 2810.1, and NPR 2810.1. Include provisions in the plan to protect personnel, facilities, mission-essential infrastructure, and critical program information from potential threats and vulnerabilities that may be identified during the threat and vulnerability assessment process.

1.2 History

1.3 Applicability Across Classes

2. Rationale

The reality is that there are many existing capabilities [able] to deny, disrupt or physically destroy NASA's space systems and the ground facilities that... control them.  Knowledge of U.S. space systems functions, locations, and physical characteristics, as well as the means to conduct counter space operations, is increasingly available on the international market.  Nations or groups hostile to the U.S. either possess or can acquire the means to disrupt or destroy U.S. space systems by attacking the spacecraft in space, their communications nodes on the ground and in space”, the ground nodes that command the spacecraft or process their data or the commercial/public infrastructure that supports a space system's operations. 

Software defects have the potential to leave a system compromised and open to cyber-attacks. Identifying risks and planning appropriate mitigations early in the project life cycle help increase the overall security and enhance the survivability of the space flight software system. 

3. Guidance

For flight and ground software, the project manager assists the program manager providing program and project information needed by the Agency team and the Information System Security Officer (ISSO) performing a threat assessment and/or threat summary to ensure that software defects with security ramifications are included in the assessment/summary and mitigations are captured in the Project Protection Plan. Per the Frequently Asked Questions (FAQ) section of the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network (NEN), “Threat summaries and protection plans are drafted as early in the formulation as possible to minimize the impact of any protection-related design requirements.” The project manager reviews the Project Protection Plan to ensure that mitigations for software defects with security ramifications are included in the Project Protection Plan created per NPR 7120.5.

Note that security requirements “for the acquisition, development, integration, and modification of ground software systems are found in NPR 2810.1.” (NPR 7150.2C 

• “Users or administrators can install unauthorized or un-vetted software, which might contain bugs, viruses, spyware, or which might simply result in system instability.”

  Swerefn
  refnum 471

• “System operators might configure a system incorrectly resulting in security weaknesses.”

  Swerefn
  refnum 472

• “Programmers may introduce logic or implementation errors which could result in system vulnerabilities or instability.”
• “External threat agents might attempt to exploit a vulnerability to inject software or configuration changes.”

  Swerefn
  refnum 472

This requirement is to be implemented as early as possible in the project life cycle so that mitigations can be built-in or established upfront.  Per the schedule in Appendix I of NPR 7120.5 

Per NPR 7150.2

Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, “Project Protection Plans (PPPs) ...have three purposes, which are described as follows:

(1) Project Protection Plans document the survivability strategy(s) used by a project, identify the valid threats and corresponding vulnerabilities to a mission and recommend potential countermeasures to ensure the protection of the infrastructure elements that support the civil space system.

(2) Protection plans provide project management personnel (project managers, project scientists, mission systems engineers, operations managers, and the user community, etc.) with an overall view of the valid threats to their project (both hostile and environmental), identify infrastructure vulnerabilities and proposes security countermeasures to mitigate risks and enhance the survivability of a civil space system.

(3) PPPs are the medium through which the civil space organizations will provide technical information on our space systems to the [Department of Defense (DoD)], Department of State, Department of Homeland Security, and the Intelligence Community to assist them in providing timely support to NASA in the event of an incident involving one of our missions. For example, protection plans include the following types of information:

a. [Tracking, Telemetry, and Command] TT&C or uplink frequency.

b. Other NASA space systems using the TT&C or uplink frequency.

c. RF antenna gain values.

d. Nominal telemetry downlink cycles.

e. Ground network and space network assets normally used for TT&C with the affected spacecraft.

The first step in developing a PPP is to extract the viable threats (which are commonly referred to as protection threats) from a civil space system's threat summary and categorize them according to the NASA Risk Matrix Standard Scale. Protection threats are defined as any natural or manmade event, accident, or system with the ability to exploit a susceptibility of any part of a space system resulting in the potential damage, degradation, destruction, or denial of service to the mission. The next step is to determine the vulnerabilities in a space system by fusing space system susceptibilities with protection threats, where Threat X Susceptibility = Vulnerability, and then recommend protection measures to alleviate the risks posed by the unmitigated vulnerabilities. This process is iterated between the SPWG and a mission's project management team between issuance of the baseline PPP and before each succeeding [key decision point (KDP)] until launch. After launch, the PPPs are updated annually to accommodate changes in the threat environment. The desired result is an enhanced space system survivability.”

For more information on the contents of a PPP, a PPP outline

Additional guidance related to software security may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.  

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to software security:

• Verify That Test Equipment Cannot be Interrupted by Extraneous Computer Processes.  Lesson Number 8501

  Swerefn
  refnum 589

  : ”Many computers used for specialized purposes in test facilities are general-purpose computers that may also be configured to perform office functions. Processes extraneous to flight system testing (e.g., code updates, scheduled file backups, e-mail downloads, and security scans) may occur intermittently on these units without user interaction or knowledge, particularly when they are connected to institutional networks. Should an extraneous process interrupt an active test, significant test time may be lost and the test article or support equipment may be damaged.”
• International Space Station (ISS) Program/Computer Hardware-Software/Downlink Encryption.  Lesson Learned Number 1148

  Swerefn
  refnum 590

  : “NASA has taken positive steps for upgrading the security on the ISS uplink by adopting a more robust encryption scheme.”
• Computer Hardware-Software/International Space Station/Uplink Encryption.  Lesson Learned Number 1133

  Swerefn
  refnum 591

  : “The recent compromising of the Data Encryption Standard (DES) suggests that the ISS command uplink may not be sufficiently protected.”

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that cybersecurity risks, along with their mitigations, are identified and managed.
   

7.2 Software Assurance Products

• None identified at this time.

  Note
  title Objective Evidence
  The project's risks list.

  Expand
  title Definition of objective evidence
  Include Page SITE:Definition of Objective Evidence SITE:Definition of Objective Evidence

7.3 Metrics

•  # of Risks identified in each life-cycle phase (Open, Closed).
• # of Risks by Severity (e.g., red, yellow, green) over time.
• # of Risks with mitigation plans vs. total # of Risks.
• # of Risks trending up over time.
• # of Risks trending down over time.
• # of Cybersecurity Risks identified (Open, Closed, Severity).
• # of Cybersecurity Risks with Mitigations vs. # of Cybersecurity Risks identified.
• # of Cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses
• # of Cybersecurity mitigation implementations identified with associated test procedures vs. # of Cybersecurity mitigation implementations identified

7.4 Guidance

Assure that cybersecurity risks, along with their mitigations, are identified and managed. See the SA guidance on SWE-156.

For flight and ground software, the project manager assists the program manager by providing program and project information needed by the Agency team and the Information System Security Officer (ISSO) performing a threat assessment and/or threat summary to ensure that software defects with security ramifications are included in the assessment/summary and mitigations are captured in the Project Protection Plan. Per the Frequently Asked Questions (FAQ) section of the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network (NEN), “Threat summaries and protection plans are drafted as early in the formulation as possible to minimize the impact of any protection-related design requirements.” The project manager reviews the Project Protection Plan to ensure that mitigations for software defects with security ramifications are included in the Project Protection Plan created per NPR 7120.5.

Note that security requirements “for the acquisition, development, integration, and modification of ground software systems are found in NPR 2810.1.” (NPR 7150.2)  Sources of potential software security risks include the output of a FIPS-199 assessment for the program, the system security plan, and the program’s risk assessment report available from the ISSO. For NASA users, the Secure Coding Portal accessible to NASA users via the NEN is another source.  Documents from the Consultative Committee for Space Data Systems (CCSDS) include potential security threats and may also be useful sources.  CCSDS documents regarding security threats against space missions note that software threats applicable to space and ground segments include mistakes made by “users, system operators, and programmers [that] could result in loss of data, loss of spacecraft control, unauthorized spacecraft control, or loss of mission” :

• “Users or administrators can install unauthorized or un-vetted software, which might contain bugs, viruses, spyware, or which might simply result in system instability.”

  Swerefn
  refnum 471

• “System operators might configure a system incorrectly resulting in security weaknesses.”

  Swerefn
  refnum 472

• “Programmers may introduce logic or implementation errors which could result in system vulnerabilities or instability.”
• “External threat agents might attempt to exploit a vulnerability to inject software or configuration changes.”

  Swerefn
  refnum 472

This requirement is to be implemented as early as possible in the project life cycle so that mitigations can be built-in or established upfront.  Per the schedule in Appendix I of NPR 7120.5 

“Software defects with security ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.” 

Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, “Project Protection Plans (PPPs) ...have three purposes, which are described as follows:

(1) Project Protection Plans document the survivability strategy(s) used by a project, identify the valid threats and corresponding vulnerabilities to a mission and recommend potential countermeasures to ensure the protection of the infrastructure elements that support the civil space system.

(2) Protection plans provide project management personnel (project managers, project scientists, mission systems engineers, operations managers, and the user community, etc.) with an overall view of the valid threats to their project (both hostile and environmental), identify infrastructure vulnerabilities and proposes security countermeasures to mitigate risks and enhance the survivability of a civil space system.

(3) PPPs are the medium through which the civil space organizations will provide technical information on our space systems to the [Department of Defense (DoD)], Department of State, Department of Homeland Security, and the Intelligence Community to assist them in providing timely support to NASA in the event of an incident involving one of our missions. For example, protection plans include the following types of information:

a. [Tracking, Telemetry, and Command] TT&C or uplink frequency.

b. Other NASA space systems using the TT&C or uplink frequency.

c. RF antenna gain values.

d. Nominal telemetry downlink cycles.

e. Ground network and space network assets normally used for TT&C with the affected spacecraft.

The first step in developing a PPP is to extract the viable threats (which are commonly referred to as protection threats) from a civil space system's threat summary and categorize them according to the NASA Risk Matrix Standard Scale. Protection threats are defined as any natural or manmade event, accident, or system with the ability to exploit a susceptibility of any part of a space system resulting in the potential damage, degradation, destruction, or denial of service to the mission. The next step is to determine the vulnerabilities in a space system by fusing space system susceptibilities with protection threats, where Threat X Susceptibility = Vulnerability, and then recommend protection measures to alleviate the risks posed by the unmitigated vulnerabilities. This process is iterated between the SPWG and a mission's project management team between issuance of the baseline PPP and before each succeeding [key decision point (KDP)] until launch. After launch, the PPPs are updated annually to accommodate changes in the threat environment. The desired result is an enhanced space system survivability.”

For more information on the contents of a PPP, a PPP outline