Add Post-OSCAL Still Conventional Attachments #106
Conversation
GaryGapinski
commented
Jun 18, 2021
GaryGapinski
commented
- additionally add Privacy-related constraints
- additionally add Privacy-related constraints
This comment has been minimized.
This comment has been minimized.
-change "lacks" to "has" - remove comments from consolidation
This comment has been minimized.
This comment has been minimized.
- SP 800-60v2r1 checks are separate
This comment has been minimized.
This comment has been minimized.
| <sch:value-of | ||
| select="$path" /> has no reference within the document</sch:assert> |
There was a problem hiding this comment.
NB: This should have more positive language, correct?
| <sch:value-of | |
| select="$path" /> has no reference within the document</sch:assert> | |
| <sch:value-of | |
| select="$path" /> SHOULD optionally have a reference within the document (but does not)</sch:assert> |
There was a problem hiding this comment.
Good suggestion.
| <sch:title>A FedRAMP SSP must incorporate one policy document and one procedure document for each of the 17 NIST SP 800-54r4 control | ||
| families</sch:title> | ||
|
|
||
| <!-- TODO: handle attachments declared by component (see implemented-requirement ac-1 for an example) --> |
There was a problem hiding this comment.
B: So is this still correct and the componentized attachments are not supported?
There was a problem hiding this comment.
The consensus with the OSCAL developers appeared (twice) to be that inventory-items should hold the related attributes and that "inheritance" should not be used. This did not have certitude, so we could restore inheritance were that to be the final resolution.
There was a problem hiding this comment.
I was confused because, in our last NIST sync meeting, you acknowledged their advice. Then you said something along the lines subsequently in different later meeting between you, Dan, and I that you would keep it anyway, since you saw it as unwise to throw it out. I was surprised, but you suggested it was not such a big deal since the code was implemented and there was no reason to roll it back.
Am I mistaken?
There was a problem hiding this comment.
I do not think you are mistaken. I will overlay component inheritance on the system inventory after a get a clean unit test on system-inventory-less-component-inheritance.
I do not think there is any other way to reduce the complexity+redundancy of inventory properties other than to use component inheritance. However, that will be a novel type of system inventory representation to FedRAMP reviewers. I presume, that a transform from OSCAL to traditional FedRAMP system inventory will be desired if not necessary.
Co-authored-by: Alexander Stein <61464190+ohsh6o@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
…omation.git into composite-schematron
This comment has been minimized.
This comment has been minimized.
- tweak base64 content validation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This is closed (obviated) by #108. |
* Update submodule and configuration for submodule. The usnistgov/OSCAL repo has a `main` branch, `master has been deprecated and removed. * Updated content with content-upgrade transforms. * Check Fix SSP errors fixed. * Update prop with `-ref` suffixes to `by-` prefixes. * Add explicit XSD validation checking with xm-model PI. * Update `CORE` and `response-point` props. Other fixes. * More fixes. * Switch from @id-ref to @target-id. * Adjust status/state to status/@State. * Logical content touchups, lots of target additions. * Mixed up status/@State enum value. Made a small slip in `/assessment-results//target/status/@state`. * Base on resolution and current NIST SP800-53 catalog. Fix errors like this: ``` /oscal/baselines/rev4/xml/FedRAMP_rev4_HIGH-baseline-resolved-profile_catalog.xml:4175: element select: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}select', attribute 'how-many': [facet 'pattern'] The value 'one or more' is not accepted by the pattern '[\i-[:𐀀-󯿿]][Resolved profile '/oscal/baselines/rev4/xml/FedRAMP_rev4_HIGH-baseline-resolved-profile_catalog.xml' is not a valid OSCAL catalog. ```
