1. Requirements

3.16.3 The project manager shall implement the identified software security risk mitigations addressed in the Project Protection Plan.

1.1 Notes

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

1.2 Applicability Across Classes

2. Rationale

Software defects with security ramifications can leave systems compromised and open to attack. Implementing appropriate planned mitigations can help protect space flight software systems, keep them secure, and eliminate or reduce the impact of single points of failure in the systems.

3. Guidance

Secure coding is the art of writing software that is impervious, or at the very least, much less vulnerable to attack by malicious people or programs. Secure coding helps protect a program’s data from theft or corruption. An insecure program can provide access for an attacker to take control of ground and/or flight systems, resulting in anything from a denial of service to the compromise of information or severe damage to the system, leading to failure of the mission. Knowing how to write code securely is important for all types of software in all types of environments.

Implementation of risk mitigations for software security includes ensuring the appropriate requirements, design, code, and tests are in place for these risk mitigations.  Appropriate controls and verifications are planned early in each relevant life-cycle phase and included in the software system for each risk.  If they exist for the program or project (check with the Information System Security Officer (ISSO)), the system security plan, security concept of operations, security architecture, risk assessment report, and security requirements traceability matrix (if not part of the general bidirectional requirements traceability matrix) are all possible inputs to the controls and verifications planning step.  These documents are useful when implementing software security risk mitigations because they contain system-specific security implementation content to address risk commensurate with the impact level (high, moderate, low) for the system, the technologies selected/being developed, the limitations (if any) of the platforms, etc.

A general recommendation is for software projects to use coding standards that recommend alternatives to insecure coding practices to help software developers reduce or eliminate vulnerabilities in spaceflight software systems (see SWE-061).  Additionally, flowing down all of the appropriate security requirements into the software will help ensure that all known software security vulnerabilities are mitigated during implementation in accordance with the project’s acceptable risk tolerance level. This requirement is for space flight software only.  Security requirements for ground software systems are found in NPR 2810.1. 

Per the Project Protection Plan template in the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network, “For those instances where a critical node cannot be protected via system design modifications then institutional security measures will have to be used and documented in either the Security Plan or the Information Technology plan.”

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

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.