Erroneous self-reference on SC-12
Agh42 opened this issue · comments
Describe the bug
In NIST_SP-800-53_rev5_catalog.json there is a self-reference from control SC-12 to SC-12 (itself).
Who is the bug affecting?
Everyone working with the example catalog.
What is affected by this bug?
Data consistency.
When does this occur?
When importing the data into a tool.
How do we replicate the issue?
Please see the attached screenshots:
- I highlighted the link in the JSON file.
- I noticed the self-reference while importing this data into the Neo4J graph database. It's immediately obvious in the graph:
Expected behavior (i.e. solution)
This reference should not be present.
Other Comments
I noticed this while importing the OSCAL content into a Neo4J database. The scripts I am using are available in my Github repo
Thank you @Agh42 I have confirmed we have two of these in both XML and JSON representations: SC-12 refers to itself and so does PS-6.
However, I can't confirm that this is an error since the published catalog (I looked at https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) also shows these controls with references to themselves. (So: while quite probably an error, I am not the one to say.)
This means the error is in the upstream sources, and probably in the current FISMA database.
We probably need to bring this to the FISMA team to clarify the intent here, and then refresh on their revision cycle.
Good find!
@david-waltermire-nist this is a good example of a FISMA team issue.
@Agh42 We have committed to keep the OSCAL content in sync with the published SP 800-53 content. Once this is fixed in the SP 800-53 content, we will get the updated OSCAL to fix this. Until then, we cannot do much about this.
@wendellpiez, please review to confirm whether or not it is done. If not, we add to Sprint 63 and prioritize.
My current upstream dataset shows this fixed. Presumably a change will show up in a diff in the (eventual) PR.
It's kind of fun how this data issue shows up when a robot draws a picture. I'm a little surprised there were not more. Speaks to the thoroughness and care of the data owners.
My current upstream dataset shows this fixed. Presumably a change will show up in a diff in the (eventual) PR.
Cool, can we commit to cutting it out of your current dataset into a targeted PR to fix this? I will remove the closable tag for now.
It's kind of fun how this data issue shows up when a robot draws a picture. I'm a little surprised there were not more. Speaks to the thoroughness and care of the data owners.
Yes, we need to make it an important, long-term priority to find ways of detecting such issues early, but that will come later. Thanks.
Actually no. The change was actually a change that had to be made to upstream content. (We communicated it to data owners and they made the change.) So it's going to come in with other revisions that come with this update. This makes it effectively impossible to carve out.
Your final remark suggests you don't get the point though. The error was not ours, nor was the redundant link. SC-12 actually did refer to itself and the link was an accurate reflection. Only with the forthcoming errata update will it be fixed - not because we fixed it, but because it was deemed an erratum. 😎
Your final remark suggests you don't get the point though.
Can you set aside 15 minutes to meet with me and it explain it then? Thanks.
The point is that this is not the kind of "error" we can detect, since it is not an error until it is defined as such in the source data we are bound to emulate, by the owners of that source data.
Sorry if the tone was short - it was late, last night.
@wendellpiez can you still please set aside 15-30 minutes and schedule a meeting to make sure I more fully understand this and plot a tentative resolution date?
Okay.
To summarize:
- The original report was not an OSCAL error, it was an error in the original document. Control SC-12 contains a link to itself among its 'related' controls.
- Thanking our user for detecting it, we reported this to the FISMA team.
- It will be resolved in the forthcoming rev5.2 update release.
- While arguably we could remove the offending link prior to this, to do so violates our contract of fidelity to the source.
In view of this, what remains to be done on this Issue? Once FISMA made the delivery, it will disappear when we commit the updated OSCAL.
Happy to fit in the 15 or 30.
CPRT shows that this error documented in this issue has been fixed in the 800-53 v 5.1.1 but not in OSCAL representation. We will be able to fix the error in OSCAL version as well.
Addressed by #238