Modeling of Related Parameters

[brian-ruf]

User Story:

In controls such as CA-7(g) (NIST 800-53, Rev 4), there are two parameters intended to work together as a pairing; however, each can have multiple values. One parameter identifies who should receive a report, and the second identifies how often the party in the previous parameter should receive the report.

An OSCAL modeling limitation arises when the following situation is encountered (real-world example):

• ISSO receives the report monthly

• System owner receives the report quarterly

• Parameter 1: ISSO, System-Owner

• Parameter 2: Monthly, Quarterly

This would be better modeled as:
Parameter Group 1:

• Parameter 1: ISSO
• Parameter 2: Monthly
  Parameter Group 2:
• Parameter 1: System-Owner
• Parameter 2: Quarterly

This limitation impacts constraints as well as values. FedRAMP requires (parameter constraint) one reporting party (_parm_1) and frequency (_parm_2), while wishing to leave the option open for additional organizationally-defined reporting parties and frequencies.
While a human could reasonably infer this from the current presentation, the current modeling does not allow a computer to parse the data consistently for this scenario.

Goals:

Expand the OSCAL modeling syntax to handle this scenario.
NOTE: the Parameter Group notation above is just an example, and is not intended to prescribe a specific solution.

Dependencies:

This was originally reported as a bug via Issue #472. See that issue for additional comments/discussion.

Acceptance Criteria

• The parameters for CA-7(g) (NIST 800-53, Rev 4) can be modeled accurately with the FedRAMP constraint and multiple parties/frequencies identified.
• 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.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}