Information Types 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.

[Gabeblis]

@brian-ruf for this instance: (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction'])
Should the implementation point value be `@value='external'? i'm not seeing any instances of the implementation point value being internal and also having an information-type prop. I only see it for the external.

[brian-ruf]

@brian-ruf for this instance: (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction'])
Should the implementation point value be `@value='external'? i'm not seeing any instances of the implementation point value being internal and also having an information-type prop. I only see it for the external.

@Gabeblis in this one instance, "internal" is correct. this is about connections that cross the authorization boundary. Most of the scenarios involve this system connection to an external system, but there is one use case where this system is offering the API service and various other systems are connecting to the API to interact.

Please note; however, that the "direction" property should be dropped. I'll add another comment about this in the next few minutes.

[Gabeblis]

Thank you 🫡

[brian-ruf]

@Gabeblis one more where the path needs to change

//component[

   (@type='system' and ./prop[@name='leveraged-authorization-uuid'])

or

   (@type=('service', 'software') and not(./prop[@name='leveraged-authorization-uuid']) and  ./prop[@name='implementation-point' and @value='external'])

or

   (@type='interconnection')

or 

   (@type=('service', 'software') and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='communicates-externally' and @value='yes' and @ns='http://fedramp.gov/ns/oscal'])

]

[Gabeblis]

@Gabeblis one more where the path needs to change

//component[

   (@type='system' and ./prop[@name='leveraged-authorization-uuid'])

or

   (@type=('service', 'software') and not(./prop[@name='leveraged-authorization-uuid']) and  ./prop[@name='implementation-point' and @value='external'])

or

   (@type='interconnection')

or 

   (@type=('service', 'software') and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='communicates-externally' and @value='yes' and @ns='http://fedramp.gov/ns/oscal'])

]

Ok, I added this change in #973.

[brian-ruf]

Consistent with the decision articulated in issue #930 (See this comment), this work needs the following two additional constraints:

• Every "information-type" property/extension must have an @class attribute.

  • target="//component/prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']"
  • exists(./@class)

• The allowed values for the @class attribute are:

  • target="//component/prop[@name='information-type' and @ns='http://fedramp.gov/ns/oscal']/@class"
  • "incoming": This information type originates outside the system boundary and flows in.
  • "outgoing": This information type originates within the system boundary and flows out.

[vmangat]

Should the information types be limited to the information types that were listed in the system's FIPS-199 categorization or ALL 800-60 information types