This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
View this section on the website
See edit history of this section
Post feedback on this section
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
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
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.”
Project Protection Plans are classified documents. Per the Frequently Asked Questions section of the Community of Practice for Space Asset Protection accessible to NASA users from the NASA Engineering Network, “NASA has developed a process to incrementally lower classification levels of relevant threat information to Secret and worked with project management teams to obtain clearances for their personnel at that level. Program/Project managers can also be read in at the Secret level for short time periods to review Project Protection Plans.”
NASA users should consult center Process Asset Libraries (PALs) for center-specific guidance and resources related to software security.
Additional guidance related to software security may be found in the following related requirements in this Handbook:
4. Small Projects
No additional guidance is available for small projects.
5. Resources
Renew your license to continue
Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.
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.
