Skip to main content

Control Response: Policies and Procedures

The first control in each NIST SP 800-53 control family is a policy and procedure control. These are sometimes refered to as "the dash one controls". (AC-1, AT-1, AU-1, etc.)

FedRAMP does not permit these controls to be inherited. As a result, every one of these controls must be associated with at least one attached policy and at least one attached procedure. Also, the control origination for these must always be corporate, system-specific, or both.

When using a FedRAMP Resolved Profile Catalog, the following query will identify the response points for a given control.

XPath Query
Response Points for AC-1:
    //control[@id='ac-1']/part[@name='statement']//prop[@name='response-point'][@ns='http://fedramp.gov/ns/oscal']/../@id

Organization: Policy and Procedure Statements

For each of the -1 controls, such as AC-1, there must be exactly four statement assemblies: Part (a)(1), Part (a)(2), Part (b)(1), and Part (b)(2).

Policy and Procedure Representation
<!-- system-implementation -->
<control-implementation>
    <!-- cut -->
    <implemented-requirement uuid="uuid-value" control-id="ac-1">
        <statement statement-id="ac-1_smt.a.1"><!-- cut --></statement>
        <statement statement-id="ac-1_smt.a.2"><!-- cut --></statement>
        <statement statement-id="ac-1_smt.b.1"><!-- cut --></statement>
        <statement statement-id="ac-1_smt.b.2"><!-- cut --></statement>
    </implemented-requirement>
</control-implementation>

Response: Overview

Within each statement assembly, all responses must be provided within one or more by-component assemblies. There must always be a component defined in the system-implementation representing the system as a whole ("THIS SYSTEM"), even if individual components are defined that comprise the system. See the Working with Components section for more information.

An OSCAL-based FedRAMP SSP should define individual components of the system. Components are not just hardware and software. Policies, processes, FIPS 140 validation information, interconnections, services, and underlying systems (leveraged authorizations) are all components.

With OSCAL, the content in the cell next to Part a must be broken down into its individual components and responded to separately.

SSP Template Security Control Description

  • For Part a
    • Component - This System
      • Describes how part a is satisfied holistically, or where the description does not fit with a defined component.
    • Component - Platform
      • Describes how part a is satisfied by the platform.
    • Component - Web-Server
      • Describes how part a is satisfied by the web server.
    • Component - Process
      • Describes how part a is satisfied by an identified process within this organization.
    • Component - Inherited
      • Describes what is inherited from the underlying Infrastructure as a Service (IaaS) provider to satisfy part a.
  • For Part b
    • Component - This System
      • Describes how part b is satisfied holistically, or where the description does not fit with a defined component.
    • Component - Platform
      • Describes how part b is satisfied by the platform.
    • Component - Web-Server
      • Describes how part b is satisfied by the web server.
    • Component - Process
      • Describes how part b is satisfied by an identified process within this organization.
    • Component - Inherited
      • Describes what is inherited from the underlying Infrastructure as a Service (IaaS) provider to satisfy part b.

The following are examples.

Response: "This System" Component

There must always be a "This System" component in the SSP. This is used in several ways:

  • Holistic Overview: The SSP author may wish to provide a more holistic overview of how several components work together, even if details are provided individually in other by-component assemblies.

  • Catch-all: Any control response that does not cleanly align with another system component may be described in the "This System" component.

  • Legacy SSP Conversion: When converting a legacy SSP to OSCAL, the legacy control response statements may initially be associated with the "This System" component until the SSP author is able to provide responses for individual components.

{{< figure src="/img/ssp-figure-38.png" title="SSP Template Security Control Response" alt="Figure illustrating how legacy SSP template control response is broad and should apply to the 'this-system' component in OSCAL." >}}

Representation
<system-implementation>
    <!-- leveraged-authorization, user -->
    <component uuid="uuid-value" type="this-system">
        <title>This System</title>
        <description>
            <p>Description of the component.</p>
        </description>
        <status state="operational"/>
    </component>
</system-implementation>

<control-implementation>
    <!-- cut -->
    <implemented-requirement uuid="uuid-value" control-id="ac-2">
        <statement uuid="uuid-value" statement-id="ac-2_smt.a">
            
            <by-component uuid="uuid-value" component-uuid="uuid-of-this-system-component">
                <description>
                    <p>Describe how individual components are working together.</p>
                    <p>Describe how the system - as a whole - is satisfying this statement.</p>
                    <p>This can include policy, procedures, hardware, software, etc.</p>
                </description>
            </by-component>
            
        </statement>
        <!-- repeat statement assembly for statement part (b, c, etc.) as needed. -->
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->

NOTES:

  • Although the name of the component is "This System", non-technical solutions may also be discussed here, such as policies and procedures.

Linking to Artifacts

Any time policies, procedures, plans, and similar documentation are cited in a control response, they must be linked.

For the legacy approach, when responding within the by-component assembly for "this system", the link must be within the same by-component assembly where the artifact is cited.

{{< figure src="/img/ssp-figure-39.png" title="SSP Template Security Control Response" alt="Figure illustrating how legacy SSP template control response should link to the appropriate artifact." >}}

Representation: Legacy Approach Example - No Policy Component
<control-implementation>
    <implemented-requirement uuid="uuid-value" control-id="ac-1">
        <statement uuid="uuid-value" statement-id="ac-1_smt.a">
            <by-component component-uuid="uuid-of-this-system" uuid="uuid-value">
                <description>
                    <p>Describe how Part a is satisfied within the system.</p>
                </description>
                <link href="#uuid-of-policy-resource-in-back-matter" rel="policy" />
            </by-component>
        </statement>
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->

For the component approach, use the component representing the policy. The link should be in the component, but may be added directly to the by-component as well.

Representation: Component Approach Example
<system-implementation>
    <!-- leveraged-authorization, user -->
    <component uuid="uuid-value" type="policy">
        <title>Access Control and Identity Management Policy</title>
        <description>
            <p>An example component representing a policy.</p>
        </description>
        <link href="#uuid-of-policy-resource-in-back-matter" rel="policy" />
        <status state="operational"/>
    </component>
</system-implementation>
<control-implementation>
    <implemented-requirement uuid="uuid-value" control-id="ac-1">
        <statement uuid="uuid-value" statement-id="ac-1_smt.a">
            <by-component component-uuid="uuid-of-policy-component" uuid="uuid-value">
                <description>
                    <p>Describe how this policy satisfies Part a.</p>
                </description>
            </by-component>
        </statement>
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->

For either example above, the policy must be present as a resource in back-matter.

In Back Matter
<back-matter>
    <resource uuid="uuid-value">
        <title>Access Control and Identity Management Policy</title>
        <rlink media-type="application/pdf" href="./documents/policies/sample_policy.pdf" />
        <base64 filename="sample_policy.pdf" media-type="application/pdf">00000000</base64>
    </resource>
</back-matter>

No comments to display

Back to top