Check that SaaS has at least one leveraged authorization

[Rene2mt]

Constraint Task

As a maintainer of a digital authorization package, I need make sure that my SaaS cloud service offering has at least one leveraged authorization, so that agencies that use my service have a clear understanding of what authorizations are being leveraged (e.g., underlying IaaS) and can more effectively understand control inheritance and how control responsibilities are satisfied. Checking to ensure that the SSP for a SaaS has at least one leveraged authorization may prevent pass back during review of my SSP.

Intended Outcome

Define a constraint to ensure that if //system-characteristics/prop[@name='cloud-service-model']/@value is saas, then
count(//leveraged-authorization) >= 1

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

Not sure, can maintainers help me choose?

Metapath(s) to Content

//system-characteristics/prop[@name='cloud-service-model']/@value

Purpose of the OSCAL Content

In order to understand the overall security posture of a SaaS cloud service offering, reviewers need to

• know what the leveraged authorizations are for the SaaS
• confirm leveraged authorizations are authorized appropriate security impact level
• can confirm control inheritance, and control responsibilities (e.g., SaaS vs underlying IaaS leveraged system)

Failure to provide leveraged authorizations (e.g., for a SaaS) gives reviewers and agencies an incomplete view of the cloud service offering's security posture. This will result in a "pass back" to obtain the missing information.

Dependencies

Check to ensure that for each leveraged authorized system / service, the SSP clearly documents (what user types / roles) are authorized users.

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

[Rene2mt]

Per review with @aj-stein-gsa and @brian-ruf , this constraint should be level="WARNING". This is rare, but there can be cases where a CSO is a SAAS, but the CSP owns the entire stack so there isn't a leveraged authorization for the underlying IaaS.