Check allowed values for user authentication

[Rene2mt]

Constraint Task

As a maintainer of a digital authorization package, I need to clearly document in my SSP if leveraged FedRAMP authorized services require authentication, and also specify the authentication method, so that agencies that use my service understand potential risk around access to data in the external system. Checking to ensure I have provided complete user authentication method information will prevent pass back.

Intended Outcome

• Define a constraint that only allows the enumerated values below for user-authentication and provides remarks as specified below:
  • yes: A user authentication mechanism exists, and is described in the remarks.
  • no: A user authentication mechanism does not exist, the reason authentication is not necessary is described in the remarks.
  • not-applicable: No user authentication is necessary, and an attestation is provided in the remarks.

The constraint should give an ERROR if the conditions above are not met.

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 ./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

Check to ensure that for each leveraged authorized system / service, the SSP clearly documents if authentication is required and specifies what the authentication method is.

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 property needed to be moved from //leveraged-authorization to //component of certain types as the property is required for both table 6.1 and 7.1, but only components are used for 7.1.

The metapath for the constraint also becomes far more complex as it can be written once to cover both 6.1 and 7.1 relevant components:

//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'])
]

Also, due to the broader use of the allowed values, the language needs to be tweaked as follows:

• yes: An authentication mechanism exists, and is described in the remarks.
• no: An authentication mechanism does not exist, the reason authentication is not necessary is described in the remarks.
• not-applicable: The authentication requirement is not applicable, and is described in the remarks.

Please note the dropping of the word "user" in addition to the other revisions.

[Gabeblis]

@brian-ruf just to confirm, we're removing the //leveraged-authorization path altogether or are we adding the component paths on top of the leveraged-authorization path?

[brian-ruf]

@Gabeblis - correct!
For "user-authentication" (now "authentication-method") the ONLY path should be the one in the previous comment. That particular property is moving from //leveraged-authorization to //component, and then scoped down to only components that meet certain criteria.

[Gabeblis]

Perfect, thanks for the confirmation

[brian-ruf]

@Gabeblis I deleted my previous comment. We are going to make this much more simplified for now.

Let's simply have this allowed value list enforce the "user-authentication" prop/extension in any component that has it.

We have other constraints for ensuring it always appears in the correct components.

So this should be:

• metapath target='/system-security-plan/system-implementation/component/prop[@name='user-authentication' @ns='http://fedramp.gov/ns/oscal']'
• target="./@value"

[Gabeblis]

@brian-ruf Are you sure we should look for @name='user-authentication'? Or should it be @name='authentication-method'?