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

The purpose of this requirement is:

1. To ensure that the space flight software development organizations work with the Project Protection Plan to evaluate all software security risks identified in the Project Protection Plan.
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 software security risk identification process is performed throughout the software development lifecycle.

The flight 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 space flight software are evaluated for security risks.

The risk and implementation approaches are defined and documented in the Project Protection Plan. The space flight software development team is responsible for implementing any space flight 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 space flight software components to ensure that the project does not introduce any additional or new software security risks.

The space flight software protections identified in the Project Protection 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 space flight software security features should be designed and tested just like any other functional requirement.

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

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

The frequency of the space flight software security analyses should be included in the Project Protection 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 Space Asset Protection accessible to NASA users from the NEN, the Protection Plan is a classified document that identifies both hostile and environmental threats to a NASA space system 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 Security 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 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.

Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, 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)”.

Project managers typically work with independent risk assessors, such as NASA IV&V Program’s Safety and Mission Assurance (SMA) Support Office (SSO) Information Assurance Program, and other software security experts, including the Information System Security Officer (ISSO), 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 space flight software components may require input from the developers to help the assessment team perform the security risk analysis.

System security risk assessments:

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

Useful sources for software security risk assessments include:

• System-level risk assessment reports (contact the ISSO).
• Vulnerability assessment plans (contact the ISSO).
• 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" ⁴⁹⁴.

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 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.

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.

Additional guidance related to software security and OTS software 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

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

1. Confirm the project has performed 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. 

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

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 space flight software development organizations work with the Project Protection Plan to evaluate all software security risks identified in the Project Protection Plan.
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 software security risk identification process is performed throughout the software development lifecycle.
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.

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.