bannerb

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

SWE-156 - Evaluate Systems for Security Risks

1. Requirements

3.16.4 The project manager shall ensure and record that all systems including space flight software are evaluated for security risks, including risks posed by the use of COTS, GOTS, MOTS, Open Source, and reused software.

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

The purpose of security risk management is to identify potential software security problems before they occur so that software security risk handling activities can be planned and invoked as needed across the life of the space flight software product or project. 

3. Guidance

The purpose of this requirement is:

  1. To ensure that the space flight software development organizations work with the Project Protection Plan to evaluate all software security risks identified in the Project Protection Plan.
  2. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is evaluated for software security vulnerabilities.
  3. To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is factored into the planning process for the Project Protection Plan.
  4. To ensure that the software security risk identification process is performed throughout the software development lifecycle.

The flight software development team, the IT security experts, the project office, and the system engineering team all work together to ensure that all systems that include space flight software are evaluated for security risks.

The risk and implementation approaches are defined and documented in the Project Protection Plan. The space flight software development team is responsible for implementing any space flight software mitigations identified in the Project Protection Plan. Ideally this should be done as early in the requirements and design cycle as possible. The assessment should also be done any time the development project adds or changes space flight software components to ensure that the project does not introduce any additional or new software security risks.

The space flight software protections identified in the Project Protection Plan should be implemented and verified by the software development organization just like any other requirement or hazard analysis migration. The requirements and design for the space flight software security features should be designed and tested just like any other functional requirement.

Any COTS, GOTS, MOTS, Open Source, and reused software components used in the space flight software should be screened by an IT security process and software security static analysis tools.

The secure coding Community of Practice, accessible to NASA users from the NASA Engineering Network (NEN), is a good source for tools and information on secure coding practices.

The frequency of the space flight software security analyses should be included in the Project Protection Plan.

Systems that include space flight software are not exempt from security related risks or attacks. Evaluating systems that include space flight software for security risks allow projects and programs to identify and plan mitigations to reduce or eliminate the affect such risks have on the security of the overall mission.

Per the Project Protection Plans description file on the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, the Protection Plan is a classified document that identifies both hostile and environmental threats to a NASA space system and draws attention to high risk system vulnerabilities (in particular, critical nodes and single points-of-failure). High risk vulnerabilities can be mitigated either through system design or via enhanced security. The Security Plan should discuss how institutional security providers implement risk mitigation techniques to protect the critical nodes (as identified in the Protection Plan) of a space system's ground and information segments.

Off-the-shelf (OTS) software, open source and reused software introduce additional potential security issues when used in a project, so careful consideration and assessment is needed to determine the effect those types of software have on the overall security of the system.

Per the FAQ section of the Community of Practice for Space Asset Protection accessible to NASA users from the NEN, the responsibility for space asset protection is “through each project's Chief Engineer or Mission Systems Engineer (MSEs)... Once a project's spacecraft is launched and operational a systems engineer from the flight operations team will take on protection responsibilities and interface with the

Space Protection Working Group (SPWG)”.

Project managers typically work with independent risk assessors, such as NASA IV&V Program’s Safety and Mission Assurance (SMA) Support Office (SSO) Information Assurance Program, and other software security experts, including the Information System Security Officer (ISSO), to have system security risk assessments or analyses performed, recording in project records that the assessments were completed and appropriate mitigations incorporated into project plans. Assessments of the space flight software components may require input from the developers to help the assessment team perform the security risk analysis.

System security risk assessments:

  • Cover the entire system.
  • Inspect requirements for security-related details.
  • Assess for vulnerabilities and potential failures in system components, including software.
  • Measure the impact of the security risk on the system.
  • May include penetration tests.

Useful sources for software security risk assessments include:

  • System level risk assessment reports (contact the ISSO).
  • Vulnerability assessment plans (contact the ISSO).
  • Output of static code analysis.

Security risk assessments occur “at the very beginning of the project and continue with each program review. It is also important to assess risks whenever requirements change and when the potential for new vulnerabilities and new threats are introduced" 494 .

For new systems, COTS, GOTS, MOTS, open source, and reused software, assessments for security risks are performed prior to use of the software in the flight software system, e.g., be part of any trade studies used to determine whether to incorporate OTS, open source or reused software.  The results of the assessment are one factor in determining whether to use the evaluated software as part of the project.

It is important to not rely completely on system testing to verify software security requirements.  System tests are not typically developed from the beginning to include the proper and full set of test cases to verify software security requirements.  Verification of software security requirements should occur, like all software verification activities, throughout the life cycle.

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

SWE-027

Use of Commercial, Government, and Legacy Software

SWE-154

Identify Security Risks

SWE-155

Implement Risk Mitigations

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.

Tool nameTypeOwner/SourceLinkDescriptionUser

Wireshark

Open Source

Wireshark Foundation

https://www.wireshark.org ...

Wireshark is the world's foremost network protocol analyzer. It lets you see what's happening on your network at a microscopic level.

LaRC, KSC, IV&V

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

Redseal Networks

COTS

RedSeal, Inc

https://redseal.co/ ...

Models networks and does threat visualization 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

Network Miner

COTS

Netresec AB

http://www.netresec.com/?page=NetworkMiner ...

Network packet capture and analysis for ground systems/networks.

IV&V

Nessus®

COTS

Tenable Network Security

https://www.tenable.com/products/nessus-vulnerability-scanner ...

Vulnerability Scanner for ground systems/networks.

IV&V

Metaspolit Express/Pro

COTS

Rapid7

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

Penetration testing for ground systems/networks.

IV&V

Kali Linux

Open Source

Kali

https://www.kali.org/ ...

Penetration testing tool for ground systems/networks.

IV&V

Fortify WebInspect

COTS

MicroFocus

https://software.microfocus.com/en-us/products/webinspect-dynamic-analysis-dast/overview ...

Dynamic Application Security Testing Software - Find and prioritize web application vulnerabilities. Automate dynamic web application testing across a software portfolio.

IV&V

Burp Suite Pro

COTS

PortSwigger Ltd.

https://portswigger.net/burp/ ...

Web application penetration testing for ground systems/networks.

IV&V

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