search

usnistgov / oscal-content

NIST SP 800-53 content and other OSCAL content examples
Other
292 stars 122 forks source link

Leading zero's not consistent throught the OSCAL catalog #224

Closed Telos-sa closed 8 months ago

Telos-sa commented 9 months ago

Describe the bug

The introduction of padding zero's to match 5.1.1 has not been implemented in the following:

catalog[group][control][@id] catalog[group][control][parameter][@id] catalog[group][control][part][@id]

Who is the bug affecting?

Customers that are wishing to convert to OSCAL, customers still working through conversion from rev 4 to rev 5, GRC tools that create control catalogs for users are impacted by this change.

What is affected by this bug?

Change in how to programmatically map the rev 4 content to Rev 5. Inconsistent messaging between the OSCAL Catalog, the CPRT, and Control Catalog excel https://csrc.nist.gov/files/pubs/sp/800/53/r5/upd1/final/docs/sp800-53r5-control-catalog.xlsx are creating confusion for which is the source of truth, what the structure should be, and how we should be developing our content.

When does this occur?

With the introduction of 5.1.1

How do we replicate the issue?

Review content from OSCAL elements path outlined above, to the CPRT, to the Control catalog.

CPRT (With leading Zero's) image

OSCAL Catalog (No Leading Zero's)

image

XLSX Catalog (No leading Zero's)

image

Expected behavior (i.e. solution)

Consistent and clear messaging from OSCAL, to CPRT, to xlsx Catalog.

iMichaela commented 9 months ago

@Telos-sa - You are absolutely right, to avoid implementation issues for the implementers of OSCAL. The team discussed this issue at length, and concluded that the @id are just IDs, not capitalized either and not aiming to reflect the CPRT Control ID. The catalog had even before a prop/@name="labels" and prop/@value=[the CPTR Control ID]. Please see

 <prop name="label" class="sp800-53a" value="AC-01"/>

If the community considers the @id updates a positive improvement for them with no support issues, we can add those through a patch release. @Telos-sa - please work with the community members to provide their feedback her. We are open to this alignment but had the community's interest at heart.

Arminta-Jenkins-NIST commented 9 months ago

At the 12/7 Triage Meeting: The team is concerned that changing the IDs to include leading 0s could break the implementation of current adopters, in particular FedRAMP that provides templates . We are seeking feedback from the community on replacing the labels of structure: 

<prop name="label" value="IA-9"/>
<prop name="label" class="sp800-53a" value="IA-09"/>

with 

<prop name="alt-identifier" class="sp800-53a" value="IA-09"/>
<prop name="alt-identifier" class="sp800-53a" value="IA-09"/>

Please provide feedback on the proposed approach no later than 12/08, EOB since the patch release with the bug fixed and official control identifier captured correctly is urgent.

iMichaela commented 8 months ago

the OSCAL IDs cannot be zero-padded due to backwards compatibility issues. PR #228 addressed it by adding prop/name="alt-identifier" to reflect the 800-53 v5.1.1 zero-padded IDs.