duplicate `alt-identifier` `prop` elements in NIST_SP-800-53_rev5_catalog.xml

[GaryGapinski]

Describe the bug

nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml contains duplicate alt-identifier prop elements.

See //param[prop [@name eq 'alt-identifier'][2]]. The first is duplicative; the second seems erroneous.

Who is the bug affecting?

Users of oscal-content.

What is affected by this bug?

Quality of content.

When does this occur?

As of this writing.

How do we replicate the issue?

See //param[prop [@name eq 'alt-identifier'][2]].

Expected behavior (i.e. solution)

No duplicate or erroneous alt-identifier prop elements.

Other Comments

{Add any other context about the problem here.}

[aj-stein-nist]

@GaryGapinski, I was reviewing this for triage (we will sync again on Thursday) and I am a little confused by the two examples provided. Are the alternate identifiers pointing to similar, but ostensibly different, alternate parameter IDs?

I checked at the following commit, and I see sc-42.1_prm_1 and sc-42.2_prm_1 as well as si-10_prm_1 and si-10.1_prm_1, which seem similar, but different.

@wendellpiez and @david-waltermire-nist, am I wrong?

https://raw.githubusercontent.com/usnistgov/oscal-content/159073e8a8ca16b3f8fba695aa00018f12535719/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml

            <param id="sc-42.01_odp">
               <prop name="alt-identifier" value="sc-42.1_prm_1"/>
               <prop name="alt-identifier" value="sc-42.2_prm_1"/>
               <prop name="label" class="sp800-53a" value="SC-42(01)_ODP"/>
               <label>sensors</label>
               <guideline>
                  <p>sensors to be used to collect data or information are defined;</p>
               </guideline>
            </param>

         <param id="si-10_odp">
            <prop name="alt-identifier" value="si-10_prm_1"/>
            <prop name="alt-identifier" value="si-10.1_prm_1"/>
            <prop name="alt-label"
                  class="sp800-53"
                  value="information inputs to the system"/>
            <prop name="label" class="sp800-53a" value="SI-10_ODP"/>
            <label>information inputs</label>
            <guideline>
               <p>information inputs to the system requiring validity checks are defined;</p>
            </guideline>
         </param>

[GaryGapinski]

While params are a bit wild west, particularly after SP 800-53Ar5, the first of these in https://raw.githubusercontent.com/usnistgov/oscal-content/main/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml is

         <control class="SP800-53-enhancement" id="sc-42.1">
            <title>Reporting to Authorized Individuals or Roles</title>
            <param id="sc-42.01_odp">
               <prop name="alt-identifier" value="sc-42.1_prm_1"/>
               <prop name="alt-identifier" value="sc-42.2_prm_1"/>
               <prop name="label" class="sp800-53a" value="SC-42(01)_ODP"/>
               <label>sensors</label>
               <guideline>
                  <p>sensors to be used to collect data or information are defined;</p>
               </guideline>
            </param>

which cites another control's (sc-42.2) param alt-identifier despite being an alt-identifer for sc-42.1. This is likely introduced by an upstream data error (unless there was deliberate intent to encourage promiscuity between sibling control enhancements).

The second instance

      <control class="SP800-53" id="si-10">
         <title>Information Input Validation</title>
         <param id="si-10_odp">
            <prop name="alt-identifier" value="si-10_prm_1"/>
            <prop name="alt-identifier" value="si-10.1_prm_1"/>
            <prop name="alt-label"
                  class="sp800-53"
                  value="information inputs to the system"/>
            <prop name="label" class="sp800-53a" value="SI-10_ODP"/>
            <label>information inputs</label>
            <guideline>
               <p>information inputs to the system requiring validity checks are defined;</p>
            </guideline>
         </param>

is analogous - the second alt-identifier references a separate control.

Separately, the guideline content is not parameter guideline content - it is SP 800-53A assessment objectives stated as falsifiable assertions - not "A prose statement that provides a recommendation for the use of a parameter.".

[aj-stein-nist]

(unless there was deliberate intent to encourage promiscuity between sibling control enhancements)

I thought this was the intent, but I think I might have been mistaken. We (namely the more knowledgeable of those I pinged) in a triage review Thursday, if not before then, to discuss. I might have misread and had presumed an interpretation that is incorrect, so :shrug:.

[david-waltermire]

@wendellpiez We should add a Schematron rule to the SP 800-53 pipeline that checks for this exceptional condition to ensure we don't get these.

[wendellpiez]

See screenshot on https://github.com/usnistgov/oscal-tools/issues/64 for published SI-10

Effectively what the OSCAL proposes is that what was represented by two parameters in the old catalog (https://github.com/usnistgov/oscal-content/blob/185bd540749d3de321c176837a28b74c0de0b5b4/src/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml), is now a single parameter referenced twice, once from the enhancement.

@david-waltermire-nist @aj-stein-nist @GaryGapinski do you concur?

Extending our rendering logic so that it does the right thing in this case, is a follow-on task: see https://github.com/usnistgov/oscal-tools/issues/64

[wendellpiez]

Here's a screenshot of SC-42, for discussion.

Here too, it appears that a single parameter is referenced more than once: it is defined in SP-42(1) and referenced there and again in SP-42(2).

In this case the parameter reference crosses from one control enhancement to another (sibling) enhancement.

By this reading the @alt-identifier values are correct.

Whether they are really useful, to whom, for what purposes, are other questions.

Comments welcome!

[wendellpiez]

A Schematron rule is now showing where references are made to parameters that are not defined within the control or group context of the reference. For SI-10 it is fine, since a second reference to a parameter defined in the parent control is made in the enhancement SI-10(1). For SI-42 it is not fine, since SI-42(2) contains a reference to a parameter defined in SI-42(1) (a sibling not an ancestor).

This is currently marked as a warning, but since parameter retrieval is implicated in processing we may wish to tighten this (both as a constraint and in the data).

[wendellpiez]

Summary:

• The multiple alt-identifier tags in both these cases turn out to be correct, accurately reflecting a little refactoring between catalog versions (parameters collapsed where they they should be reused, not redefined)
• This is actually reflected in the insertion points for parameter references as described above
• To control enhancement SC-42(2) sc-42.2 we can add:

<link rel="required" href="#sc-42.1"/>

showing that this enhancement cannot be used without the neighbor enhancement (b/c its text makes reference to a parameter from the other).

In the case of SI-10 no such link is needed since the extra reference is within the hierarchy (made from the enhancement to the parameter defined in the control).

Remaining tasks:

• [x] Add 'required' link
• [x] Finalize and post Schematron detecting unflagged cases
• [x] Make PR with these

[GaryGapinski]

See screenshot on usnistgov/oscal-tools#64 for published SI-10

Effectively what the OSCAL proposes is that what was represented by two parameters in the old catalog (https://github.com/usnistgov/oscal-content/blob/185bd540749d3de321c176837a28b74c0de0b5b4/src/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml), is now a single parameter referenced twice, once from the enhancement.

@david-waltermire-nist @aj-stein-nist @GaryGapinski do you concur?

I concur. The technique is appropriate. However it works only because use of control enhancements entails use of the enhanced control (see NIST SP 800-53 rev5 §2.2 ¶2 final sentence), and thus a related constraint should be employed, as well as an <insert> constraint that requires associated parameter value definition. And since a parameter can reference (via <insert>) parameters, the constraint logic becomes more elaborate. And that is a NIST 800-53 constraint, not (yet) a general OSCAL constraint, so may be variously interpreted in various venues.

Since a param can be found in multiple places a suitable parameter identifier scheme should be employed.

Somewhat related, @alt-identifier lacks a version attribute.

[wendellpiez]

Agreed on reforming the parameter identifier scheme. As for lack of context or traceability for @alt-identifier, you make a good point, but those might also be temporary stopgaps, not of interest to anyone with no mappings to old param id values.

@david-waltermire-nist PR usnistgov/oscal-content#129 is now up addressing this Issue, ready for review.

[wendellpiez]

@david-waltermire-nist just noting that the SC-42(2) case is called out as a bug in #101 -- where the argument is made these should be independent settings, not a single combined setting. (Discussion? upstream content editors presumably discussed this.)

[david-waltermire]

@wendellpiez For wrapping up this issue, would you please write a summary in this issue describing how the patterns @GaryGapinski identified are correct?

[wendellpiez]

The essence of the problem here is not in the alt-identifier values, but in how they reflect refactoring in the way parameters are deployed and referenced in the updated OSCAL Rev5 with assessment data added, and specifically the ways these relate to parameterized values in the original Rev 5 content.

In summary there are three categories of parameters, the third of which includes the cases in question.

Simple "same" parameters

Whenever possible (as determined by content authors) references to parameters from both 800-53 and 800-53A content are collapsed and considered "the same", while using "new" IDs (and label properties) for consistency. The parameter carries a single alt-identifier with the old ID, which is being replaced. Often a new 53A reference will simply say (effectively) "parameter X referenced in the control must be set". Sometimes it has more specific information, but this happens whenever a new parameter would be satisfied entirely by an old one.

The new IDs on this class of parameter -- and label properties carry the odp notation. Old IDs carry a prm substring.

An example:

<param id="ac-01_odp.04">
  <prop name="alt-identifier" value="ac-1_prm_3"/>
  <prop name="label" class="sp800-53a" value="AC-01_ODP[04]"/>
  <label>official</label>
  <guideline>
     <p>an official to manage the access control policy and procedures is defined;</p>
  </guideline>
</param>

To see why ODP 4 used to be identified as prm_3, consider the next case.

Simple "split" parameters

On occasion, single values required for 800-53 are decomposed into multiple values for purposes of assessment (typically to address more granular scope). In such cases, the original (old) parameter is retained, for reference (as a single value) from 800-53 contents. New parameters are also added for holding the decomposed values, for reference from 800-53A contents. To indicate this relation, the old parameters are now marked with props, for example in ac-1_prm_1 directing to the corresponding (disaggregated) new parameters:

<param id="ac-1_prm_1">
  <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ac-01_odp.01"/>
  <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="ac-01_odp.02"/>
  <label>organization-defined personnel or roles</label>
</param>
<param id="ac-01_odp.01">
  <prop name="label" class="sp800-53a" value="AC-01_ODP[01]"/>
  <label>personnel or roles</label>
  <guideline>
     <p>personnel or roles to whom the access control policy is to be disseminated is/are defined;</p>
  </guideline>
</param>
<param id="ac-01_odp.02">
  <prop name="label" class="sp800-53a" value="AC-01_ODP[02]"/>
  <label>personnel or roles</label>
  <guideline>
     <p>personnel or roles to whom the access control procedures are to be disseminated is/are defined;</p>
  </guideline>
</param>

Parameters retained to represent such aggregations do not have "label" properties (marked with prop[@name='label']), since these parameters have never received formal labels, instead being referenced (commonly) by the line item in which their values were reported. Parameter reuse, however, is greatly aided by the assignment of explicit labels, so all 'new' parameters, whether as an update as in the "simple same" case, or disaggregated, carry 'label' properties (prop values), which indeed can be used in renditions, such as in the standalone publication of control assessment methods given in SP800-53A.

Reused parameters

On a couple of occasions, refactoring has gone the other way: instead of a value for 800-53 being decomposed into two (or more) values for 800-53A, more than one value in 800-53 is deemed actually to be a reuse of a single value. In this case, a single parameter is deployed in the control where it is first referenced, and subsequent references are rewired to point to this occurrence.

The new parameter carries an alt-identifier for each of the parameters in the earlier catalog rendition that captured this information.

Note that in this case, processing a parameter correctly for a given control, requires that the control where the parameter is defined (not necessarily the same) is treated as a prerequisite.

On one occasion, in SI-10, the reuse of the parameter is in an enhancement (contained control object) of the control where the parameter is defined.

On another occasion, SC-42(2), a parameter defined in one enhancement SC-42(1), is referenced again from inside a sibling control (enhancement), SC-42(2).

A link with rel of requires is provided any time such a dependency is implied by parameter referencing. The same link is given to indicate any enhancement's dependency on its parent control, so only a single occurrence of such a link needed to be added to support this (for the SC-42 case).