usnistgov / oscal-content

NIST SP 800-53 content and other OSCAL content examples
Other
303 stars 123 forks source link

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

Closed aj-stein-nist closed 1 year ago

aj-stein-nist commented 2 years ago

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

{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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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: https://github.com/usnistgov/oscal-content/pull/147/commits/ee6b9aa9a347c1ee3a8b7ae79358bd1e2d74f985

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 commented 2 years ago

Remaining work on this issue:

wendellpiez commented 2 years ago

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 commented 1 year ago

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

david-waltermire commented 1 year ago

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 commented 1 year ago

Similar to the spike consideration in usnistgov/oscal-content#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 commented 1 year ago

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.