Discrepancy between FedRAMP SSP Guide, SSP Baseline, and OSCAL Schema with regard to Control Origination

[telosBA]

• This is a ...

  • [x] concern - I think something needs to be different.
  • [x] question - I didn't understand something.
  • [ ] kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • [ ] request - I would like to see something additional provided.

• This relates to ...

  • [ ] the FedRAMP OSCAL Registry (Excel File)
  • [ ] the Guide to OSCAL-based FedRAMP Content (PDF)
  • [x] the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • [ ] the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • [ ] 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)
  • [ ] General/Overall
  • [ ] Other

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

• Where, exactly?
  • For the registry, please indicate the tab and cell, or other clear identifier
  • For the guide, please indicate the section number and printed page number (lower right corner)
  • For the OSCAL XML or JSON files, please indicate XML or JSON; and indicate the line number, field id, or other clear location identifier

SSP Guide p. 39 OSCAL Schema

• What is your feedback?

• What version of OSCAL are you using? (Check our info on supported OSCAL versions)

1.0.2

• What action would you like to see from the FedRAMP PMO?

There is a discrepancy between FedRAMP SSP Guide and SSP Baseline with regard to Control Origination, namely: Baseline includes "Shared" while FedRAMP Guide does not. Is there mapping to identify which original source of truth now maps to the new models?

FedRAMP's values also differ from those defined in the OSCAL Schema under <control-implementation> <implemented-requirement> <prop> name="control-origination" in naming standard and selection abilities. Why can there be multiple selections by FedRAMP standards when NIST requires 1? Is this a deviation that requires NIST OSCAL update in schema, or is it expected to deviate?

What is the mapping from current SSP requirement to OSCAL, for customers that are using old versions?

• Other information (e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, eg. slack, gitter, etc)

[david-waltermire]

Core OSCAL allows the following control-orignation values:

• organization: The control is implemented by the organization owning the system, but is not specific to the system itself.
• system-specific: The control is implemented specifically to this system.
• customer-configured: The control is provided by the system, but must be configured by the customer.
• customer-provided: The control must be implemented by the customer.
• inherited: This control is inherited from an underlying system.

FedRAMP defines the following values in their namespace:

• sp-corporate
• sp-system
• customer-configured
• customer-provided
• inherited

According to the guide "hybrid" can be defined by combining sp-corporate and sp-system in two different props.

OSCAL also allows more than one prop to be used for control origin.

FedRAMP OSCAL Value	Core OSCAL Value
sp-corporate	organization
sp-system	system-specific
customer-configured	customer-configured
customer-provided	customer-provided
inherited	inherited

IMHO, this allows the text in the FedRAMP control summary to be realized as follows using core OSCAL:

FedRAMP Control Origination	Core OSCAL Value(s)
Service Provider Corporate	organization
Service Provider System Specific	system-specific
Service Provider Hybrid	organization + system-specific
Configured by Customer	customer-configured
Provided by Customer	customer-provided
Shared	One or more of (organization, system-specific) and one or more of (customer-configured, customer-provided)
Inherited from pre-existing...	inherited

Based on this analysis, I believe the FedRAMP namespaced values can be deprecated in favor of the core OSCAL values. This requires an update to the FedRAMP guide.

[Telos-sa]

Confirmed that this is still an issue with the validator. Wanted to know if this is going to be addressed in rev 5.
Expect there to be errors for every control, which is making the validation report very noisy.
Validations.zip

[Telos-sa]

Good Afternoon, Wanted to see if there is any updated for this element. In Rev 5, the legacy SSP and the OSCAL ssp continue to have competing requirements, where the Legacy Control Origination's are still in effect, and the sp-corporate and sp-system elements have not been updated to the NIST formatting in the requirements document.

Requesting guidance for how to handle. Should we: For legacy SSP

1. Use the legacy terminology
2. Use the FedRAMP OSCAL terms
3. Use the NIST OSCAL (Recommend for reciprocity)

For OSCAL SSP

1. Use Legacy terminology
2. Use the FedRAMP OSCAL terms with fedramp namespace
3. Use the NIST OSCAL with Nist Namespace (recommend for reciprocity)

When looking at the options, and FedRAMP allowing for re-combinations, is there planned restrictions on which combinations should be allowed?

Recommended combinations: <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

Combinations | Reasoning -- | -- organization, system-specific | Identifies Hybrid inherited, system-specific | identifies shared responsibility model upstream inherited, customer-configured | Identifies shared responsibility model upstream, and downstream