Create Examples of SSP Exports to Support Creation of Responsibility Model

[Compton-US]

User Story

As an OSCAL model developer, I need examples of the SSP model that contain content for export to a responsibility model based on #1336 and #1385.

Related Issues:

• Research use of a Customer Responsibility Matrix (CRM) model for control element content. #1336
• Map use case information to existing OSCAL model(s) and identify gaps. #1385

Goals

Produce XML examples of OSCAL SSP with export content.

Dependencies

No dependencies.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A gist is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[Compton-US]

Also consider the use case related to content provided through a component definition, and any requirements related to exports. This capability did not appear to be a part of the component definition model, but is likely needed.

[iMichaela]

@Compton-NIST
The SSP model provides :

control-implementation.implemented-requirement.by-component.export and
control-implementation.implemented-requirement.statement.by-component.export

where information would go at the component level, but there is no equivalent assembly providing this information in a component definition (CDef) to allow for information transfer into the SSP. Today, the information would be generated manually from unstructured information provided in a CDef by a vendor.
In our CDef example oscal-content/examples/component-definition/json/example-component-definition.json

"control-implementations": [
          {
            "uuid": "49f0b690-ed9f-4f32-aae0-625b77aa6d27",
            "source": "https://github.com/usnistgov/oscal-content/blob/master/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_MODERATE-baseline_profile.xml",
            "description": "MongoDB control implementations for NIST SP 800-53 revision 5.",
            "implemented-requirements": [
              {
                "uuid": "cf8338c5-fb6e-4593-a4a8-b3c4946ee2a0",
                "control-id": "sc-8.1",
                "description": "MongoDB supports TLS 1.x to encrypt data in transit, preventing unauthorized disclosure or changes to information during transmission. To implement TLS, set the PEMKeyFile option in the configuration /etc/mongod.conf to the certificate file's path and restart the the component."
              },
              {
                "uuid": "5227daf8-7a4b-4fe0-aea9-3547b7de2603",
                "control-id": "sa-4.9",
                "description": "Must ensure that MongoDB only listens for network connections on authorized interfaces by configuring the MongoDB configuration file to limit the services exposure to only the network interfaces on which MongoDB instances should listen for incoming connections."
              }
            ]

the information "To implement TLS, set the PEMKeyFile option in the configuration /etc/mongod.conf to the certificate file's path and restart the the component." - please scroll to the right to see it - qualifies for CRM information type. If someone is putting together a system for others to use (cloud service) that has a mongoDB component, will have to manually include this information in the export assembly.

[aj-stein-nist]

Chris is out of the office today, so I will preemptively move this to next sprint and we can sync up later. @Compton-NIST: when you return, let's sync up and determine if this is achievable as-is for the current sprint, needs changes, et cetera.

[aj-stein-nist]

@Compton-NIST, howdy. Can you summarize where you are at with this story and how it pertains to the larger CRM epic? I will likely unassign this from the current sprint, but I would like to catch up on this effort when you have a moment.

[iMichaela]

@Compton-NIST and @aj-stein-nist - can we have a meeting this week (virtual is OK) to discuss this issue, the Feb OSCAL DEFINE meeting and possible relation to this issue and the Feb RFC we want to send? Thank you.

[aj-stein-nist]

@Compton-NIST and @aj-stein-nist - can we have a meeting this week (virtual is OK) to discuss this issue, the Feb OSCAL DEFINE meeting and possible relation to this issue and the Feb RFC we want to send? Thank you.

We can meet after the fact, but I would still like a sitrep in a comment in the issue on the interim later this week. Thanks.

[iMichaela]

We can meet after the fact, but I would still like a sitrep in a comment in the issue on the interim later this week. Thanks.

Absolutely! It si important to have a sitrep here.

[Compton-US]

@iMichaela and @aj-stein-nist

I am attaching the handout from the model review, where I covered an example for our scenario 1 use case (fully inherited control). Based upon feedback from the community there was a desire to fully discuss, address and explore this scenario before moving on to the shared responsibility use case.

• Generally, I focused on the use of the export assembly, and modifications necessary to support all elements that would be required/desired for the CRM model. This would ensure a clear separation between what is intended to be shared beyond the document, and what is not.
• I do have additional content I have not shared which explores the format of the CRM, but it is more of a conversation starter than a specification for the entire model. There is also a question whether CRM needs an independent model if it is primarily made of the same assemblies as the SSP, just with a more limited scope. (Trying to keep it short, but similar in concept to profile resolution with catalogs)
• Due to our efforts around the program, and the lack of an adequate forum/capacity to engage the community in more depth on this topic, it has been on hold. It needs to be put on the research track.

Handout - OSCAL Model Responsibility Research 2022-10-28.pdf

[iMichaela]

• There is also a question whether CRM needs an independent model if it is primarily made of the same assemblies as the SSP, just with a more limited scope. (Trying to keep it short, but similar in concept to profile resolution with catalogs)

@Compton-NIST - Thank you for the update. Using the SSP model to convey the CRM information is an interesting idea. Curious to learn how you think the system-characteristics (& its mandatory assemblies) should be addressed. In particular authorization-boundary which is not shareable information. An earlier thought from @brian-ruf was that a Component Definition instance could capture the inherited controls exported by a leveraged system. Hopefully @brian-ruf and others will be interested in helping the CRM model research. Please let us know when you are ready to move it to the research track to further explore those options and more.

[Compton-US]

@aj-stein-nist and @iMichaela - Claiming for this sprint. I'm also going to pass this through also as a spiral on the research track for review and feedback as a test of the process there (passively). That'll make a little forward progress on this, and also not cause confusion in development.

[Compton-US]

This issue was presented at the OSCAL-DEFINE meeting this week, with the slides and feedback here:
usnistgov/OSCAL-DEFINE#11

Based on this feedback, we are going to produce an example that demonstrates the export as an attribute, as a part of the current spiral 3 that is focused on export examples.

Work proceeds here: usnistgov/OSCAL-DEFINE#10

[Compton-US]

This is being worked as a part of DEFINE:

• Research Effort: A model is needed for customer responsibilities that does not expose the SSP. OSCAL-DEFINE#5
• Discovery: Responsibility Modeling OSCAL-DEFINE#13

Keeping open since this is pending outcome.