Example SSPs Using Actions
What are they?
OSCAL has the ability to encode metadata about each document instance. One type of metadata is an action, a metadata element that OSCAL-enabled software can use to encode a record of a type of action taken by one or more parties from one or more organizations. OSCAL is not prescriptive about what an action is. Currently, the minimal, default values for such an action are request-changes
and approval
. Any organization can create their own action type, but these examples will focus specifically on those minimal types.
You can find more in-depth information about all the details of an action in its XML documentation or JSON documentation.
How do you use actions between one or more parties within the same document?
When encoding actions in the metadata section of an OSCAL document, it is helpful to view interactions between one or more parties against unique versions of the document. A party or parties will, with their OSCAL-enabled software, modify the document they received with:
- an updated version ID
- a revision (this is optional, but added in these examples for clarity)
- action assembly and its
- action types
- date and time of of occurrence
- remarks with prose about the nature of the action
Below is a diagram of a notional example with a system security plan for a system in BigCorp. A BigCorp Information System Security Manager oversees the system for federal customers. A federal customer wants to see a copy of the system security plan for future use of BigCorp Example System in their environemnt. BigCorp requires the security manager to have an internal review with lawyers specialized in information technology security and compliance policies before public release to that customer. The diagram visualizes how the different members of BigCorp would use an OSCAL-enabled tool to facilitate the review process over multiple versions of the system security plan with actions.
In this directory, there are two example SSPs, representing snapshot-in-time versions of the SSP. The two extant revisions are when the Legal Department requested changes and when they approved (in the third and fourth revisions of the document). The first and second revisions by the Information System Security Manager are implied by the modifications in the SSP content as identified and action remarks.