1. Requirements

3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

The purpose of security risk management is to identify potential software security problems before they occur so that software security risk handling activities can be planned and invoked as needed across the life of the space flight software product or project. 

3. Guidance

3.1 Purpose Of This Requirement

The purpose of this requirement is:

1. To ensure that the  software development organizations work with the Project Protection Plan ³⁶²  to evaluate all software security risks identified in the Project Protection Plan, System Security Plan, and related documents
2. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is evaluated for software security vulnerabilities.
3. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is factored into the planning process for the Project Protection Plan.
4. To ensure that the cyber security assessment (including risks) is performed throughout the software development life cycle.
5. Assess the software requirements to determine if the software requirements include software cybersecurity requirements per the Project Protection Plan, per NASA AA Directive on Robotic Spacecraft Command (if applicable), and per the SPACE SYSTEM PROTECTION STANDARD, NASA-STD-1006  ⁶⁶³

The software development team, the IT security experts, the project office, and the system engineering team all work together to ensure that all systems that include software are evaluated for security risks.

See also SWE-147 - Specify Reusability Requirements, 

3.2 Project Protection Plan

The risk and risk mitigation implementation approaches are defined and documented in the Project Protection Plan. The software development team is responsible for implementing any software mitigations identified in the Project Protection Plan. Ideally, this should be done as early in the requirements and design cycle as possible. The assessment should also be done any time the development project adds or changes software components to ensure that the project does not introduce any additional or new software security risks.

The software protections identified in the Project Protection Plan and/or the System Security Plan should be implemented and verified by the software development organization just like any other requirement or hazard analysis migration. The requirements and design for the software security features should be designed and tested just like any other requirement.

Any COTS, GOTS, MOTS, Open Source, and reused software components used in the software should be screened by IT security and software security static analysis tools.

See also Topic 8.08 - COTS Software Safety Considerations. 

3.3 Secure Coding Practices

The Software Security Community of Practice ⁶⁶⁴, accessible to NASA users from the NASA Engineering Network (NEN), is a good source for secure coding tools and practices.

3.4 Software Security Analyses

The frequency of the software security analyses should be included in the Project Protection Plan and/or the System Security Plan. 

Systems that include space flight software are not exempt from security-related risks or attacks. Evaluating systems that include space flight software for security risks allows projects and programs to identify and plan mitigations to reduce or eliminate the effect such risks have on the security of the overall mission.

Per the Project Protection Plans description file on the Community of Practice for Mission Resilience and Protection Program (MRPP) accessible to NASA users from the NEN, the Protection Plan is a classified document that identifies both hostile and environmental threats to NASA systems (software, network, hardware, ...) and draws attention to high-risk system vulnerabilities (in particular, critical nodes and single points-of-failure). High-risk vulnerabilities can be mitigated either through system design or via enhanced security. The Plan should discuss how institutional security providers implement risk mitigation techniques to protect the critical nodes (as identified in the Protection Plan) of a space system's space, ground, and information segments.

Off-the-shelf (OTS) software, open-source and reused software introduce additional potential security issues when used in a project, so careful consideration and assessment is needed to determine the effect those types of software have on the overall security of the system.

The responsibility for space asset protection is through each project's Chief Engineer or Mission Systems Engineer (MSEs)... Once a project's spacecraft is launched and operational a systems engineer from the flight operations team will take on protection responsibilities and interface with the Space Protection Working Group (SPWG).

3.5 Independent Risk Assessors

Project managers typically work with independent risk assessors, such as the Information System Security Officer (ISSO) and other software security experts, to have system security risk assessments or analyses performed, recording in project records that the assessments were completed and appropriate mitigations incorporated into project plans. Assessments of the flight and ground software components may require input from the developers to help the assessment team perform the security risk analysis.

System security risk assessments should:

1. Cover the entire mission system.
2. Inspect requirements for security-related details.
3. Assess for vulnerabilities and potential failures in system components, including software.
4. Measure the impact of the security risk on the system.
5. May include penetration tests.

Useful sources for software security risk assessments include:

1. System-level risk assessment reports (contact the ISSO).
2. Vulnerability assessment plans (contact the ISSO).
3. The output of static code analysis.

Security risk assessments occur “at the very beginning of the project and continue with each program review. It is also important to assess risks whenever requirements change and when the potential for new vulnerabilities and new threats are introduced" ⁴⁹⁴. See also SWE-154 - Identify Security Risks, 7.22 - Space Security: Best Practices Guide

For new systems, COTS, GOTS, MOTS, open-source, and reused software, assessments for security risks are performed before the use of the software in the flight and ground software system, e.g., be part of any trade studies used to determine whether to incorporate OTS, open-source or reused software.  The results of the assessment are one factor in determining whether to use the evaluated software as part of the project. See also SWE-027 - Use of Commercial, Government, and Legacy Software. 

3.6 System Testing and Security Requirements

It is important to not rely completely on system testing to verify software security requirements.  System tests are not typically developed from the beginning to include the proper and full set of test cases to verify software security requirements.  Verification of software security requirements should occur, like all software verification activities, throughout the life cycle. See also SWE-157 - Protect Against Unauthorized Access and 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, SWE-205 - Determination of Safety-Critical Software,

3.7 Additional Guidance

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

3.8 Center Process Asset Libraries

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

4. Small Projects

The acceptable risk posture for smaller projects or mission class will vary depending on the project type (e.g. CubeSat vs large observatory) and should be considered.  The cyber security assessment needs to be performed and risks identified. 

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

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

7.2 Software Assurance Products

• List of findings from software cybersecurity assessments.

  
  

  Objective Evidence

  Evidence of confirmation that the project has completed a Threat Summary and has a Project Protection Plans (PPP).

   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

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance

Look at the secure coding ⁶⁶⁴ information  (NASA only link).

1. Confirm the project performed a software cybersecurity assessment on the software components per the Agency security policies and the project requirements.

The purpose of this requirement is:

1. To ensure that the software development organizations work with the Project Protection Plan ³⁶²  to evaluate all software security risks identified in the Project Protection Plan, System Security Plan, and related documents.
2. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is evaluated for software security vulnerabilities.
3. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is factored into the planning process for the Project Protection Plan.
4. To ensure that the cyber security assessment (including risks)  is performed throughout the software development life cycle.
5. Assess the software requirements to determine if the software requirements include software cybersecurity requirements per the Project Protection Plan, per NASA AA Directive on Robotic Spacecraft Command (if applicable), and per the SPACE SYSTEM PROTECTION STANDARD, NASA-STD-1006 ⁶⁶³.

NPR 7120.5E ⁰⁸² requires all flight programs/projects to develop Threat Summaries and Project Protection Plans (PPP). The PPP serves as a starting point for mission protection planning and is linked to consistent high threat and risk issues.  The Project Protection Plans incorporate results of the Candidate Protection Strategies (CPS) Asset Protection analysis, including any requisite requirement tailoring.

2. Confirm that the project assessment includes risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.

Quality, security-related vulnerability assessments/analyses on COTS, GOTS, MOTS, OSS, or reused software components:

• May focus on  ⁴⁸⁴:
  • Code that runs by default.
  • Code that runs in an elevated context.
  • Code connected to a globally accessible network interface.
  • Code is written in a language whose features facilitate addressing vulnerabilities.
  • Code with a history of vulnerabilities.
  • Code that handles sensitive data.
  • Complex code.
  • Code that changes frequently.
• Assess for bugs, programming errors, and potential failures.
• Confirm, to some acceptable level of rigor, that software does not do what it is not supposed to do
• Assess the impact and likelihood of vulnerability exploitation.
• May check for adherence to secure architecture, design, coding standards, including the use of secure coding practices (may be difficult to do for OTS software).
• Use automated security static code analysis as well as coding standard static analysis.

3. Confirm that the cybersecurity risks and associated mitigations have been identified to satisfy the conditions in SWE-154 - Identify Security Risks.

Work with Information System Security Officer (ISSO) to assure that all the cybersecurity risks and mitigations identified in space and ground systems have been identified and confirm that the appropriate requirements to address these risks and their mitigations have been added to the requirements. Review the guidance in SWE-154 and check to see that those conditions are satisfied. See also Topic 7.22 - Space Security: Best Practices Guide. 

7.5 Additional Guidance

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