See edit history of this section
Post feedback on this section
- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
1. Requirements
3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.
1.1 Notes
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 History
1.3 Applicability Across Classes
Class A B C D E F Applicable?
Key: - Applicable | - Not Applicable
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
3.1 Purpose Of This Requirement
The purpose of this requirement is:
- To ensure that the software development organizations work with the Project Protection Plan 362 to evaluate all software security risks identified in the Project Protection Plan, System Security Plan, and related documents
- To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is evaluated for software security vulnerabilities.
- 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.
- To ensure that the cyber security assessment (including risks) is performed throughout the software development life cycle.
- Assess the software requirements to determine if the software requirements include software cybersecurity requirements per the Project Protection Plan, per NASA AA Directive on Robotic Spacecraft Command (if applicable), and per the SPACE SYSTEM PROTECTION STANDARD, NASA-STD-1006 663
The 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 software are evaluated for security risks.
See also SWE-147 - Specify Reusability Requirements,
3.2 Project Protection Plan
The risk and risk mitigation implementation approaches are defined and documented in the Project Protection Plan. The software development team is responsible for implementing any 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 software components to ensure that the project does not introduce any additional or new software security risks.
The software protections identified in the Project Protection Plan and/or the System Security 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 software security features should be designed and tested just like any other requirement.
Any COTS, GOTS, MOTS, Open Source, and reused software components used in the software should be screened by IT security and software security static analysis tools.
See also Topic 8.08 - COTS Software Safety Considerations.
3.3 Secure Coding Practices
The Software Security Community of Practice 664, accessible to NASA users from the NASA Engineering Network (NEN), is a good source for secure coding tools and practices.
3.4 Software Security Analyses
The frequency of the software security analyses should be included in the Project Protection Plan and/or the System Security 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 allows projects and programs to identify and plan mitigations to reduce or eliminate the effect such risks have on the security of the overall mission.
Per the Project Protection Plans description file on the Community of Practice for Mission Resilience and Protection Program (MRPP) accessible to NASA users from the NEN, the Protection Plan is a classified document that identifies both hostile and environmental threats to NASA systems (software, network, hardware, ...) 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 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 space, 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.
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).
3.5 Independent Risk Assessors
Project managers typically work with independent risk assessors, such as the Information System Security Officer (ISSO) and other software security experts, 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 flight and ground software components may require input from the developers to help the assessment team perform the security risk analysis.
System security risk assessments should:
- Cover the entire mission 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).
- The 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. See also SWE-154 - Identify Security Risks, 7.22 - Space Security: Best Practices Guide
For new systems, COTS, GOTS, MOTS, open-source, and reused software, assessments for security risks are performed before the use of the software in the flight and ground 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. See also SWE-027 - Use of Commercial, Government, and Legacy Software.
3.6 System Testing and Security Requirements
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. See also SWE-157 - Protect Against Unauthorized Access and SWE-159 - Verify and Validate Risk Mitigations and Topic 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software, SWE-191 - Software Regression Testing, SWE-205 - Determination of Safety-Critical Software,
3.7 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
3.8 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
SPAN Links |
---|
4. Small Projects
The acceptable risk posture for smaller projects or mission class will vary depending on the project type (e.g. CubeSat vs large observatory) and should be considered. The cyber security assessment needs to be performed and risks identified.
5. Resources
5.1 References
- (SWEREF-004) Software Engineering Institute, Carnegie Mellon University. Retrieved September 27, 2016 from https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
- (SWEREF-060) NASA Engineering Network. Accessed September, 2016. Formerly Space Asset Protection, The NASA Engineering Network (NEN) is accessible only to NASA users.
- (SWEREF-064) NIST SP 800-27, Revision A.
- (SWEREF-065) NIST SP 800-64 Revision 2.
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-273) NASA SP-2016-6105 Rev2,
- (SWEREF-362) Mission Resilience and Protection key document, Available in NEN, Mission Resilience and Protection Community of Practice. Formerly "Space Asset Protection", Updated Jan 23, 2023
- (SWEREF-494) Douglas A. Ashbaugh, Software Engineering Services (2006). Retrieved November 11, 2014 from http://www.crosstalkonline.org/storage/issue-archives/2006/200609/200609-Ashbaugh.pdf.
- (SWEREF-495) Arlene F. Minkiewicz, PRICE Systems (2005). Retrieved November 11, 2014 from http://www.crosstalkonline.org/storage/issue-archives/2005/200511/200511-Minkiewicz.pdf.
- (SWEREF-496) C. Warren Axelrod, Delta Risk (2014). Retrieved November 11, 2014 from http://www.crosstalkonline.org/storage/issue-archives/2014/201403/201403-Axelrod.pdf
- (SWEREF-663) NASA-STD-1006, Approved: 2019-10-29, Office of the NASA Chief Engineer
- (SWEREF-664) OCE site in NASA Engineering Network, Portal that houses information for software developers to develop code in a secure fashion, Formerly known as "Secure Coding"
5.2 Tools
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
6.1 NASA Lessons Learned
No Lessons Learned have currently been identified for this requirement.
6.2 Other Lessons Learned
No other Lessons Learned have currently been identified for this requirement.
7. Software Assurance
7.1 Tasking for Software Assurance
1. Confirm the project has performed a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.
7.2 Software Assurance Products
- List of findings from software cybersecurity assessments.
Objective Evidence
Evidence of confirmation that the project has completed a Threat Summary and has a Project Protection Plans (PPP).
7.3 Metrics
- # of Risks identified in each life cycle phase (Open, Closed).
- # of Risks by Severity (e.g., red, yellow, green) over time.
- # of Risks with mitigation plans vs. total # of Risks
- # of Risks trending up over time.
- # of Risks trending down over time.
- # of Cybersecurity Risks identified (Open, Closed, Severity).
- # of Cybersecurity Risks with Mitigations vs. # of Cybersecurity Risks identified
See also Topic 8.18 - SA Suggested Metrics.
7.4 Guidance
Look at the secure coding 664 information (NASA only link).
- Confirm the project performed a software cybersecurity assessment on the software components per the Agency security policies and the project requirements.
The purpose of this requirement is:
- To ensure that the software development organizations work with the Project Protection Plan 362 to evaluate all software security risks identified in the Project Protection Plan, System Security Plan, and related documents.
- To ensure that the use of any COTS, GOTS, MOTS, Open Source, and reused software is evaluated for software security vulnerabilities.
- 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.
- To ensure that the cyber security assessment (including risks) is performed throughout the software development life cycle.
- Assess the software requirements to determine if the software requirements include software cybersecurity requirements per the Project Protection Plan, per NASA AA Directive on Robotic Spacecraft Command (if applicable), and per the SPACE SYSTEM PROTECTION STANDARD, NASA-STD-1006 663.
NPR 7120.5E 082 requires all flight programs/projects to develop Threat Summaries and Project Protection Plans (PPP). The PPP serves as a starting point for mission protection planning and is linked to consistent high threat and risk issues. The Project Protection Plans incorporate results of the Candidate Protection Strategies (CPS) Asset Protection analysis, including any requisite requirement tailoring.
2. Confirm that the project assessment includes risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.
Quality, security-related vulnerability assessments/analyses on COTS, GOTS, MOTS, OSS, or reused software components:
- May focus on 484:
- Code that runs by default.
- Code that runs in an elevated context.
- Code connected to a globally accessible network interface.
- Code is written in a language whose features facilitate addressing 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).
- Use automated security static code analysis as well as coding standard static analysis.
3. Confirm that the cybersecurity risks and associated mitigations have been identified to satisfy the conditions in SWE-154 - Identify Security Risks.
Work with Information System Security Officer (ISSO) to assure that all the cybersecurity risks and mitigations identified in space and ground systems have been identified and confirm that the appropriate requirements to address these risks and their mitigations have been added to the requirements. Review the guidance in SWE-154 and check to see that those conditions are satisfied. See also Topic 7.22 - Space Security: Best Practices Guide.
7.5 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook: