bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-155 - Implement Risk Mitigations

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
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

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:

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

4. Small Projects

No additional guidance is available for small projects. 


5. Resources


5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

 


6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.

  • No labels