1. Requirements

3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems.

1.1 Notes

Project 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, NASA Security Program Procedural Requirements, NPD 1600.2, the NASA Security Policy, 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

Key:    - Applicable | - Not Applicable

2. Rationale

 Software systems have the potential to provide an entry point for actors to abuse or exploit the asset in an unexpected manner.  Identifying the threats and risks as well as the planned mitigations for them early in the project life cycle helps to increase the overall security and enhance the reliability of the system. See also Topic 8.10 - Facility Software Safety Considerations. 

3. Guidance

3.1 Threat Assessment

For flight and ground software, the project manager should assist the program manager by providing program and project information needed by the Agency team and the Information System Security Officer (ISSO) who are performing a threat assessment and/or threat summary to ensure that software defects (design, code, implementation, operations, development process, ...) with security ramifications are included in the assessment/summary and mitigations are captured in the Project Protection Plan. ³⁶²  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. This assistance may be in the form of providing a list of software elements (operating systems, software tools, libraries, …) and software security process/strategies (static analysis tools, vulnerability testing, …) that are being used.  The Project Protection Plan (and other security related documents) may require security clearances to view.

Security requirements for the acquisition, development, integration, and modification of software systems are found in NPR 2810.1.  Security of Information and Information Systems (see IT System Security Plan sections) Sources of potential software security risks include the output of a NIST FIPS-199 (Standards for Security Categorization of Federal Information and Information Systems) assessment for the program, the system security plan (see below), and the program’s risk assessment report available from the ISSO. For NASA users, the Software Security website accessible to NASA users via the NEN is another source for guidance.  Documents from the Consultative Committee for Space Data Systems (CCSDS) include potential security threats and may also be useful sources for guidance.  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.” ⁴⁷²
• “System operators might configure a system incorrectly resulting in security weaknesses.” ⁴⁷²
• “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.” ⁴⁷²

This SWE requirement is to be implemented as early as possible in the project life cycle so that mitigations (secure coding standards and development processes, static code analysis, penetration tests, encryption schemes…) can be built-in or established upfront.  Per the schedule in Appendix I of NPR 7120.5 ⁰⁸², a preliminary version of the Project Protection Plan is due at System Definition Review (SDR)/Mission Definition Review (MDR), a baseline is due at Preliminary Design Review (PDR), and appropriate updates are due at Critical Design Review (CDR), System Integration Review (SIR), Operational Readiness Review (ORR), and Mission Readiness Review (MRR)/Flight Readiness Review (FRR).  Annual updates to the Project Protection Plan are expected once the system is in operation to accommodate changes in the threat environment. Documents like the PPP and SSP may levy requirements on the software systems that have to be addressed by the software engineering.

Software Engineering should be aware that per NPR 7150.2 ⁰⁸³, “Software defects with security ramifications include implementation bugs such as buffer overflows and design flaws such as inconsistent error handling.”  Security-related defects fall into several categories such as memory safety (e.g., dangling pointers), race conditions, secure input and output handling (e.g., validating an input message length), improper exception handling, etc.  Compromises to user authentication, access rights and privileges, data confidentiality, and data integrity also contribute to software systems that are not secure. When identifying security risks in software, be sure to account for all types of information and assets in the system that require protection as well as all the ways the identified information and assets can be accessed. 

See also SWE-156 - Evaluate Systems for Security Risks, Topic 7.22 - Space Security: Best Practices Guide, SWE-159 - Verify and Validate Risk Mitigations, and Topic 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software. SWE-191 - Software Regression Testing, 

3.2 Project Protection Plan

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.” See also SWE-157 - Protect Against Unauthorized Access, SWE-210 - Detection of Adversarial Actions, 

For more information on the contents of a PPP, a PPP outline ⁰⁶⁰ is available on the section of the Community of Practice for Mission Resilience and Protection accessible to NASA users from the NEN.

Consult threat and risk models and examples such as those provided on the software security page of the NEN.

(4) System Security Plans are not owned by engineering, but engineering has input into the SSP.  The SSP definition is documented in NPR 2810.1, they address the threats and risks associated with the system.

3.3 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.4 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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 ⁵⁸⁹: ”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 ⁵⁹⁰: “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 ⁵⁹¹: “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

Also, Software Assurance may need to review the PPP, SSP, and other products that affect the software system.

7.2 Software Assurance Products

• None identified at this time.

  Objective Evidence

  • The project's risks list.
   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

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

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

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

See the guidance from section 3.0. 

See also Topic 7.22 - Space Security: Best Practices Guide, and 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: