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 allow projects and programs to identify and plan mitigations to reduce or eliminate the affect 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).
• 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 prior to 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 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.