Skip to main content

Responsible Roles

Every applicable control mustshould have at least one responsible-roleor 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 allmore responsible roles appearing in the Personnel Roles and Privileges table.identified.

ssp-figure-32.pngssp-r5-control.png

WithIn OSCAL, there are three options for identifying responsible roles:

  • By Control: (Retrofit MVP only) assign responsible roles to the implemented-requirement assembly, there must be one set-parameter statement for each of the control'sentire parameters,control
    • as
  • By specifiedComponent (Implied): infer responsible roles from the components cited in the FedRAMP baseline and illustrated in the example representation below. The only exception to this is with nested parameters. Some select parameters contain an assignment parameter within a selection parameter, such as appears in AC-7 (b). In these instances, only the final selected value must be provided. The nested assignment parameter may be ignored.

    OSCAL also supports parameter setting at the component level, within a by-component assembly.array

  • By Component (Explicit): assign responsible roles to the statement/by-component array

Retrofit Adoption Path: MVP

When initially converting a Word-based FedRAMP SSP to OSCAL, assign all roles by control to the implemented-requirements/responsible-roles array. This aligns with the FedRAMP Word-based SSP template.

As the SSP is migrated to a normalized approach using components, the assignment of roles is moved from the entire control to statement-level, component responses.

With fully normalized OSCAL content, responsible roles are inferred via the components associated with a control via statements/by-components. Each assocaited component SHOULD have owner and administrator responsible roles and linked to specific parties (teams or individuals).

If additional roles need to be cited, they are explicilty assigned to by-components/responsible-roles. If an explicitly needed role does not associate cleanly to a specific component, it is assigned to the by-components/responsible-roles entry for this system (component type=this-system).

WORKING HERE

Representation
<metadata>
    <role id="admin-unix">
        <title>Unix Administrator</title>
    </role>
</metadata>
<!-- Fragment: -->
<system-implementation>
    <user uuid="uuid-value">
        <role-id>admin-unix</role-id>
    </user>
</system-implementation >
<!-- system-implementation -->
<control-implementation>
    <implemented-requirement uuid="uuid-value" control-id="ac-2">
        <!-- cut -->
        <responsible-role role-id="admin-unix" />
        <set-parameter param-id="ac-2_prm_1">
            <value>System Manager, System Architect, ISSO</value>
        </set-parameter >
        <!-- cut -->
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->
XPath Queries
Number 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 Roles and Privileges (Should 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