Allowed Values for nature-of-agreement for leveraged authorization

[aj-stein-gsa]

Constraint Task

As a maintainer of a digital authorization package, in order to know I am using the appropriate type of agreement between the documented system and its leveraged authorization(s) documented in my SSP so that I avoid a pass-back, I would like a check in my SSP to confirm the appropriate types of agreement between the CSP maintaining a CSO documented in a SSP and its leveraged authorization(s).

Intended Outcome

Goal

Syntax

• Define an allowed-values constraint that allows the enumerated values below or other possible options (allow-other="yes"):
  • contract: A contract between the CSP and the organization that owns the leveraged system.
  • mou: A memorandum of understanding between the CSP and the organization that owns the leveraged system.
  • sla: A service-level agreement between the CSP and the organization that owns the leveraged system.
  • eula: An end user license agreement between the CSP and the organization that owns the leveraged system.
  • license: An application license agreement between the CSP and the organization that owns the leveraged system.
  • other: An non-typical agreement between the CSP and the organization that owns the leveraged system. Explain in remarks.

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

There are only NIST-defined allowed values.

Metapath(s) to Content

//component[@type='system' and ./prop[@name='leveraged-authorization-uuid']]/prop[@name='nature-of-agreement' and @ns='http://fedramp.gov/ns/oscal' ]

Purpose of the OSCAL Content

Check for agreement types as they are material to the review of a CSO SSP by FedRAMP reviewers.

Dependencies

No response

Acceptance Criteria

• All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
  • Explanation is present and accurate
  • sample content is present and accurate
  • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
• All constraints associated with the review task have been created
• The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
• The constraint conforms to the FedRAMP Constraint Style Guide.
  • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
• Known good test content is created for unit testing.
• Known bad test content is created for unit testing.
• Unit testing is configured to run both known good and known bad test content examples.
• Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
• A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
• This issue is referenced in the PR.

Other information

No response

[brian-ruf]

IMPORTANT

Metaschema path updated!

This list of allowed values is specifically for //component[@type='system'] representing a leveraged authorization, thus having a prop[@name='leveraged-authorization-uuid']

A similar - but not identical - set of allowed values is required on the same property for external systems, which are also //component[@type='system'], but specifically without the leveraged-authorization-uuid property. "interconnection" components and "service" components may also have variants.

[brian-ruf]

This issue is very similar to #907 and it would be efficient for the same person to do both at the same time.

[DimitriZhurkin]

@brian-ruf,

Is <component type="system"> different from <component type="this-system">?

I mean, is system a new FedRAMP value?

[aj-stein-gsa]

@brian-ruf,

Is <component type="system"> different from <component type="this-system">?

I mean, is system a new FedRAMP value?

A longstanding one.

this-system: The system as a whole.
system: An external system, which may be a leveraged system or the other side of an interconnection.

Source: OSCAL SSP model docs re components

[brian-ruf]

Per discussion with @DimitriZhurkin and @brian-ruf the allow-others should be set to no instead of yes.

[aj-stein-gsa]

OK, well I will update the issue AC then.