Discrepancy between FedRAMP Template and NIST Schema with regard to implementation-status

[telosBA]

• This is a ...

  • concern - I think something needs to be different.
  • 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)
  • 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

FedRAMP SSP Guide p.38
FedRAMP-SSP-OSCAL-Template.xml Line 1101
NIST OSCAL Schema

• What is your feedback?

For implementation status – FedRAMP leverages a prop underneath the implemented-requirement, but NIST has its own implementation-status within the by-component element within implementation-requirement. Why the deviation, was this an oversight?

FedRAMP also allows multiple values for implementation status, which deviates from NIST OSCAL. Is this a planned deviation, or should select 1 be strictly enforced (instead of partial and planned?) What is the mapping from current SSP requirement to OSCAL, for customers that are using the old versions?

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

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

Explain derivation from NIST schema or rectify Template.

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

[david-waltermire]

The core OSCAL implementation-status was intended to replace the FedRAMP one. This existed in FedRAMP prior to OSCAL 1.0.0. In preparing OSCAL 1.0.0, we generalized as much of the FedRAMP attributes as we could. Use of the OSCAL feature should be preferred. IMHO, this needs to be updated in the FedRAMP guides.

[aj-stein-nist]

Note, @volpet2014 we should discuss this as part of ongoing work where we ought to collaborate in #115.

[volpet2014]

Within the OSCAL-based FedRAMP baselines, control statements and control objectives are tagged with a response-point FedRAMP Extension. Every control statement designated as a response-point in the baseline must have a statement with the control's implemented-requirement assembly. Within each of the statement assemblies, all responses appear in one or more by-component assemblies. Each by-component assembly references a component defined in the system-implementation assembly. FedRAMP will accept multiple values for implementation status or a single overall implementation status for the control. FedRAMP is generating new templates and guidance from the resolved-profiles for Rev 5 so they will match directly to OSCAL and is planning an update to the Rev 4 templates to resolve mapping issues.