Skip to content

Only interconnection type components support direction constraints #2086

Open
@aj-stein-gsa

Description

@aj-stein-gsa

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.

<allowed-values target="(.)[@type='interconnection']/prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name">
<enum value="isa-title">Title of the Interconnection Security Agreement (ISA).</enum>
<enum value="isa-date">Date of the Interconnection Security Agreement (ISA).</enum>
<enum value="isa-remote-system-name">The name of the remote interconnected system.</enum>
<enum value="ipv4-address">An Internet Protocol Version 4 interconnection address</enum>
<enum value="ipv6-address">An Internet Protocol Version 6 interconnection address</enum>
<enum value="direction">An Internet Protocol Version 6 interconnection address</enum>
</allowed-values>

https://github.com/usnistgov/OSCAL/blob/v1.1.3/src/metaschema/oscal_implementation-common_metaschema.xml#L191-L198

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

  1. Create a SSP with a component with a type that is not .[@type="interconnection"] and a prop[@name="direction" and @value="incoming"].
  2. 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

No one assigned

    Type

    No type

    Projects

    Status

    Needs Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions