Add Linking from Objectives to Statements for the 800-53 Catalog

[aj-stein-nist]

User Story:

As an OSCAL tools developer and/or security practitioner, I want an explicit linking between objectives and control statements in the SP800-53 OSCAL catalog.

Goals:

There is an implicit linking through a common ID naming scheme, but this could be made more explicit with a linking relationship that does not require human understanding or machine-level parsing and transformation of IDs themselves.

The rationale and goals stem from the conversation around improvements we can make in usnistgov/oscal-content#98.

Dependencies:

N/A

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• 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.}

[GaryGapinski]

Please separate 800-53 content from 800-53A content. The recent attempt to render them in the same document managed to damage the 800-53 content in favor of 800-53A in a manner which was entirely upside-down: 800-53A pseudo-ODPs are derivative from those of 800-53, not the other way around. Keeping the content separate would also have the salutary result of keeping the 800-53A leading zero affectation in a sanitary cordon.

Such a separation is healthy — NIST issues the 800-53 SPs independent of one another — and relationships can be accommodated by inter-document linkages from 800-53A content to 800-53 content: not the other way around.

Separately, mapping presumptive 800-53A assessment objectives to 800-53 control statement imperatives (and thus derivative system security plan control implementation statement declarations) is a worthy topic for discussion. 800-53A assessment method to and from assessment objective mapping is also of worthy of discussion.

[wendellpiez]

I like this idea very much, albeit with caveats and concerns.

The biggest set of concerns has to do with how we approach design and deployment of variants on this site and others, which is a data governance policy question. @aj-stein-nist has already mentioned the need for this conversation in another context.

Apart from this, I can see a deployment of two coupled catalog instances with an XSLT (perhaps accompanied by human-readable pseudocode) for creating a unified version, with explicit links, from the pair. Alternatively it could be done in reverse, with the single synthetic instance provided with a transformation to split it into "clean" partitions (main text vs 53A).

However, this could also be done outside our repository.

wrt data governance / decision questions (keeping agility in mind) don't we need an Issue on that? @david-waltermire-nist

Also @GaryGapinski if you want this idea to float to general discussion more quickly please feel free to make an Issue for it.

[wendellpiez]

Not having seen any more discussion regarding the foregoing proposal, we return to regularly scheduled programming. WIP now appearing in https://github.com/wendellpiez/oscal-content/tree/issue123-objectivelinks

These corrections to the data were made by hand:
ee6b9aa

Additionally, links were added to assessment objectives linking them to statements.

The syntax is as follows (the link element is new):

<part id="ac-1_obj.a-1" name="assessment-objective">
  <prop name="label" class="sp800-53a" value="AC-01a.[01]"/>
  <link rel="depends-on" href="#ac-1_smt.a"/>
  <p>an access control policy is developed and documented;</p>
</part>          

is "depends-on" the correct link/@rel?

See draft PR #147

[wendellpiez]

Remaining work on this issue:

• Validate correctness of the new data, in detail
• Clean up the working branch
• Squeeze commit history

[wendellpiez]

Here's a data quality question. So far we have:

<part id="mp-8_obj.b" name="assessment-objective">
    <prop name="label" class="sp800-53a" value="MP-08b."/>
    <part id="mp-8_obj.b-1" name="assessment-objective">
        <prop name="label" class="sp800-53a" value="MP-08b.[01]"/>
        <p>there is verification that the system media downgrading process is commensurate with the security category and/or classification level of the information to be removed;</p>
        <link rel="depends-on" href="#mp-8_smt.b"/>
    </part>
    <part id="mp-8_obj.b-2" name="assessment-objective">
        <prop name="label" class="sp800-53a" value="MP-08b.[02]"/>
        <p>there is verification that the system media downgrading process is commensurate with the access authorizations of the potential recipients of the downgraded information;</p>
        <link rel="depends-on" href="#mp-8_smt.b"/>
    </part>
    <link rel="depends-on" href="#mp-8_smt.b"/>
</part>

Question: do we want the link from the containing part (the one at the very end)? or is it superfluous (due to the absence of text at that level)? or maybe it is the lower-level links we do not need?

[wendellpiez]

Working branch here: https://github.com/wendellpiez/oscal-content/tree/issue123-objectivelinks

[david-waltermire]

Talked with @wendellpiez about this. He is going to pose a question in this issue with 3 possible answers (i.e. both, inner, and outer) for community discussion at a future Lunch with the Devs. Once this is done we will tag this issue with "discussion needed" and "lunch with the devs".

[aj-stein-nist]

Similar to the spike consideration in #86, we will relabel this a spike, create a new issue for production wrap-in of this work after 5.2 release like that issue. @wendellpiez will create an issue to track this work and we will close this out in the sprint after that is done. IMPORTANT: we need to make sure in that issue we track goals of "reviewing decision with NIST team" and "briefing the community with options" and make final decision.

[wendellpiez]

Should this be reopened in view of the removal of the blocker, namely data improvements from upstream?

As I understand it currently, this Issue has not been addressed but WIP towards that end is available in a working branch: https://github.com/wendellpiez/oscal-content/tree/issue123-objectivelinks

Also see #147.