bannerb

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Include Page
2B-Page Warning
2B-Page Warning

Tabsetup
1. The Requirement
1. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
Div
idtabs-1

1. Requirements

3.16.7 The project manager shall verify and validate the required software security risk mitigations to ensure that security objectives identified in the Project Protection Plan for space flight software are satisfied in their implementation.

1.1 Notes

Include assessments for security vulnerabilities during Peer Review/Inspections of software requirements and design and undergo automated security static analysis as well as coding standard static analyses of software code to find potential security vulnerabilities.

1.2 Applicability Across Classes

 

Applicable b
a1
b1
csc1
c1
d0
dsc0
e0
f0
g0
h0

Div
idtabs-2

2. Rationale

Mitigations identified to address security risks need to be confirmed as appropriate and adequate.  Software verification and validation (V&V) processes are used to determine whether the software security risk mitigations, as planned and implemented, satisfy their intended use to address security risks in space flight software.  The results of V&V activities serve as documented assurance that the correct mitigations were identified, implemented, and will reduce to an acceptable level or eliminate known software security risks.

Div
idtabs-3

3. Guidance

Project managers ensure that software security risk mitigations called out in the Project Protection Plan for space flight software are verified and validated as part of the project’s development activities. The verification and validation (V&V) of these mitigations are included in the project’s planned V&V activities, reflected in the project’s V&V plans, and carried out throughout the project life cycle.

When planning V&V for required software security risk mitigations, the following are useful source documents within the project and from the Information System Security Officer (ISSO):

  • System level risk assessment report.
  • Plan of actions and milestones (POA&M). (POA&M serves as the NASA management tool to address, report, resolve, and remediate security-related weaknesses, both at the information system-level and program-level).

Examples of the type of information found in these documents relevant to planning V&V for software security risk mitigations include:

  • Vulnerabilities discovered during the security impact analysis or security control monitoring.
  • Corrective efforts associated with the mitigation of identified security weaknesses.
  • The NASA goalfor vulnerability remediation identified during vulnerability scanning.
    • To have all vulnerabilities categorized as high remediated within five working days of discovery.
    • To have all vulnerabilities categorized as moderate remediated within thirty working days of discovery.
    • To have all vulnerabilities categorized as low remediated within sixty working days of discovery.

Specific to software security risk mitigations, V&V activities include, at a minimum:

  • Security vulnerability checks during peer review/inspections of software requirements, design, code (may require updates to existing peer review/inspection checklists).
  • Automated security static code analysis.
  • Coding standard static analysis.

Additionally, repeating previous assessments for software security vulnerabilities could be used to confirm that the previously identified vulnerabilities and weaknesses have been addressed and no new vulnerabilities introduced or discovered.  To keep costs down and prevent propagation of risks through the project, mitigations are to be put in place as early as possible and verified throughout the life cycle.

Note

Project Protection Plans are classified documents.  Per the FAQ 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.

Note

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 and verification and validation may be found in the following related requirements in this Handbook:

SWE-028

Verification Planning

SWE-029

Validation Planning

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

Evaluate Software for Security Vulnerabilities

Div
idtabs-4

4. Small Projects

No additional guidance is available for small projects. 

Div
idtabs-5

5. Resources

refstable
 


toolstable
 

Div
idtabs-6

6. Lessons Learned

No Lessons Learned have currently been identified for this requirement.