-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starting to represent higher-order semantics in SP800-53/A ODPs #86
Comments
See also: AC-03(07) and AC-03(09) ODPs 1 and 2. |
We need to discuss with @wendellpiez to ensure this is actually done or there are other remaining tasks. |
We should consider dropping links into the labels to link to the related ODP. We should also consider adding a link for rel= |
Next (planning):
|
I now have work in my branch that exposes where references to controls and control parts (including ODPs) appear untagged in the SP800-53/A source XML. The full listing looks like this:
Note the working XSLT captures the actual text not just the locations; with some work it could produce a variant in which these were re-tagged. (We would produce a set of templates for this list, each of which would make the appropriate patch.) If we were to wrap each of these as an An example of how this would look: Before: <param id="ac-03.09_odp.02">
...
<guideline>
<p>controls to be provided by the outside system or system component (defined in AC-03(09)_ODP[01]) are defined;</p>
</guideline>
</param> After:
Comments? One comment I have is that while this is worded as a cross-reference, it might better be worded more directly:
... but this would entail a change to the copy. Another comment is that this does not actually capture where there are dependencies (as here). |
Also noting a couple of these are self-references, as in MP-7 and PM-7 guidance. (Tag these also?) |
Working branch is here: https://github.com/wendellpiez/oscal-content/tree/issue86-opd-analysis |
AJ talked with Wendell and this seems like the pre-work of analyzing this before 5.2 was a spike effort. We will consider this issue to track that. @wendellpiez agreed to create the follow-on issue to move the spike branch ☝️ with that analysis into production catalogs after 5.2 is released, so we will have to move it accordingly on the backlog. |
User Story:
In the forthcoming release of an integrated Revision 5 SP 800-53 with Appendix A (Assessment Procedures) we have something not so new, a bit of complexity in an ODP (organizationally-defined parameter) --
What is shown here in the label property really ought to be in a
link
and/orconstraint
(at least).Goals:
Dependencies:
Does exploiting the OSCAL models in this way to capture semantics of the data have an impact on how the parameters are represented and managed elsewhere in FISMA systems? (Potentially, yes.)
This is connected to Issue tbd in OSCAL, regarding development of any OSCAL-related guidance and modeling.
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.}
The text was updated successfully, but these errors were encountered: