Allowed Values for nature-of-agreement for external systems.

[brian-ruf]

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 external system(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 the external system.

Intended Outcome

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 external system.
  • [ ] mou: A memorandum of understanding between the CSP and the organization that owns the external system.
  • [ ] isa: An interconnection security agreement between the CSP and the organization that owns the external system.
  • [ ] sla: A service-level agreement between the CSP and the organization that owns the external system.
  • [ ] eula: An end user license agreement between the CSP and the organization that owns the external system.
  • [ ] license: An application license agreement between the CSP and the organization that owns the external system.
  • [ ] other: An non-typical agreement between the CSP and the organization that owns the external system. Explain in remarks.

Syntax Type

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

Allowed Values

FedRAMP allowed values must be defined or verified.

Metapath(s) to Content

//component[@type='system' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']]/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]

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