aj-stein-gsa commented 6 days ago

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 commented 4 days ago

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.