bannerc
SWE-155 - Implement Risk Mitigations

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

1.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Sometimes Safety Critical; E - F = Never Safety Critical.

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:

  1. Run a static analysis tool to verify that the source code conforms to a secure coding rule set by running a static analysis tool
  2. Run a static analysis tool to assess the cybersecurity vulnerabilities and weaknesses in the source code, use a tool that assesses the known CWEs 
  3. Address the results of the static analysis tools used to assess the cybersecurity vulnerabilities and weaknesses in the source code
  4. Determine that the software requirements, software design, and code meet the identified cybersecurity vulnerabilities requirements from the project assessment
  5. 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 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:

4. Small Projects

No additional guidance is available for small projects. 


5. Resources

5.1 References


5.2 Tools


Unable to render {include} The included page could not be found.


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

  1. 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 addresses the engineering and assurance identified cybersecurity vulnerabilities and weaknesses. 

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


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.

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 664 site for more information (NASA access only).



  • No labels