Skip to main content

Parameter Assignments

Need rework and to cover aggregated parameters

Every applicable control must have at least one responsible-role defined. There must be a separate responsible-role assembly for each responsible role. OSCAL requires the specified role-id to be valid in the defined list of roles in the metadata. Controls with a FedRAMP implementation-status property value of "non-applicable" (see the Implementation Status section) do not require a responsible-role. FedRAMP further requires that the specified role-id must also have been referenced in the system-implementation user assembly. This equates to the FedRAMP requirement of all responsible roles appearing in the Personnel Roles and Privileges table.

SSP Template Security Control Parameter Assignments

Representation

WithIf thea FedRAMP control has one or more parameters, add a set-parameters array Within an implemented-requirementrequirements assembly,entry. thereThere must be one set-parameterparameters statemententry for each of the control's parameters, as specifiedparameter in the control as follows:

  • a param-id set to the parameter value from the OSCAL-based FedRAMP baselinebaselines
  • a values array with:
    • one string entry per response
    • If the response is list, such as a list of user types to receive a procedure, add one entry per list item.
Only set parameters at the `implemented-requirements` level. While OSCAL also supports the ability to set parameters within `by-components` entries, this does not align with FedRAMP's handling of parameters and illustratedshould not be used. 

system-security-plan:
  control-implementation:
    implemented-requirements:
    - uuid: 11111111-2222-4000-8000-012000010000
      control-id: ac-1
      set-parameters:

      - param-id: ac-01_odp.01
        values:
        - all managers, administrators and users of the system

      - param-id: ac-01_odp.02
        values:
        - all managers and administrators of the system

      - param-id: ac-01_odp.03
        values:
        - System-level

      - param-id: ac-01_odp.04
        values:
        - System Architect

      - param-id: ac-01_odp.05
        values:
        - at least every 3 years
      
      - param-id: ac-01_odp.06
        values:
        - change in theorganizational examplelegal representationstatus below.or Theownership

      only- exceptionparam-id: toac-01_odp.07
        thisvalues:
        is- withat nestedleast parameters.annually

      - param-id: ac-01_odp.08
        values:
        - change in policy or a security incident involving a failure of access control
          mechanisms

Selection Parameters and Nested Parameters

Some select parameters contain anone or more assignment parameterparameters. In this instance, simply provide the final selection value within the set-parameters entry for the select and omit any set-parameters entries related to the assignment.

Example

AC-7_ part (b) has three assignment parameters nested within a single selection parameter,parameter. suchLine asbreaks appearsand inbullets AC-7have been added below to better illustrate the nesting.

Automatically

  • [Selection (b).one Inor thesemore): instances,
    • lock the account or node for an [Assignment: organization-defined time period];
    • lock the account or node until released by an administrator;
    • delay next logon prompt per [Assignment: organization-defined delay algorithm];
    • notify system administrator;
    • take other [Assignment: organization-defined action]]

when the maximum number of unsuccessful attempts is exceeded.

Although the OSCAL controls will have four parameters, only the final selected value mustfor bethe provided.selection parameter is assigned in the SSP. The nestedother assignmentparameters parameter may beare ignored.

OSCALIf alsomore supportsthan parameterone settingchoice atis is applicable, add each as a separate entry in the componentvalues level,array. withinFor aexample if the final choices are:

  • lock the account or node for an [Assignment: 30 minutes];
  • lock the account or node until released by an administrator;

The by-componentset-parameters assembly.array would be:

Representation
<metadata>
<rolesystem-security-plan:
  id="admin-unix">control-implementation:
    <title>Uniximplemented-requirements:
    Administrator</title>
    </role>
</metadata>
<!-- Fragment:uuid: 11111111-2222-4000-8000-012000010000
      control-id: ac-7
      set-parameters:

      --> <system-implementation>param-id: <userac-07_odp.03
        uuid="uuid-value">values:
        <role-id>admin-unix</role-id>
    </user>
</system-implementation >
<!-- system-implementationlock the account or node for 30 minutes; 
        --> <control-implementation>lock <implemented-requirementthe uuid="uuid-value"account control-id="ac-2">or <!--node cutuntil -->released <responsible-roleby role-id="admin-unix"an />
        <set-parameter param-id="ac-2_prm_1">
            <value>System Manager, System Architect, ISSO</value>
        </set-parameter >
        <!-- cut -->
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->administrator;
XPath

Parameters Queries

ac-07_odp.01 
and Numberac-07_odp.02 belong to part (a). They would normally be included and are only omitted for the example.


Parameters ac-07_odp.04, ac-07_odp.05 and ac-07_odp.06 are part of specified Responsible Roles:
    count(/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role)
  Responsible Role:
    /*/metadata/role[@id=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role[1]/@role-id]/title
  Check for existence in Personnel Roles07_odp.03 and Privilegesare (Shouldomitted.

return a number > 0)
    count(/*/system-implementation/user/role-id[string(.)=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role/@role-id])
  Parameter Value:
    /*/control-implementation/implemented-requirement[@control-id="ac-2"]/set-parameter [@param-id="ac-2_prm_1"]/value
Back to top