Add capability to communicate chronology for CWE and Actions

[Chris-Turner-NIST]

User Story:

When using the Vulntology to describe a vulnerability I may desire the ability to communicate the order that certain things occur within a scenario. Specifically this is applicable to communicating CWEs and Actions. If there were properties that allowed me to establish a chain of events within these properties I could better represent a given scenario.

Goals:

Add properties to

Exploited Weakness (https://github.com/usnistgov/vulntology/blob/master/specification/values/exploited-weakness.md)
Actions (https://github.com/usnistgov/vulntology/blob/master/specification/objects/action.md)
Barriers (https://github.com/usnistgov/vulntology/blob/master/specification/objects/barrier.md)
Known Chains (https://github.com/usnistgov/vulntology/blob/master/specification/objects/vulnerability.md)
That communicates a sequence of events (precedes/follows) between sister objects.

Dependencies:

both of these reference the same concept so a unified approach would be mandatory

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that addresses the goals of this User Story. This issue is referenced in the PR. If the PR only partially addresses a given User Story, the specific goals addressed are identified in the PR.
• Properties are optional once more than one of the parent object exist (multiple CWEs and/or multiple Actions) within a single scenario
• Add example use of this to the JSON and Human Readable examples

[david-waltermire]

We need to consider how to support sequencing for weaknesses, actions, barriers, etc. It would be ideal to come up with a common pattern that could be used in all cases. This will take some more significant design work than this issue indicates, but would greatly enhance the expressiveness of the vulntology.

@Chris-Turner-NIST We should set aside some time to design a way forward.

[david-waltermire]

Vulntology Sequencing Requirements

Scope

Support sequencing capability for:

• Barriers
• Weaknesses
• Actions
• Known Chains (possibly different case since we only want direct hops)

Requirements

1. Need to express options (e.g., A or B)
2. Need to express sequencing (ordering/preconditions) (e.g., A then B)
3. Need to express transitions (cause-effect/outcomes) (e.g., A leads to B)

Note: An array can provide for sequencing, but does not convey conditions or outcomes.

Example

> expresses allowed transition (i.e., A > B is A allows B)
= expresses a requirement (i.e., A = B is B requires A)
() indicates a combination of pre-conditions (i.e., (A B) is A then B)

• CWE-A > CWE-B => CWE-C
• CWE-B => CWE-C
• (CWE-A > CWE-B) => CWE-D > CWE-E

can be expressed as:

YAMLish logical structure:

  A:
     allows: B
     [other data]
  B:
    [other data]
    allows: C (optional)
    allows: D (optional)
  C:
    requires: B (implies B allows C)
    [other data]
  
  D:
    precondition-1:
      requires: A  (implies A must come before B?)
      requires: B (implies B allows D)
    [other data]

JSONish logical structure

{
  "A": {
    "allows": [ "B" ]
  },
  "B": {
    "allows": [ "C", "D" ]
  }
  "C": {
    "requires": [ "B" ]
  }
  "D": {
    "pre-condition": {
      "requires": [ "A", "B" ]
    },
    "allows": [ "E" ]
  }
   
}

A rough example of how this might look in practice.

{
  "actions": [ {
    "id": "action1",
    "allows": "action2"
  },
  {
    "id": "action2",
    "requires": "action1"
  }
  ]
}