Guidance on which layer to respond to statements

[Telos-sa]

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:

• ac-1_smt
  • ac-1_smt.a
    • ac-1_smt.a.1
      • ac-1_smt.a.1.a
      • ac-1_smt.a.1.b
    • ac-1_smt.a.2
  • ac-1_smt.b
  • ac-1_smt.c
    • ac-1.smt.c.1
    • ac-1.smt.c.2

If guidance were least granular, statement requirement would be:

• ac-1_smt

If gudiance were MOST granular, statement requirement would be:

• ac-1_smt.a.1.a
• ac-1_smt.a.1.b
• ac-1_smt.a.2
• ac-1_smt.b
• ac-1.smt.c.1
• ac-1.smt.c.2

If guidance is at the first item level, statement requirement would be:

• ac-1_smt.a
• ac-1_smt.b
• ac-1_smt.c

If no guidance, then all are applicable in ssp (issue with first cut of FedRAMP rev 5):

• ac-1_smt
  • ac-1_smt.a
    • ac-1_smt.a.1
      • ac-1_smt.a.1.a
      • ac-1_smt.a.1.b
    • ac-1_smt.a.2
  • ac-1_smt.b
  • ac-1_smt.c
    • ac-1.smt.c.1
    • ac-1.smt.c.2

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

• All readme documentation affected by the changes in this issue have been updated.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{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.}

[iMichaela]

@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]andAC-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.

[iMichaela]

FedRAMP solves this by leveraging a "response-point" tag, that identifies what specific control statement layer must be answered.

@Telos-sa - I am sorry I missed one point you made (see above). FedRAMP requested the links to help automate the process - please review the PR #221's conversation. My understanding is that the SSP's response point is include to allows you to document your implementation with the granularity expected by FedRAMP, so anything more granular provided by the 800-53A should be aggregated upwards. But I do not speak on behalf of FedRAMP, so please request guidance from them on how to proceed. NIST OSCAL content must reflect the source of truth (CPRT 800-83 v5.1.1 data sets (A & B included)

[Arminta-Jenkins-NIST]

At the 12/7 Triage Meeting: Team decided that the explanation will be reviewed and presented to the community member via a wiki on OSCAL Pages: Tutorials, blog, or similar page TBD.

[iMichaela]

No other comments were received from the community on this issue. Closing it.