Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Telos-sa opened this issue Dec 6, 2023 · 3 comments
Closed

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

Telos-sa opened this issue Dec 6, 2023 · 3 comments
Labels
bug The issue is a bug report. Discussion Needed The issue or PR needs to be reviewed by the OSCAL development team.

Comments

@Telos-sa
Copy link

Telos-sa commented Dec 6, 2023

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.

@Telos-sa Telos-sa added the bug The issue is a bug report. label Dec 6, 2023
@github-project-automation github-project-automation bot moved this to Needs Triage in NIST OSCAL Work Board Dec 6, 2023
@iMichaela
Copy link
Contributor

@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 Arminta-Jenkins-NIST added the Discussion Needed The issue or PR needs to be reviewed by the OSCAL development team. label Dec 7, 2023
@Arminta-Jenkins-NIST Arminta-Jenkins-NIST moved this from Needs Triage to Further Analysis Needed in NIST OSCAL Work Board Dec 7, 2023
@Arminta-Jenkins-NIST
Copy link

Arminta-Jenkins-NIST commented Dec 7, 2023

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
Copy link
Contributor

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.

@github-project-automation github-project-automation bot moved this from Further Analysis Needed to Done in NIST OSCAL Work Board Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug report. Discussion Needed The issue or PR needs to be reviewed by the OSCAL development team.
Projects
Status: Done
Development

No branches or pull requests

3 participants