bannerb

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

SWE-158 - Evaluate Software for Security Vulnerabilities

1. Requirements

3.16.6 The project manager shall ensure that the space flight software systems are assessed for possible security vulnerabilities and weaknesses.

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

Space flight software systems are assessed for software and communication security vulnerabilities and weaknesses to ensure such issues are known and managed during the software development life cycle and to ensure the associated risk is also identified and managed.

3. Guidance

The project manager is required to have and implement a Project Protection Plan for their system.  The software development organization is responsible for implementing mitigations to address the identified software and communication security vulnerabilities and weaknesses for space flight software systems.  It is expected that requirements for these mitigations are generated as security requirements and that those security requirements affecting software are included in the software requirements specification (see SRS).  These security requirements are then flowed down and implemented in the design and code and tested by the software development team.

A select group of personnel from the Agency's Space Protection Working Group (SPWG) actually writes Project Protection Plans and Program Threat Summaries.  Program Threat Summaries for NASA are based on similar standardized documents written for national security space systems. 

Project managers are to assess their software systems against identified risks (see SWE-156) and agreed to viable security vulnerabilities and weaknesses to confirm that changes required to mitigate or eliminate identified security risks have been implemented in the completed products.

Project managers work with software assurance and other software security experts, including the Information System Security Officer (ISSO), to have software vulnerability assessments performed.  Assessments, conducted by software security specialists, may require input from software developers.  The results of these assessments may require updates to software requirements to be sure that identified vulnerabilities that can be mitigated in software are properly addressed.  It is important for projects to not introduce vulnerabilities and weaknesses by coding for functionality and performance at the expense of security.

Security assessments are performed throughout the project life cycle rather than being performed at the end of the life cycle when it is costly to correct programming errors, bugs, and other identified vulnerabilities.  “Continuous test and evaluation of security attributes of systems is an important part of testing as it allows software developers to identify and address vulnerabilities as part of the system architecture and design.” 485 Each project establishes assessment guidelines and frequency suitable to its development life cycle or follows any existing Center guidelines, tailored appropriately for the project.

Quality, security-related vulnerability assessments/analyses:

  • Include newly developed code and, to the extent possible, off-the-shelf (OTS), open source, and reused code.
  • May focus on 484:
    • Code that runs by default.
    • Code that runs in elevated context.
    • Code connected to a globally accessible network interface.
    • Code written in a language whose features facilitate building in vulnerabilities.
    • Code with a history of vulnerabilities.
    • Code that handles sensitive data.
    • Complex code.
    • Code that changes frequently.
  • Assess for bugs, programming errors, and potential failures.
  • Confirm, to some acceptable level of rigor, that software does not do what it is not supposed to do
  • Assess the impact and likelihood of vulnerability exploitation.
  • May check for adherence to secure architecture, design, coding standards, including the use of secure coding practices (may be difficult to do for OTS software).
  • May use automated security static code analysis as well as coding standard static analysis.

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-027

Use of Commercial, Government, and Legacy Software

SWE-135

Static Analysis

SWE-154

Identify Security Risks

SWE-155

Implement Risk Mitigations

SWE-156

Evaluate Systems for Security Risks

SWE-157

Protect  Against Unauthorized Access

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.

Tool nameTypeOwner/SourceLinkDescriptionUser

Vmware

COTS

Vmware, Inc.

http://www.vmware.com/ ...

VMware suite of products to virtualize infrastructure for ground systems/networks. (Includes (vCloud, workstation, ESXi, vSphere.)

IV&V

Sonatype

COTS

Sonatype, Inc.

https://www.sonatype.com/ ...

Software supply chain management where it scans for known vulnerabilities when using open source software (for ground systems/networks).

IV&V

OWASP Dependency Check

Open Source

Open Web Application Security Project (OWASP)

https://www.owasp.org/index.php/MainPage ...

Software supply chain management where it scans for known vulnerabilities when using open source software (for ground systems/networks).

IV&V

Metaspolit Express/Pro

COTS

Rapid7

https://www.metasploit.com/ ...

Penetration testing for ground systems/networks.

IV&V

Fortify

COTS

MicroFocus

https://software.microfocus.com/en-us/products/static-code-analysis-sast/overview ...

MicroFocus Fortify is a static code analysis tool that is used to scan software for security vulnerabilities. Fortify is used extensively through the DoD community. GSFC uses Fortify for its DOD Clients. The NASA OCIO procured an enterprise license of Fortify. Please contact the SOC for more information soc@nasa.gov.

GSFC

BlackDuck Hub

COTS

Black Duck Software, Inc.

https://www.blackducksoftware.com/products/hub ...

Software supply chain management where it scans for known vulnerabilities when using open source software (for ground systems/networks). A Complete Open Source Management Solution - Fully discover all open source in your code - Map components to known vulnerabilities - Identify license compliance and component quality risks - Set and enforce open source policies - Integrate open source management into your DevOps environment - Monitor and alert when new threats are reported

IV&V

AppScan®

COTS

IBM®

https://www.ibm.com/us-en/marketplace/appscan-standard ...

IBM Security AppScan Standard - IBM Security AppScan Standard protects against web application attacks and expensive data breaches by automating application security vulnerability testing. Source and Enterprise versions also available

JPL

 

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.

  • No labels