Research spike: untagged links in parameters

[wendellpiez]

User Story:

As noted on Issue usnistgov/oscal-content#86, the most recent revision of SP800-53A includes at least one parameter where more information should be captured (regarding parameter values and constraints) and the dataset enriched to represent it, such as expressing the link between the parameters formally (to begin with), or validate the value set across them (for example).

This is an OSCAL issue insofar as we would like to develop and approach we can use throughout this data set (wherever appropriate) and also recommend to others for their own similar cases. Even if not a complete solution it should ideally be consistent going forward as a basis for further development or refinement.

Goals:

• Write queries to identify the base cases that need to be enriched. Perhaps regex that looks to parentheticals?
• Design an approach for using inline linking to address this.
• Create new issues identifying what work needs to be done to implement.

Initial thoughts

Using the example of AU(2) and its parameters, express the relations and constraints being stated in a machinable way. Note that ODP 2 here is defined as a subset of ODP 1 with respect to its value choice.

In XPath/Metapath an effective test could be simply .=//param[@id='au.02-odp.01']/(select/choice|value) (for any given value of ODP 2) or .=$linked with some way to declare $linked.

Do this simply and easily enough that the approach can be easily understood and widely deployed and supported.

The dependency on the neighbor ODP might also be expressed (prop[@name='depends-on]), even apart from the semantic aspect.

Dependencies:

usnistgov/oscal-content#86 depends on this Issue.

Acceptance Criteria

• A policy has been articulated and model defined for this case and any others found to be in scope
• It has been deployed in the usnistgov/oscal-content repository as appropriate (and in consultation with FISMA team)

Optional

• Follow-on Issues are made for documentation or further development

[wendellpiez]

usnistgov/oscal-content#86 proposes to add <a> (anchor) tagging where cross-references are not yet marked (37 cases) including this one.

We have a rule for marking such a dependency using link[@rel='depends-on'], as in other cases.

If that suffices to provide more explicit (rational) linking, we could possible add those by patching per control -- where appropriate, since some might not actually be dependencies.

So we can proceed by:

• Addressing Starting to represent higher-order semantics in SP800-53/A ODPs oscal-content#86 and merging content with tagged <a>
• Over that data, perform analysis for param//a and possibly other locations, to determine whether any elaboration is called for

[aj-stein-nist]

@wendellpiez and I will need to meet and discuss this one, moving to Sprint 63.

[aj-stein-nist]

@wendellpiez given what we discussed with the "these issues relate to the NIST SP 800-53 Rev 5.2 updates" collection of issues. Given our current window estimate on that is a few weeks, can we discuss here/Gitter/quick meeting if we can move these until after Sprint 63 (March, not February) and only bring them back in as needed?

[wendellpiez]

We can pick them up and run if all the other gravitational fields align.

[aj-stein-nist]

OK, thanks for the clarification. Per discussion last week, can you 1) please adjust wording here to identify the work tracked in this issue was spike research and development work and 2) create and link to the new issue you created or will create to merge this into oscal-content main for release post Rev 5.2? Thanks.

[wendellpiez]

@aj-stein-nist I have renamed the Issue. It now better reflects that this was a research effort.

However as noted, it was also created as a dependency for an Issue in another repo, namely usnistgov/oscal-content#86. And research findings asked for here have been posted to that Issue, with a spike branch containing WIP: https://github.com/wendellpiez/oscal-content/tree/issue86-opd-analysis

This suggests to me that there is no actual (remaining) OSCAL Issue here, only an oscal-content Issue. Can we close this? Or is this job not done until we have discussed possible approaches more broadly or other possible approaches?

[aj-stein-nist]

@aj-stein-nist reviewed this with Arminta and determine if he will close or not re the previous comment, seems likely we should. I assigned this with Further Analysis Needed status.

[aj-stein-nist]

As of a53f261 it seems the parameters are tagged with with a approach like so:

      <control class="SP800-53" id="au-2">
         <title>Event Logging</title>
         <param id="au-2_prm_2">
            <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="au-02_odp.02"/>
            <prop name="aggregates" ns="http://csrc.nist.gov/ns/rmf" value="au-02_odp.03"/>
            <label>organization-defined event types (subset of the event types defined in <a href="#au-2_smt.a">AU-2a.</a>) along with the frequency of (or situation requiring) logging for each identified event type</label>
         </param>
         <param id="au-02_odp.01">
            <prop name="alt-identifier" value="au-2_prm_1"/>
            <prop name="alt-label" class="sp800-53" value="event types that the system is capable of logging"/>
            <prop name="label" class="sp800-53a" value="AU-02_ODP[01]"/>
            <label>event types</label>
            <guideline>
               <p>the event types that the system is capable of logging in support of the audit function are defined;</p>
            </guideline>
         </param>
         <param id="au-02_odp.02">
            <prop name="label" class="sp800-53a" value="AU-02_ODP[02]"/>
            <label>event types (subset of AU-02_ODP[01])</label>
            <guideline>
               <p>the event types (subset of AU-02_ODP[01]) for logging within the system are defined;</p>
            </guideline>
         </param>
         <param id="au-02_odp.03">
            <prop name="label" class="sp800-53a" value="AU-02_ODP[03]"/>
            <label>frequency or situation</label>
            <guideline>
               <p>the frequency or situation requiring logging for each specified event type is defined;</p>
            </guideline>
         </param>
         <param id="au-02_odp.04">
            <prop name="alt-identifier" value="au-2_prm_3"/>
            <prop name="label" class="sp800-53a" value="AU-02_ODP[04]"/>
            <label>frequency</label>
            <guideline>
               <p>the frequency of event types selected for logging are reviewed and updated;</p>
            </guideline>
         </param>

So it seems the OSCAL content work is also complete. Analysis complete, so I will close.