SWE-155 - Implement Risk Mitigations

Web Resources

See edit history of this section

Post feedback on this section

Section Labels:

Unknown macro: {page-info}

1. The Requirement
2. Rationale
3. Guidance
4. Small Projects
5. Resources
6. Lessons Learned
7. Software Assurance

1. Requirements

3.11.6 The project manager shall address identified cybersecurity vulnerabilities and weaknesses.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

Click here to view the history of this requirement: SWE-155 History

SWE-155 Last used in rev NPR 7150.2C

Rev	SWE Statement
A
Difference between A and B	NEW
B	3.16.3 The project manager shall implement the identified software security risk mitigations addressed in the Project Protection Plan.
Difference between B and C	Changed "implement" to "address"; Changed focus of requirement from risk mitigations to cybersecurity vulnerabilities and weaknesses; Removed the requirement for them to be in the Project Protection Plan.
C	3.11.6 The project manager shall address identified cybersecurity vulnerabilities and weaknesses.
Difference between C and D	Retired Functions addressed by SWEs 154, 156, 157. 159
D

1.3 Applicability Across Classes

Class	A	B	C	D	E	F
Applicable?

Key: - Applicable | - Not Applicable

2. Rationale

Software defects with security ramifications can leave systems compromised and open to attack. Implementing appropriately 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

The engineering team and the project have responsibilities to address any identified cybersecurity vulnerabilities and weaknesses identified in the software requirements, design, code. Confirm that the requirements associated with the identified cybersecurity vulnerabilities and weaknesses have been tested or are planned to be tested. The engineering team and the project should run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code and check to see that the findings from the static analysis tool have been addressed by the team.

Recommended guidance for the engineering team:

Run a static analysis tool to verify that the source code conforms to a secure coding rule set by running a static analysis tool
Run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code, use a tool that assesses the known CWEs
Address the results of the static analysis tools used to assess the cybersecurity vulnerabilities and weaknesses in the source code
Determine that the software requirements, software design, and code meet the identified cybersecurity vulnerabilities requirements from the project assessment
Use the NIST criteria to assess the software development environment

A method of identifying weaknesses and vulnerabilities is to use the National Vulnerability database from NIST that is the U.S. government repository of standards-based vulnerability data. Software weaknesses can be identified using Common Weakness Enumeration (CWE) - a dictionary created by MITRE.

See the secure coding site for more information https://nen.nasa.gov/web/coding (NASA access only)

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

Click here to view master references table.

(SWEREF-064)
Engineering Principles for Information Technology Security (A Baseline for Achieving Security),
NIST SP 800-27, Revision A.
(SWEREF-065)
Security Considerations in the System Development Life Cycle,
NIST SP 800-64 Revision 2.
(SWEREF-082)
NASA Space Flight Program and Project Management Requirements
NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
(SWEREF-273)
NASA Systems Engineering Handbook
NASA SP-2016-6105 Rev2,
(SWEREF-664)
Software Security
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

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

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

SWE-155 - Implement Risk Mitigations

3.11.6 The project manager shall address identified cybersecurity vulnerabilities and weaknesses.

7.1 Tasking for Software Assurance

Confirm that the project addresses the engineering and assurance identified cybersecurity vulnerabilities and weaknesses.

7.2 Software Assurance Products

None at this time

Objective Evidence

Evidence of confirmation that the project addressed the results from the static code analysis tool results for cybersecurity vulnerabilities and weaknesses.
Software problem reporting or defect tracking system results.

Definition of objective evidence

Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
Signatures on SA reviewed or witnessed products or activities, or
Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
- To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
- To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

- # of Cybersecurity vulnerabilities and weaknesses identified.
- # of Cybersecurity vulnerabilities and weaknesses (Open, Closed, Severity).
- Trending of Open vs. Closed over time.
- # of Cybersecurity vulnerabilities and weaknesses identified vs. # resolved during Implementation.
- # of Non-Conformances identified in Cybersecurity coding standard compliance (Open, Closed).
- # of Cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses.
- # of Cybersecurity mitigation implementations identified with associated test procedures vs. # of Cybersecurity mitigation implementations identified.
- Trends of Cybersecurity Non-Conformances over time.

7.4 Guidance

Confirm that the engineering team and the project have addressed any identified cybersecurity vulnerabilities and weaknesses in the software requirements, design, code. Check with the project to see where the lists of identified cybersecurity vulnerabilities are and compare these items with the approved changes in the CM system to see if the vulnerabilities listed have resulted in changes in requirements, design, or code. A static analyzer that checks for such vulnerabilities can be rerun to verify that no remaining vulnerabilities exist.

Confirm that the requirements associated with the identified cybersecurity vulnerabilities and weaknesses have been tested or are planned to be tested. Check to see if the engineering team and the project have run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code if so check to see that the findings from the static analysis tool have been addressed by the team. See the Software Assurance guidance for SWE-155 (this requirement) and SWE-158 to check that relevant static analysis results were addressed.