[Question]: Clarification on Response Points and _prm Parameter Placement

[JoseGHdz]

This is a ...

question - need to understand something

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 is your feedback?

Clarification on Response Points and _prm Parameter Placement

I’ve been working on configuring the required constraints and encountered the following error:

[ERROR] [/catalog/group[1]/control[1]/part[1]] has-required-response-points: All Response points defined in the baseline MUST have corresponding statements values in the SSP. Missing statement: (ac-1_smt).

This error suggests that the general statement for the control is missing under statements in implemented-requirements (not including the control parts). However, while reviewing the example in the FedRAMP SSP Example, I noticed something different—specifically, that _prm parameters are included under set-parameters within the control statement itself under the by-components and not set-parameters under implemented-requirements.

This led me to question whether I’m using the correct import profile. The profile I was advised to use temporarily is: Import Profile

However, using this profile has resulted in a warning related to _prm parameters:

[WARNING] [/system-security-plan/control-implementation[1]/implemented-requirement[1]/set-parameter[1]] aggregate-parameters-warning: A FedRAMP SSP SHOULD NOT set aggregate parameters directly. Parameter ac-1_prm_1 is an aggregate parameter that should not be set in the SSP.

From what I understand, _prm parameters should be placed under by-component within the control statement rather than set-parameters. I’d like to confirm:

1. Should _prm parameters only be placed within by-component under the control statement?
2. Am I using the correct import profile for this implementation?

Any guidance on this would be greatly appreciated.

Update

I tested by placing the _prm parameter in the 'by-components' of the control statement and I got the same warning message of the aggregate parameters.

Where, exactly?

This relates to the _prm parameters and the import profile linked above.

Other information

No response

[aj-stein-gsa]

I’ve been working on configuring the required constraints and encountered the following error:

[ERROR] [/catalog/group[1]/control[1]/part[1]] has-required-response-points: All Response points defined in the baseline MUST have corresponding statements values in the SSP. Missing statement: (ac-1_smt).

This error suggests that the general statement for the control is missing under statements in implemented-requirements (not including the control parts). However, while reviewing the example in the FedRAMP SSP Example, I noticed something different—specifically, that _prm parameters are included under set-parameters within the control statement itself under the by-components and not set-parameters under implemented-requirements.

This led me to question whether I’m using the correct import profile. The profile I was advised to use temporarily is: Import Profile

However, using this profile has resulted in a warning related to _prm parameters:

[WARNING] [/system-security-plan/control-implementation[1]/implemented-requirement[1]/set-parameter[1]] aggregate-parameters-warning: A FedRAMP SSP SHOULD NOT set aggregate parameters directly. Parameter ac-1_prm_1 is an aggregate parameter that should not be set in the SSP.

From what I understand, _prm parameters should be placed under by-component within the control statement rather than set-parameters. I’d like to confirm:

1. Should _prm parameters only be placed within by-component under the control statement?
2. Am I using the correct import profile for this implementation?

@JoseGHdz re 1 and 2 it appears you are implementing against the correct approach. However, the warnings and errors indicate you should not use "aggregate parameters" (ac-1_prm_1) but rather the individual ODP parameters (ac-01_odp.01; ac-01_odp.02; et cetera). The former aggregates the latter. I hope that helps but I know that is a very simplified answer. We are working towards updating and publishing documentation.

[aj-stein-gsa]

I'll mark this blocked until the author of the issuer replies to confirm that answers their question or they need more details and assistance to fully answer the question.