iMichaela
commented
11 months ago @Telos-sa - the links inserted are not changing anything 800-53A provides (including the level of granularity which was expressed before through the round parentheses () and [] ones that existed for many years in NIST SP 800-53A. For example:
<part name="statement" id="ac-3.7_smt">
<p>Enforce a role-based access control...[skip]"/>.</p>
</part>
<part name="guidance" id="ac-3.7_gdn">
<p>Role-based access ...[skip]... and objects covered by the policy.</p>
</part>
<part id="ac-3.7_obj" name="assessment-objective">
<prop name="label" class="sp800-53a" value="AC-03(07)"/>
<part id="ac-3.7_obj-1" name="assessment-objective">
<prop name="label" class="sp800-53a" value="AC-03(07)[01]"/>
<p>a role-based access control policy is enforced over defined subjects;</p>
<link rel="assessment-for" href="#ac-3.7_smt"/>
</part>
<part id="ac-3.7_obj-2" name="assessment-objective">
<prop name="label" class="sp800-53a" value="AC-03(07)[02]"/>
<p>a role-based access control policy is enforced over defined objects;</p>
<link rel="assessment-for" href="#ac-3.7_smt"/>
</part>
<part id="ac-3.7_obj-3" name="assessment-objective">
<prop name="label" class="sp800-53a" value="AC-03(07)[03]"/>
<p>access is controlled based on <insert type="param" id-ref="ac-03.07_odp.01"/> and <insert type="param" id-ref="ac-03.07_odp.02"/>.</p>
<link rel="assessment-for" href="#ac-3.7_smt"/>
</part>
<link rel="assessment-for" href="#ac-3.7_smt"/>
</part>Even from the first publication of 800-53 with 800-53A embedded, the data was in there and it meant that, for example, assessment-objective with the id="ac-3.7_obj" and the label with value=AC-03(07)' is applicable to the AC-03(07) control statement BUT is has more than one objectives. It has :AC-03(07)[01]`AC-03(07)[02] and AC-03(07)[03]. We realized that some users were not understanding well the applicability of the assessment-objective, so we enhance the catalog with the links to allow you to programmatically infer those relations.
I hope this explanation provides the requested Guidance and clarifies that current links are not inserted arbitrarily and that the "granularity" is triggered by the official 800-53A data set. Lates release of the OSCAL catalog provides data enhancements per CPRT 800-53 and 800-53A official documents. Please see the NIST 800-53 v5.1.1 announcement and the online CPRT Security and Privacy Controls for Information Systems and Organizations, 5.1.1 aka 800-53,A,B data
If the explanation is confirmed sufficient by @Telos-sa or other community members, then I recommend closing this issue as completed (see explanation above). Alternatively, we can create an ADR with the above explanation included for the community to point to. As of now, we do not maintain a directory for ADRs but it can be a Wiki page. If you find it useful as a Wiki page, please suggest it in a separate issue so we can track it separately.
Arminta-Jenkins-NIST
User Story:
As an oscal user leveraging the NIST provided baseline resolved profile catalogs (High, Moderate, Low, Privacy), I need a way to identify the statement layers that require an answer when completing the SSP, and preventing the need to duplicate efforts across the layers This can be in the form of guidance for answering at the most granular level, or at the upper most level.
For instance AC-1 has the following statement layers:
If guidance were least granular, statement requirement would be:
If gudiance were MOST granular, statement requirement would be:
If guidance is at the first item level, statement requirement would be:
If no guidance, then all are applicable in ssp (issue with first cut of FedRAMP rev 5):
FedRAMP solves this by leveraging a "response-point" tag, that identifies what specific control statement layer must be answered.
Goals:
A clear message to creators of content (specifically for catalog tailoring) with the ability to leverage a "response-point" to denote which statements are required for their organization. This will ensure ease of building out SSP related content for customers and avoid situations were layering may create more confusion and duplicate efforts for Project teams when creating their SSP's.
Dependencies:
NIST should provide guidance on any recommendations for where the profiles should be answered, to further scope SSP generation.
Acceptance Criteria
{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}