[Feedback]: Potential mismatch of parameters between baselines and templates for Rev5

[vmangat]

This is a ...

question - need to understand something

This relates to ...

• [ ] the FedRAMP OSCAL Registry
• [X] 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 is your feedback?

The Rev5 Templates seem to be asking for parameters input at the aggregate parameter level (PRM ids) , while the baselines are documenting constraints at the ODP level. We need guidance on Aggregate parameters, where the OSCAL based SSP should consider the aggregate parameter (PRM) or split up and document sub parameters separately (odp).

Where, exactly?

Templates - for AC-1 first parameter, the templates ask for the parameter as "Parameter AC-1(a)" which maps to the aggregate parameter id "ac-1_prm_1". This parameter has two sub parameters in the OSCAL catalog "ac-01_odp.01 and ac-01_odp.02"

FedRAMP OSCAL rev5 Baseline - the baselines are providing constraints at the odp granularity level

If the OSCAL SSP is to be built at the sub parameters level (odp) then there will be a data migration challenge for CSPs that have filled out the Rev5 template. If the OSCAL SSP is to be built out at the aggregate parameter level then the sub parameter breakdown will be ignored.

Other information

Included are the screen shot of the AC-1 example from the templates, catalog and baseline respectively.

[Rene2mt]

FedRAMP OSCAL SSPs must provide the granular “ODP” level parameters. This will be clarified in the FedRAMP OSCAL SSP User Guide and sample FedRAMP OSCAL SSP template.

Additionally, FedRAMP will develop documented guidelines around generating SSP Word Templates . For example:

• How should parameters be displayed in printables? Aggregated or as individual ODPs?
• What parameter identifiers should be displayed in printables (e.g., sp800-53a label such as AC-01_ODP[01])?

[Rene2mt]

Attached is a proposed layout for OSCAL generated SSP control content. As illustrated in the mockup document:

• The control statements must include the parameter insertion points (e.g. [Assignment: organization-defined personnel or roles])
• The control information summary table must display the "Parameter" and "Value" for each applicable ODP
  • The parameter must show the ODP identifier
  • The parameter should show the parameter description so the reader has context
  • The parameter value must be provided

This approach is slightly different from the currently published FedRAMP (rev 5) SSP template, however, it contains all the details that would be provided in that template and augments it with additional information and layout formatting provide a clearer mapping back to the appropriate ODPs.

Mockup of FedRAMP SSP Control with ODPs.pdf

[vmangat]

For an SSP that is developed from OSCAL catalogs and profiles, the document will look fairly different.... all controls statements are presented as available in the OSCAL files....

Here is a printable sample of what AC-1 would look like, and how we suggest aggregate parameters be presented:

Here is a printable sample of a control which has a Choice parameter with a selection that includes another parameter:

[Rene2mt]

We had explored an option very similar to what you posted but the review teams felt it would be difficult for (human) reviewers to track what the parameter requirements are if they are not displayed inline in the control (as shown in the example below). From the reviewer's perspective, it is important to know what the parameter is asking for (e.g., organizational defined personnel and roles) as well as what the parameter value specified by the CSP (e.g., Security personnel, system administrators, technical staff).

Perhaps a combination of the parameter label and odp ID should be rendered in the control description, that way reviewers know what the parameter is looking for and reference the (ODP) value in the control summary information table.

[gregelin]

How best to represent the relationship between the Organizational Defined Parameters (ODP) formats is a very difficult question.

It would be helpful to see a suggested representation across multiple examples and scenarios.

The above example of "Option 5" by @Rene2mt only shows one example. It's not clear how "Option 5" handles "ac-1_prm_1 / ac-1_odp_1" and "ac-1_prm_1 / ac-1_odp_2" from @vmangat example.

Also, we now see ac-01_odp.01 vs ac-1_odp_1 in these examples in this thread. Speaking for myself, I'm now confused and feel like I have to go back to source documents to see what's going on. I often feel like it's necessary to go back to source documents just to follow a thread like this. That's an awful lot of friction and suggests perhaps a clearer, less ambiguous solution is waiting to be found.

I personally read the find the slash separator "/" to be useful as an indicator of alternate valid choice OR indicating a path separation. That seems to work for handling parameters that are further split into other parameters or assessment values.

The bracket representation "[ ]" seems more ambiguous as brackets in English represent an implicit item made explicit separate from rest of text, OR in programming an array of items, or range. Since the format of ac-01_odp.01 is removing parentheses from Parameter AC-1(a), it seems odd to be re-introducing closure markings of braces "[ ]".

Another solution is to simply represent three columns in the table: Parameters | OSCAL Identifier | Value.

(I'm working on an example, but want to leave this comment.)

[Rene2mt]

Thanks for the feedback @gregelin. We are working on revised and expanded examples to show several different scenarios. I do want to share the requirements that we sought to address with the prior example we provided (Mockup of FedRAMP SSP Control with ODPs.pdf):

• Parameter - The FedRAMP PMO reviewers we talked to found it useful to show this as the parameter control part reference (e.g., AC-1(a)). This gives them a simple, human readable reference to what control statement part the parameter is addressing, comparable to what they are used to seeing in the current template SSP documents. This is challenging and may require adding some new FedRAMP extensions in the profiles (e.g. <prop name="label" class="fedramp" value="AC-1(a)" /> or <prop name="param-label" ns="https://fedramp.gov/ns/oscal" value="AC-1(a)" />).
• Parameter Label / Guideline - In the mockup example PDF, you'll also see the parameter label / guideline in the parameter table cells. This was intended to give the reviewers additional context and can be pulled from the catalog or resolved profile catalog imported by the SSP.
• ODP mapping - We added the ODPs (e.g., ac-01_odp.01) in the square brackets because other reviewers (e.g. 3PAOs) that are testing the controls based on NIST SP800-53a assessment procedures need to be able to map with certainty back to the ODPs.
  • There are many possible ways to display this aside from square brackets. The forward slash (/), separate column, all seem like reasonable approaches. We are open to suggestions.
  • Any reference to ODP identifies must be consistent with what is specified in the source catalog. I believe ac-01_odp.01 is whereas ac-1_odp_1 is not.
• ODP Value - This is the value specified by SSP author (e.g., for AC-1(a), we might have "Security personnel, system administrators, etc.").

The examples attached (Mockup of FedRAMP SSP Control with ODPs.pdf) shows in-line parameter label/guidance (highlighted orange). Again, this is to provide the reviewers a full understanding of the control and parameters as they review the CSPs control implementation statements and specified parameter values. However, we acknowledge that some parts of mocked in-line parameters (e.g. "Assignment" vs "FedRAMP Assignment"; Selection (one-or-more), etc.) pose a challenge. We are working on examples on how the proposed output could be achieved, although it might require some enabling FedRAMP extensions in some cases.