SP 800-53 revision 5 final updates

[wendellpiez]

Includes:

• Freshly produced version of SP800-53 Rev 5, in OSCAL, with many corrections.
• New OSCAL profiles representing baselines with adjustments reflecting final revisions of SP 800-53B

Note that files marked as FPD represent the earlier (February) final public draft version of SP800-53 and can potentially be removed now those documents have been superseded.

Remaining issues here awaiting resolution:

• correct broken links (see Renovate SP800-53 production pipeline converting to OSCAL from docx source #25)
• remove FPD versions from repo?

I can promote this PR from draft once these and any newly discovered issues are addressed.

[iMichaela]

@david-waltermire-nist - I reviewed this PR but without write access to this repository, I cannot do more than leaving a comment. The OSCAL baselines files are OK. The OSCAL catalog file was not reviewed again in its entirety. I reviewed only the previously identified errors to make sure they were all addressed. With the exception of the squared parentheses [ ] around references (e.g. [PRIVACT] as opposed to PRIVACT), everything is in good shape.

[brian-ruf]

Recommend we remove the draft baselines.
Also it doesn't appear the resolved profile catalogs were generated for the final baselines.

[wendellpiez]

New Rev5 catalog with broken links removed is now in this PR. See #25.

We still need to determine how to handle archiving FPD stuff.

[brian-ruf]

@wendellpiez these profiles have an issue with their import statements.

The file name for 800-53r5 appears here as :
NIST_SP-800-53_rev5-FINAL_catalog

However, each profile's import statement points to:
NIST_SP-800-53_rev5_catalog
(without -FINAL in the file name)

[brian-ruf]

For comparison, here are the titles used in the OSCAL files for Rev 4, vs the OSCAL files for Rev 5.

I'd like to suggest the Rev 5 titles better align with the Rev 4 usage, which includes the Rev number in the profile titles (so people know it's a profile for Rev 5 and not Rev 4):

Rev 4 Titles	Rev 5 Titles
NIST Special Publication 800-53 Revision 4: Security and Privacy Controls for Federal Information Systems and Organizations	NIST SP800-53 Revision 5
NIST Special Publication 800-53 Revision 4 HIGH IMPACT BASELINE	SP800-53 HIGH IMPACT BASELINE
NIST Special Publication 800-53 Revision 4 MODERATE IMPACT BASELINE	SP800-53 MODERATE IMPACT BASELINE
NIST Special Publication 800-53 Revision 4 LOW IMPACT BASELINE	SP800-53 LOW IMPACT BASELINE
	SP800-53 PRIVACY BASELINE

[wendellpiez]

@brianrufgsa those are good ideas, so I have done that. The details make a difference.

(Although saying 'withdrawn' not 'Withdrawn' makes an exception to Ruf's Rule, heh.)

[iMichaela]

11/12/2020

BUG: LOW+PRIVACY baseline imports HIGH baseline. Same for MODERATE+PRIVACY.

I expected that the merged security + privacy profiles to explicitly list the merged controls. It is hard to check if the issues raised earlier regarding the main control vs enhancements pulled in by privacy baseline are addressed, especially when the profile is used and tailoring is done

[SECURITY]+HIGH:

AC-3(14) - ok, pulled in by LOW BL
AU-3(3) - ok, pulled in by LOW BL
PE-8(3) - ok, pulled in by LOW BL
PM-5(1) <-- no PM control is in a security baseline. ISSUE PENDING
SA-8(33) - ok, pulled in by LOW BL
SC-7(24) - ok, pulled in by LOW BL

[iMichaela]

BUG: LOW+PRIVACY baseline imports HIGH baseline. Same for MODERATE+PRIVACY.
Additional comments are provided under "Conversation", regarding resolved merged (listing all merged controls) of the security+privacy profiles and the unresolved issue of PM-5(1) with is pulled in by the privacy profile without PM=5 (not an OSCAL issue, but an issue).

[wendellpiez]

Thanks @iMichaela!

I wonder what others think regarding the question of whether the compound baselines (overlays) should import either or both of the constituent profiles (security baseline + privacy overlay). At present as noted, the privacy controls are listed out in the compound baseline (imported from the catalog) but the security baseline is imported (as a profile). I am not sure @brianrufgsa @david-waltermire-nist or other potential consumers have told us what they think; all opinions are useful (and we could even deploy more than one solution, as a demo).

It's a good question to be asking now.

[iMichaela]

@wendellpiez Maybe we can poll the audience to the Model review meeting tomorrow. Or ask on Gitter. A resolved profile will provide full information in the form of a catalog, but without a tool that compounds the security baseline with the privacy one (as designed by the privacy team), for some people might be confusing.

[iMichaela]

LGTM. So far, I did not find anything else that needs corrections.

[brian-ruf]

The Rev 5 catalog in this PR has errors.

There are four locations in the Rev 5 catalog where the parameter assignment value is hard-coded in the statement, rather than represented with an <insert>, such as:

        <part name="item" id="au-2_smt.c">
          <prop name="label">c.</prop>
          <p>Specify the following event types for logging within the system: [Assignment: organization-defined event types (subset of the event types defined in <a href="#au-2_smt.a">AU-2a.</a>) along with the frequency of (or situation requiring) logging for each identified event type];</p>
        </part>

The four locations where I found this include:

• au-2_smt.c
• cm-2_smt.b.2
• pt-3_smt.a
• si-23_smt.b

[wendellpiez]

I am going to put a detector for these in the Schematron and do a bit more analysis.

The presence of the anchor (<a>) makes this problem a bit sticky, but that's what the source data has, so it is a requirement to reflect it.

Also, AU-2.c is an interesting case of a cross-referencing semantic in the data, i.e. the values are being constrained here by the value of another parameter. Indeed, it is also a compound parameter, whose value will be not a scalar but a map or index (from event types to logging policy).

[iMichaela]

Suggest this statement to be updated to a content that reads a little better and that is similar to the other descriptions . E.g.
This directory contains the OSCAL Final Public Draft (FPD) version of SP 800-53 Revision 5 catalog and SP 800-53B profiles. This content is now superseded, and the files are provided for reference only.

[iMichaela]

Reviewed all changes. All look good. I only suggested one statement in the readme.md to be updated .

[iMichaela]

Please see issue #38

[iMichaela]

All links identifying the required related control (the parent) are in place.

[david-waltermire]

This PR was manually merged and is now closed.