bannerb

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Include Page
2B-Page Warning
2B-Page Warning

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Div
idtabs-1

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

 

Applicable b
a1
b1
csc1
c1
d0
dsc0
e0
f0
g0
h0

Div
idtabs-2

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.

Div
idtabs-3

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

Note

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

Note

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:

SWE-154

Identify Security Risks

SWE-156

Evaluate Systems for Security Risks

SWE-157

Protect  Against Unauthorized Access

SWE-158

Evaluate Software for Security Vulnerabilities

SWE-159

Verify and Validate Risk Mitigations

Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. 


Div
idtabs-5

5. Resources

refstable
 


toolstable
 


Div
idtabs-6

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.