bannerd


SWE-210 - Detection of Adversarial Actions

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

SWE-210 - Used first in NPR 7150.2D

RevSWE Statement
A


Difference between A and B

N/A

B

RESERVED

Difference between B and C

N/A

C


Difference between C and DFirst use of this SWE
D

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.3 Applicability Across Classes

Class

     A      

     B      

     C      

     D      

     E      

     F      

Applicable?

   

   

   

   

   

   

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, 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software

3.1 Detection of Adversarial Actions  PAT-012

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

PAT-012 - Detection of Adversarial Actions

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

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

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

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

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.

 

5.3 Process Asset Templates

SWE-210 Process Asset Templates
Click on a link to download a usable copy of the template. 

6. Lessons Learned

There are currently no Lessons Learned identified for this requirement.

7. Software Assurance

SWE-210 - Detection of Adversarial Actions
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.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Confirm that the software requirements exist for collecting, reporting, and storing data relating to the detection of adversarial actions.

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.

    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:

  • No labels