- Print
- DarkLight
Scenarios
- Find and Acquire Component Definitions
- Deliver an SSP With Attachments
- Add a New Attachment to an SSP
- Retrieve an SSP With Attachments
All scenarios use https://example.com
as the root URL for the server.
Find and Acquire Component Definitions
A System Security Plan (SSP) author has elected to use Keycloak for identity management and wishes to include information about Keycloak in their SSP.
Client: OSCAL-based SSP Authoring Tool
Server: OSCAL Content Registry
- Client queries the OSCAL Content Registry for a list of available component definition files.
- Client -> Server:
GET https://example.com/component-definition
- Server -> Client: List of component definitions that includes
file-id
,title
,version
,last-modified
and other metadata (JSON)
- Client -> Server:
- Client presents list of component definitions to the SSP author.
- Author selects Keycloak component definition.
- Client imports the component definition file for Keycloak in XML format.
- Client -> Server:
GET https://example.com/component-definition/abc-123
(HTTP Header:Accept: application/xml
) - Server -> Client:
oscal_keycloak_component.xml
(delivers the OSCAL Component Definition in XML format)
- Client -> Server:
Deliver an SSP With Attachments
An SSP author delivers an OSCAL-based SSP to the ISSO's office for adjudication. The SSP is in OSCAL JSON format. It includes a boundary diagram attachment (Boundary.pdf
) in the resources
with a UUID value of 2ba7db9b-4603-4574-8eb2-93a447dbcd29
l
Client: OSCAL-based SSP Authoring Tool
Server: CISO's GRC Repository
- Client sends the SSP to the CISO's GRC Repository
- Client -> Server:
POST https://example.com/system-security-plan
(HTTP Headers: Access Token,Content-type: application/json
)(Payload:oscal_ssp.json
) - Server verifies the access token was create-new permissions.
- Server assigns a unique file identifier (
"file-id": "ssp-8675309"
). - Server stores the SSP and associates the file-id with it
- Server -> Client: SSP list entry that includes
file-id
,title
,version
,last-modified
and other metadata (JSON).
- Client -> Server:
- Client uploads SSP attachments.
- Client -> Server:
PUT https://example.com/system-security-plan/ssp-8675309/attachment/2ba7db9b-4603-4574-8eb2-93a447dbcd29
(Boundary.pdf
is the payload)(HTTP Header: Access Token) - Server verifies the access token has write permissions to the SSP.
- Server stores the attachment and revises the
rlink/href
value tohttps://example.com/system-security-plan/ssp-8675309/attachment/2ba7db9b-4603-4574-8eb2-93a447dbcd29
- Server returns status 200 with no payload.
- Client -> Server:
- Client repeats step #2 as necessary for each additional attachment defined int the SSP's back-matter.
Add a New Attachment to an SSP
An SSP author wishes to add a new attachment to the SSP delivered above. The new attachment is a configuration management plan (CM_plan.pdf
) that is not yet defined in the SSP's back-matter. The author wishes to include a title, version, date, and attachment type in the resource entry.
Client: OSCAL-based SSP Authoring Tool
Server: CISO's GRC Repository
- Client sends SSP attachment.
- Client -> Server:
POST https://example.com/system-security-plan/{file-id}/attachment
(Payload:CM_plan.pdf
) - Server generates a v4 or v5 UUID value for the attachment. (
e6b48e1e-b94d-4fbf-9599-1becd4b11144
) - Server stores the attachment and associates the UUID with the attachment.
- Server creates a new back-matter resource in the SSP and assigns it the same UUID value.
- Server -> Client: The newly created resource entry (JSON), which includes the UUID value above.
- Client -> Server:
- Client sends updated resource content with title, properties, and remarks.
- Client -> Server:
PUT https://example.com/system-security-plan/ssp-8675309/attachment/e6b48e1e-b94d-4fbf-9599-1becd4b11144/resource
(Payload: updated resource content)(JSON)
- Client -> Server:
Retrieve an SSP With Attachments
An Assessment Lead needs to retrieve an OSCAL-based SSP from the ISSO office's GRC repository. The SSP includes a boundary diagram attachment (Boundary.pdf
) in the OSCAL-SSP's resources
:
Client: OSCAL-based Assessment Planning Tool
Server: CISO's GRC Repository
- The assessor's tool retrieves a list of SSPs from the CISO's GRC Repository:
- Client -> Server:
GET https://example.com/system-security-plan
(HTTP Header: Access Token) - Server compiles list of SSPs to which the assessor has access based on access token.
- Server -> Client: List of accessible SSPs, which includes
file-id
,title
,version
,last-modified
and other metadata (JSON).
- Client -> Server:
- Client presents list of SSPs to the assessor.
- Assessor selects the relevant SSP.
- Client imports the SSP in YAML format.
- Client -> Server:
GET https://example.com/system-security-plan/ssp-8675309
(HTTP Headers: Access Token,Accept: application/yaml
) - Server verifies the access token has read-permission for the SSP
- Server -> Client:
oscal_system-security-plan.yaml
- Client -> Server:
- Assessor reviews SSP and wishes to see the boundary diagram.
- Client extracts
rlink/href
value from the OSCAL SSP. - Client -> Server:
GET https://example.com/system-security-plan/ssp-8675309/attachment/2ba7db9b-4603-4574-8eb2-93a447dbcd29
(HTTP Header: Access Token) - Server verifies the access token has read permission for the SSP
- Server -> Client:
Boundary.pdf
- Client extracts