This subdirectory contains stable, best effort versions of OSCAL catalogs and profiles related to NIST SP800-53. The files have been produced by a combination of automated and semi-automated (editorial) processes.
NIST SP 800-53 Revision 5 files are available in the sibling rev5 folder.
This directory contains OSCAL catalog and profile content for SP 800-53 revision 4.
- NIST_SP-800-53_rev4_catalog.json: This file contains the full text of SP 800-53 revision 4 in OSCAL JSON format, including information integrated from appendixes describing objectives and assessments for controls (SP 800-53A).
- NIST_SP-800-53_rev4_catalog.xml: This file has the same contents as NIST_SP-800-53_rev4_catalog.json except in XML format.
- NIST_SP-800-53_rev4_LOW-baseline_profile.json: This file contains an OSCAL profile in JSON format representing the Low impact baseline profile (selection) of controls based on
NIST SP 800-53 rev4 Appendix D. - NIST_SP-800-53_rev4_LOW-baseline_profile.xml: This file has the same contents as NIST_SP-800-53_rev4_LOW-baseline_profile.json except in XML format.
- NIST_SP-800-53_rev4_MODERATE-baseline_profile.json: This file contains an OSCAL profile in JSON format representing the Moderate impact baseline profile (selection) of controls based on
NIST SP 800-53 rev4 Appendix D. - NIST_SP-800-53_rev4_MODERATE-baseline_profile.xml: This file has the same contents as NIST_SP-800-53_rev4_MODERATE-baseline_profile.json except in XML format.
- NIST_SP-800-53_rev4_HIGH-baseline_profile.json: This file contains an OSCAL profile in JSON format representing the High impact baseline profile (selection) of controls based on
NIST SP 800-53 rev4 Appendix D. - NIST_SP-800-53_rev4_HIGH-baseline_profile.xml: This file has the same contents as NIST_SP-800-53_rev4_HIGH-baseline_profile.json except in XML format.
The regular composition of controls and subcontrols (control enhancements) can be determined using a few XPaths over the XML content for interrogation:
distinct-values(//part/@name) -> statement, guidance, objective, assessment, object
distinct-values(//prop/@name) -> label, method, status
distinct-values(//part[@name=.//part/@name] -> statement, guidance, objective
* XPath expressions are given here on the assumption that unprefixed names are bound to the OSCAL namespace.
Controls have the following parts.
part[@name='statement']
part[@name='guidance']
part[@name='objective']
part[@name='assessment']
part[@name='object']
Also the following properties are given:
prop[@name='label'] gives the 'name' or 'number' of the control, enhancement, or component part of a control such as statements or objectives. These are derived from the data and expanded into full values.
prop[@name='method']
prop[@name='status'] A value of "Withdrawn" is given to this property only in controls and subcontrols designated as Withdrawn (from earlier versions of SP800-53).
Link elements appear for two reasons: either they capture implicit or explicit links given in the source data; or (in certain cases) they are inferred.
rel attributes on links, as in HTML, give some indication of the purpose or use of the link. In SP800-53 we have four values:
rel="related"indicate related controls: these links are given explicitly in the sourcerel="reference"indicates a citation of a reference as given in the sourcerel="corresp"shows where a control or enhancement objective corresponds to an item in its statementrel="incorporated-into"on Withdrawn controls or enhancements, indicate superseding controls.
All internal links validate in the sense that any href value beginning in '#' does indeed correspond to an id value given elsewhere. The catalog does (presently) have a link element with no href, in a case where no target is available. In other cases - where an href gives a URI - this rendition of the catalog does not stipulate or warrant that any resource can be retrieved at the given address.
Unique identifiers for any elements or constructs should probably be assigned by a local system in any case, but elements in OSCAL do have unique ID values assigned as attribute id and therefore useful as canonical identifiers. These values are derived from the labels and have been confirmed to be regular and systematic in the document as given.
Where labels have composite values delimited with parentheses, the parentheses are cast to "dot" (period) delimiters and the entire value cast to lower case.
So AC-3(1) becomes ac-3.1.
Where labels are composed by combining parentheses with values in brackets (on "objective" elements), the two segments are separated.
So AC-3(3)[6](b)(3)[a] becomes ac-3.3.b.3_obj.6.a as corresponding with (statement) AC-3(3)(b)(3) as objective [6][a].
This is done in order to facilitate the matching control objectives with corresponding items in their statements.
Note that since they correspond with labels, id values will be "sticky" across different versions of the catalog. So a pointer using such an ID by itself (that is, without being able to authenticate the hosting document as well) has no a guarantee of uniqueness or correctness. To mitigate this, applications may address a combination of element and document id - since the catalog/@id value should disambiguate versions of documents where the element id does not help to distinguish them.