Information Types for for Leveraged Authorizations and External, Interconnected, and Unauthorized Systems

[brian-ruf]

Constraint Task

As an SSP author, I need to ensure I am using the correct information types when documenting leveraged authorizations external services and interconnections.

Intended Outcome

Enforce the 800-60 allowed value list within components that represent external communication, identical to enforcement within information-type.

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

FedRAMP allowed values must be defined or verified.

Metapath(s) to Content

//component[
   (@type='system' and ./prop[@name='leveraged-authorization-uuid'])
or
   (@type='service' and not(./prop[@name='leveraged-authorization-uuid']) and  ./prop[@name='implementation-point' and @value='external'])
or
   (@type='interconnection')
or 
   (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction'])
or
   (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction'])
]

Purpose of the OSCAL Content

Aligns any reference of information type to 800-60 and enables the reference of information type impact information relative to the leveraged authorization or external service/interconnected system.

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

The allowed values were recently added/revised in PR # 917 in satisfaction of issue #890; however, the allowed values were only applied to //information-type. They also need to be applied to //component as defined by the above xpath.