Profile Parameter Modification Modeling Limitations

[brian-ruf]

Describe the bug

The following are limitations related to parameter constraints and values.

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

The issue arises when the combination of the two parameters is intended to reflect one party (_parm_1) receiving the report on one frequency (_parm_2) , and another party (_parm_1) receiving the report on a different frequency (_parm_2). Under the current OSCAL syntax, each of the two parties would be provided as values of _parm1, and each of the two frequencies would be provided as values of _parm_2; however, there is no way to link each party to its respective frequency.

2. Similarly with this control, FedRAMP prescribe 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 this could reasonably be inferred from the current presentation, there is no way for a machine to understand the intention of this scenario.

Who is the bug affecting?

The FedRAMP PMO.

What is affected by this bug?

FedRAMP's ability to properly model their parameter modifications, and organizations wishing to identify more than one possible value-pair for the two related parameters.

When does this occur?

When modeling, NIST SP 800-53, Revision CA-7(g) is the control in question. (Need to add others to this list.)

Expected behavior (i.e. solution)

Suggest the OSCAL Team evaluate a way to better model these pairs, perhaps by allowing an optional @id attribute on the value elements, and enabling linking of those value elements, such as with an optional @linked-value-id attribute.

This would allow multiple values to be listed for each parameter, and would allow the related pairs to be linked.

[david-waltermire]

@brianrufgsa How big of a priority is this issue? Can this wait for Milestone 3? Or does this need to be addressed in Milestone 2?

[brian-ruf]

@david-waltermire-nist, I think this can wait for MR3. We can live with it for now and work around it for now.

[brian-ruf]

@david-waltermire-nist - This ties into metaschema discussions. Consider rolling into whatever sprint addresses those. (per @wendellpiez)

[wendellpiez]

This issue appears to me to fall within the scope of constraint checking and validation going beyond the schema into rule sets scoped to particular catalog families and even instances.

That is, a generalized validation mechanism that can address co-occurrence constraints could be employed to test propositions such as "when parameter X has value X1, parameter Y must have value Y1".

This is possible now with custom application code or e.g. with Schematron. However, this would be entirely local and ad hoc, not useful (for example) on JSON unassisted. (Still useful, and useful to know how to do.)

A more generalized approach could be designed and supported via Metaschema or a Metaschema layer.

For now, @brianrufgsa, is it helpful to document the expected relation between the two parameters with a constraint on either or both? While not yet automatable, this is a straightforward way of communicating the intent.

[david-waltermire]

@brianrufgsa This is not a bug. Can you create a new issue as a feature request? You can reference this new issue here and then close this issue.

[brian-ruf]

Moved this issue from a bug to a feature request (Issue #563). Closing this one.