Profile needs modify functionality for responsible parties

[degenaro]

User Story

As an OSCAL aggregate Profile author, I need to be able to identify the responsible parties for each control.

For example, control A may concern CISO A's expertise and control B may concern CISO B's expertise. Simply having a list of responsible parties in the Profile Metadata does not capture these relationships. As such, control owners of A and B cannot understand from the Profile and Metadata alone if each is responsible for control A and B, or just A, or just B or neither.

This functionality is needed to automatically populate SSP control-implementation -> implemented-req -> control ID -> responsible-party where there is an association between control and control owner support.

Goals

When this issue is closed, the resulting Profile schema provides the means to resolve relationship ambiguities with modify specifications between controls and responsible parties.

Dependencies

No response

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.
• [x] A Pull Request (PR) 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.

[aj-stein-nist]

@degenaro, thanks for opening this issue. Can you provide an example of a profile and catalog to demonstrate where the gap is?

/cc @ancatri

[ancatri]

Catalog NIST 800-53 IBM profile on NIST 800-53 has different CISO experts for each control family who need to provide their modifications/ additional guidance in this profile to the teams generating their component definitions and SSP. The SSP inherits for its control-implementation section these parties and while we have a way to express it SSP, we also need a way to capture it at profile time.

[aj-stein-nist]

Separate of the profile, let's focus on just the catalog: do you have a specific JSON/XML/YAML example of how you mark a specific family, control, or piece of it (to avoid other OSCAL terminology) as managed by one CISO expert party from multiple IBM parties?

It is important to understand how you are doing it today in a derived catalog, and if you cannot, what you would like to do. Thanks!

[ancatri]

We do not change anything in the NIST 800-53 catalog , we do the changes only via profile.

[aj-stein-nist]

So, profile resolution is catalog + changes profile -> new resolved catalog, and as it stands now the metadata resolution section of the spec I mentioned in Gitter does not define any required, defined behaviors for metadata roles in the profile, just source catalogs.

If we talk about the resulting catalogs, what would you want to see and where as an example? There is no specific, unique element in the OSCAL catalog model inside a control for the responsible role and/or party that manages a control or has some relationship to it.

Have you tried doing so with a prop yet?

[ancatri]

I find @wendellpiez solution, with a profile per CISO party, cleaner than pushing an existing party/role in the metadata as props under alter. I see your point on the resolved profile as catalog. The new catalog does not need to cary over the alter party owner. I would leave that detail only in the profile as a "draft" source for the new catalog, source for the SSP. The new catalog has the controls resolved, the SSP caries the alter responsible party ...

[wendellpiez]

For clarification, consider

<alter control-id="c1">
  <add>
    <prop ns="..." name="responsible-role" value="roleABC"/>
  </add>
</alter>

This provides for a prop to be given in the targeted control in resolution. It doesn't carry an "alteration responsibility" per se, but a more general assignment, but make of it what you like. (Of course this is just the tagging not any semantic, but that's the beauty of properties, they are open for you to use.)

For example, a workflow could validate (in addition to other validations):

• Every control in the resolved catalog has exactly one prop with this name/ns
• An SSP using this profile includes a role defined in metadata matching each such identifier (and this could be autopopulated)
• Every implemented requirement addressing a control has XYZ, where XYZ references the identified role

etc.

If you know ahead of time what roles are or may be defined in SSPs, that makes it easier to constrain the values of the properties in advance.

Part of the problem is defining you are trying to track - the role (or responsible party) of an emendation (e.g. a particular tailoring of a baseline) vs role of some 'responsible party' downstream. Either seems reasonable - and props could accommodate either.

[sunstonesecure-robert]

wouldn't this just be a catalog param that the profile can add to the controls in the catalog? thus the new resolved catalog would have required params in each control for the "control-owner" and that info could be copied into the SSP responsible-party by whatever SSP tooling needs to fill in ODPs?

the logic to feed into such SSP tooling many different (hierarchical?) values for these ODPs on a family/group, or control-by-control basis would be a feature of the SSP construction tooling. For a real world example, we have a database of all controls and we can assign (or import) one or more owners. at SSP construction time, we query via tooling each control and its owner so that value is used in the SSP. we don't ourselves have an override/inheritance model for assigning a default or override owner for every control, or every control in the group/family, since typically we obtain that info when we define the control implementation (and when necessary drag and fill in a spreadsheet works nicely before importing into the database). but your tooling/customer needs may vary and require that default/hierarchical logic to fill ODPs.

[iMichaela]

12/11/23

I find @wendellpiez solution, with a profile per CISO party, cleaner than pushing an existing party/role in the metadata as props under alter. I see your point on the resolved profile as catalog. The new catalog does not need to cary over the alter party owner. I would leave that detail only in the profile as a "draft" source for the new catalog, source for the SSP. The new catalog has the controls resolved, the SSP caries the alter responsible party ...

Based on the comment above, and options provided in the comments, I propose closing the issue.