1. Requirements

3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions.

1.1 Notes

Monitoring of key software observables (e.g., number of failed login attempts, performance changes, internal communication changes) is needed to detect adversarial actions that threaten mission success. When an adversarial action occurs, it should be reported. Raw event data should be further analyzed to determine whether an anomalous event represents an attack and if so, the nature of the attack.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

To provide the capability to monitor key software observables (e.g. number of failed login attempts, performance changes, internal communication changes) to detect adversarial actions that threaten mission success.

3. Guidance

It is important to understand the scope of what it means for software to resist adversity:

• What critical capabilities/services must the software continue to provide despite disruptions?
• What types of adversities can disrupt the delivery of these critical capabilities (i.e., what adverse events and conditions must the software be able to tolerate)?
• What are the types and levels of harm to what assets can cause these disruptions?

See also SWE-154 - Identify Security Risks, SWE-157 - Protect Against Unauthorized Access, Topic  8.04 - Additional Requirements Considerations for Use with Safety-Critical Software. 

3.1 Detection of Adversarial Actions  ^PAT-012

3.2 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.3 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

5.3 Process Asset Templates

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

7.2 Software Assurance Products.

• SA analysis of software volatility measures over time. 

  
  

  Objective Evidence

  • Evidence that confirmation of Task 1. has been completed, including identifying any risks or issues.
    
   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 requirements specified relating to detection of adversarial actions vs. # of requirements related to detection of adversarial actions actually implemented

See also Topic 8.18 - SA Suggested Metrics.

7.4 Guidance 

Confirm that the software requirements include requirements for detecting adversarial actions.  This should be done as a part of the software requirements assessment process.

See also 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software. 

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: