Skip to content
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

Only interconnection type components support constraints #2086

Open
aj-stein-gsa opened this issue Dec 4, 2024 · 1 comment
Open

Only interconnection type components support constraints #2086

aj-stein-gsa opened this issue Dec 4, 2024 · 1 comment
Labels

Comments

@aj-stein-gsa
Copy link
Contributor

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

@brian-ruf
Copy link
Contributor

The above property collection needs to be de-coupled.

The following allowed values continue to only apply to interconnection components:

       <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> 

The following allowed values must be allowed on all of the following component types:

  • system
  • service
  • interconnection
  • software
       <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> 

Happy to provide justification if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Needs Triage
Development

No branches or pull requests

2 participants