Inherited Control Description Guidance Mismatched with Validations

[TonyCiceroUS]

This relates to ...

• the FedRAMP OSCAL Registry
• the FedRAMP OSCAL baselines
• the Guide to OSCAL-based FedRAMP Content
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)
• the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• the FedRAMP OSCAL Validations

What happened?

According to the Guide to OSCAL-based FedRAMP System Security Plans (SSP), an inherited control implementation description is optional, however according to NIST a description property is required on an 'inherited' object. Furthermore, the FedRAMP validations requires that an inherited control implementation description must contain at least 32 words.

Relevant log output

No response

How do we replicate this issue?

1. Added Inherited object to by-component as shown in the guide
2. Run validations on SSP

Where, exactly?

FedRAMP validation rule:
https://github.com/GSA/fedramp-automation/blob/master/src/validations/rules/rev5/ssp.sch#L3514-L3521

NIST reference:
https://pages.nist.gov/OSCAL-Reference/models/v1.0.4/system-security-plan/json-reference/#/system-security-plan/control-implementation/implemented-requirements/by-components/inherited

Guide to OSCAL-based FedRAMP System Security Plans (SSP):

Other relevant details

FedRAMP should follow the NIST OCSAL guidance for inherited controls descriptions making them required. FedRAMP should then remove the requirement for a minimum of 32 words in the control implementation description for inherited controls (even the example provided is not 32 words in length).

[Rene2mt]

Concur with regards to requiring description on inherited control implementations. This will align with core NIST OSCAL.

With regards to the validation, we may need to split into two separate validations:

1. Validate that the description field exits AND is non-empty. A failure of either condition would result in an "error"
2. Validate that the description field length meets arbitrary length requirement (e.g. 32 characters). A failure would result in a "warning". This is a crude approach but it is generally unlikely that a control inheritance description would be so succinct, and a "warning" is not as severe as an "error" as it is meant to provide the content creator (or content consumer) feedback that a problem might exist.

The OSCAL guides, validations, and templates will need to be updated.

[Telos-sa]

In previous discussions with NIST and FedRAMP, we came up with a model during rev 4, where the by-component matching a leveraged component would suffice, and only that description would be required.

Has FedRAMP determined what information from a Leveraged authorization package is going to be provided to support the creation of the inherited description? How is this different than the description of the leveraged authorization component?

What content should be provided if the CSP is leveraging another package, but does not have access to the oscal SSP, or the CIS/CRM?