Expand Catalog Control Status Allowed Values

[brian-ruf]

User Story

As an author of control catalogs and baselines, I need the ability to indicate specific controls are:

1. Withdrawn (currently allowed) [NIST SP 800-53 catalog]
2. Deprecated (currently not allowed) [Department of Education control overlays]
3. Reserved (currently not allowed) [Department of Education control overlays]
4. Provisional or Conditional (currently not allowed) [FedRAMP Tailored, PCI DSS]

Note that deprecated is similar to, but not morally equivalent to withdrawn. The primary difference is that withdrawn is backward looking and indicates the control is no longer valid whereas deprecated is forward looking, indicating when a control will no longer be valid, requiring a milestone event or date trigger.

There is a "status" property allowed for controls within the catalog metaschema; however, currently the only allowed values are "withdrawn" and "Withdrawn", which is a NIST RMF-specific restriction.

I recommend the following:

• expand the //control/prop[@name='status']/@value allowed values list to include other common scenarios such as described above.
• add allow-other="yes" to the allowed-values constraint for
• when creating a separate RMF-specific metaschema, re-assert the requirement for "withdrawn" as the only allowed value for the "status" prop only for the RMF context.

Note the changes for the first and second bullets are relevant to this constraint in metaschema.

EDITED to change "Depreciated" to "Deprecated".

Goals

• Allow values other than "withdrawn" for a control's "status" property.

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

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[iMichaela]

@brian-ruf - A “deprecated” control or feature is one that remains available and functional but is no longer recommended for use. In contrast, “depreciated” refers to a reduction in the value of an asset over time.

What would be the intended meaning of a “depreciated” control in this context?

Additionally, by allowing other values (i.e., adding allow-other="yes"), we effectively permit any arbitrary term. I have significant concerns about the usability and interpretability of an effectively infinite set of permissible values.

If instead we carefully expand the controlled vocabulary and provide precise definitions for each permitted value, users will have clearer guidance and will be better positioned to interpret the information consistently and correctly.

[brian-ruf]

@iMichaela first apologies for the distraction from the main point by my use of the wrong word. Department of Education uses "Deprecated". I have edited the original issue to use the correct word.

While I understand your concern to a degree, I feel that approach only works best when the possible list of allowed values has been well-researched and the universe of possibilities can be reasonably accommodated in the allowed values list.

In this case there are many well known status types that can are blocked by the current constraint. Clearly there was no attempt to research the list of possibilities before the constraint was set to only allow "withdrawn". Indeed, in this instance it would have been better to establish a "withdrawn" property with allowed values of "true" or "false" rather than block the use of a "status" property that clearly has other possible values.

If we wish to prioritize OSCAL adoption, there are two options for this situation:

• Option 1: proceed as I suggest, making a reasonable attempt to add values that are known to be used, but keeping the door open to other possibilities we may have missed and let specific frameworks limit to allowed values that apply to them.

• Option 2: proceed as you suggest, but perform a more exhaustive research of frameworks to ensure we capture as many possible allowed values as possible, while blocking other values.

Option 1 allows us to move faster while not blocking other possible uses of the property that we may have missed. It carries a risk of people using non-standard values where we missed a value, but doesn't block people from using the field immediately if they have a use case we failed to address.

Option 2 ensures the highest level of interoperability, but the trade-off is that for any use case we missed (as with the ones above), the adopting entity is blocked from using the status field for their use case until they submit an issue and wait for a new OSCAL release.

I'd feel better about Option 2 if we thoroughly researched this and ensured a fully comprehensive set of allowed values was available, and if we were updating OSCAL on a monthly or quarterly cadence. In the absence of that, I recommend Option 1 as the most efficient path forward given our current circumstances. We would still define the additional allowed values for which we know there are use cases. (Department of Education, PCI DSS, FedRAMP Tailored)

[iMichaela]

@brian-ruf - Thank you for your fast reply. The list does not have to be locked TODAY (your Option 1 - which is what I suggested too) and if other standards cannot map their choice of words for the control's status to what we support, we can accommodate later, OR they can use a namespace that will be recorded in the registry we so much need. I was not suggesting to expand the list today and never augment it :) (Option 2) . I apologize of I did not convey properly the point I was making. I am though very concerned and not convinced the allow-other="yes" is the way to go if we want machines to process the information automatically. The standards body where we will take OSCAL to standardize internationally will be able to negotiate a more comprehensive list (Option 2)

[brian-ruf]

@iMichaela ah perfect! Yes, I like the lockdown as a goal after we are confident we have a reasonably complete list. I can create a PR on this over the next week. As part of the PR I'll try to do some research to determine what other status values may be necessary for real-world use cases.

[brian-ruf]

Based on research, I recommend expanding the list of allowed values as follows:

Value	Source/Rationale
active	[Default] This control is currently in force
withdrawn	This control was withdrawn or retired and is no longer in force. The remarks may include a withdrawn date, content version or other reference.
incorporated	This control was incorporated into another control as identified by one or more "incorporated" links.
moved	This control was moved as identified by a "moved" link.
reserved	This is a placeholder for a future control.
deprecated	This control will be withdrawn. The withdrawn timeline or milestone may be describe the remarks.
conditional	This control is only applicable under certain conditions described in the remarks.
superseded	This control has been superseded by the artifact indicated by one or more "superseded-by" links or as described in the remarks.
experimental	This control is a pilot or proposed control; not yet required

Cardinality

The cardinality of the "status" prop should be 0 - 2

Cardinality Rationale: Most of these values are mutually exclusive; however, "conditional" could apply to "active", "depreciated", and "experimental". Further, some framework authors may wish to leave the "conditional" status for historical reference when a control is "withdrawn", "incorporated", "moved" or "superseded".

[iMichaela]

Addressed by PR #2202 and related #2222