Add responsibility-party-role check

[aj-stein-gsa]

Constraint Task

As a maintainer of an OSCAL package, in order to know I have properly identified every relevant role has a related responsible party (be it person or organization) just as needed and avoid passbacks, I want a check that every role has a party related to it.

Intended Outcome

Goal

Check that all roles have corresponding parties

Syntax

• Create an index constraint (id="party-has-one-responsibility" and level="ERROR" that checks that each party is bound to one responsible-party/party-uuid given the responsible-party/@role.

Syntax Type

This is required core OSCAL syntax.

Allowed Values

There are no relevant allowed values.

Metapath(s) to Content

//metadata/party
//metadata/responsible-party
//metadata/role

Purpose of the OSCAL Content

To check intregrity of relationships between different parties and roles.

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

Note: we seem to have finalized review and merge of this work in #718. We need to come back and revisit that.

[aj-stein-gsa]

@brian-ruf one thing I noticed but I have had trouble tracking down is an assertion pretty late in the game of "1 party, 1 role" wthout much context or history. From the OSCAL perspective, that is easy to check, but generally from a review perspective is that possible? I assume the roles are not so-so granular in packages, but I am curious what unspoken rule in review this would connect to.

So, for now, I leave this in backlog.

[brian-ruf]

There are key roles that must have parties associated, but there can be many other roles that do not have parties for reasons such as being orphaned in the editing process. While a potential indicator of missing data, this should at most generate a warning, not an error, and may not even be worth checking for at all.

It won't impact pass backs, because all review feedback would go through the system ISSO anyway, but it might impede an assessment. And I can see where a CSP might run our constraints in advance or engaging a 3PAO.

[aj-stein-gsa]

Thanks, @brian-ruf, that makes plenty of sense. What I have not found is better evidence of why "every party can have one role and only role" precedent in the Schematron validation rules, but not overall in FedRAMP. Is that reasonable, and each org would have sub-org or individual broken down for necessary separation of roles? Given what I have seen and know in Word docs, that seems unlikely, so I wanted to check.

(This could have been based in an overreach from references in the old rules.xml file, but I am not sure if that came directly from me; this work from the 10x team was much more expansive after I left, see below.)

fedramp-automation/src/validations/rules/rev4/rules.xml

Lines 1257 to 1263 in 136f3c6

	<rule
	assertions="role-has-responsible-party"
	doc:guide-reference="Guide to OSCAL-based FedRAMP System Security Plans §4.6-§4.11"
	doc:template-reference="System Security Plan Template §9.3"
	sch:pattern="general-roles">
	<statement>One or more responsible parties must be defined for each role.</statement>
	</rule>

[brian-ruf]

I don't know where that came from, and do not believe it is valid. A single party can, and often does have more than one role. Especially in smaller organizations.
For example, it would be reasonable for the same individual to be both ISSO and SSP author. Likewise, the same executive might be the system owner, SSP approver and policy approver.

[aj-stein-gsa]

Cool, thanks for the update. This kind of thing is why I wanted to hold this one before throwing it back into the top of the pile.