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.}

[brian-ruf]

When evaluating this, look at the parameter in Rev 5, AU-2, statement c, which states it's a subset of the supplied parameter value of statement a, with applied frequency of (or situation requiring) logging for each event type.

[david-waltermire]

This issue requires building a relationship between parameters in the catalog model. It also requires some thought on how to address parameter pairs related to set-parameter in catalogs, profiles, and SSPs. This is a big undertaking to complete for 1.1. Moving this back to 1.2 for now.