Description
Describe the bug
When attempting to enhance constraints for different types of components in a system security plan that represent cross-boundary communication, we have confirmed that a prop[@name="direction"]
is necessary to describe the direction of network communication. However, you can only use this property on component[@type="interconnection"]
, not others as applicable. More details can be found in GSA/fedramp-automation#950 to complete work for GSA/fedramp-automation#930.
Below is the relevant constraint that needs to be adjusted.
OSCAL/src/metaschema/oscal_implementation-common_metaschema.xml
Lines 191 to 198 in b123c11
Who is the bug affecting
Developers and engineers who want to develop or consume constraint-based analysis to know if their OSCAL-based system security plan meets all NIST and FedRAMP-specific requirements.
What is affected by this bug
Metaschema, Modeling
How do we replicate this issue
- Create a SSP with a component with a type that is not
.[@type="interconnection"]
and aprop[@name="direction" and @value="incoming"]
. - Run the oscal-cli or other conformant tooling to confirm the constraint does not permit this allowed value.
Expected behavior (i.e. solution)
Different types of components permit the use of this property.
Other comments
FedRAMP can use a @ns
flag for the given prop, but we want to align with general use cases NIST supports and that can increase confusion about the difference between the identically named props while also decreasing interoperability.
Revisions
No response
Metadata
Metadata
Assignees
Type
Projects
Status