SSP Control Implementation Scope/Origination

[brian-ruf]

User Story:

As an OSCAL we need to better differentiate scope and origination of responsibility for control and more granular control statements in the SSP model.

See the table in issue #572 for inspiration for references.

Goals:

• Using analysis, ensure scope and origination can be appropriately represented at all appropriate levels of granularity (implemented-requirement, statement, and/or by-component)
• Ensure syntax and documentation are updated, enabling OSCAL users to apply this feature.
• Create new issues identifying the specific OSCAL model and documentation changes that are needed to address this issue

Dependencies:

None.

Acceptance Criteria

• [ ] Update the constraint to allow the prop to appear at the statement, by-component, and statement/by-component levels.
• [ ] Add a note in the docs about how to resolve the effective value when values are applied at multiple levels.
• [ ] 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 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.

[david-waltermire]

It looks like the prop control-origination is only supported at the implemented-requirement level right now. This can be added to the statement, by-component, and statement/by-component levels. It should be noted that the most specific (lowest level) one must win when this value is defined at multiple levels.

[david-waltermire]

This was a gap identified in #1385. Perhaps this could be addressed as part of this issue.

We need to consider a way forward that aligns with how FedRAMP is currently considering this information. e.g., it should be possible to map from the approach we design to the current FedRAMP approach.

[sunstonesecure-robert]

several issues on CIS/CRM end up linked here, but the details in those issues are great, and this seems to be more of a catch-all. Github handles all the linkages but since the language in this and may of the issues is "perhaps" "can" "may" - it becomes less clear, especially over weeks and months, whether there is 1:1 coverage of the issues brought up earlier with a lot of detail and the end proposal.

I would just hate to lose a lot of that great detailed discovery - but appreciate the benefits of good issue hygeine!

[Compton-US]

@sunstonesecure-robert Thank you for sharing your feedback and concerns! In this particular issue, we just addressed a consistency issue with the origination prop discovered at the component and statement level. We are carrying on with the CRM modeling work in #1467, which was created just a few days ago. At the moment, I note the prior supporting issue at the very beginning, and there is a "related to" section where I reference other tickets from the past that others have recommended reviewing. I'll try to make a pass to see if I've missed anything, but if there is an issue you think I've missed, definitely leave me a note on #1467, and I'll take a look.