Generating Content from OSCAL-based SSP

The following artifacts are historically generated by hand to summarize content found in other portions of the FedRAMP SSP. When using OSCAL, these artifacts can be generated from content found elsewhere in this document. This includes the:

Control Information Summary (CIS)
Customer Responsibility Matrix (CRM)

If delivering SSP content in OSCAL, CSPs are no longer required to manually generate and maintain these artifacts, provided that the content in their OSCAL-based FedRAMP SSP remains accurate.

Tool developers are encouraged to develop their own solutions to generating this content.

Generating the Control Information Summary (CIS)

There are many ways a tool developer can generate the CIS. FedRAMP is developing an Extensible Stylesheet Language Transformation (XSLT) file to generate the FedRAMP CIS. When ready, FedRAMP will make this freely available to the public here:

https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/resources

Generating the Customer Responsibility Matrix (CRM)

There are many ways a tool developer can generate the CRM. FedRAMP plans to develop open-source tooling to generate the FedRAMP CRM. When ready, FedRAMP will make this freely available to the public on the FedRAMP Automation GitHub repository.

Useful CRM XPath Queries

1
2
3
4


  Flat-File CRM Query:
    //control-implementation/implemented-requirement/prop[@name="control-origination"][@ns="https://fedramp.gov/ns/oscal"][@value="customer-configured" or @value="customer-provided"]/remarks/node()
  Component-based CRM Query:
    //control-implementation/implemented-requirement/statement/by-component[@component-id="customer"]/description

Working with Components

OSCAL is designed such that a system architect can express all aspects of the system as components. A component is anything that can satisfy a control requirement. This includes hardware, software, services, and underlying service providers, as well as policies, plans, and procedures. There are several ways to use components in an OSCAL-based SSP. The following defines FedRAMP’s minimum initial use.

This section will likely be updated as OSCAL continues to evolve its approach to components, and as FedRAMP receives feedback from stakeholders.

FedRAMP-defined component identifiers are cited in relevant portions of this documentation and summarized in the FedRAMP OSCAL Registry.

Minimum Required Components

There must be a component that represents the entire system itself. It should be the only component with the component-type set to “this-system”.

The following is an example of a defined component.

Minimum Required Component Representation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<!-- system-characteristics -->
<system-implementation>
    <!-- user -->
    
    <!-- This System -->
    <component uuid="uuid-value" type="this-system" >
        <title>This System</title>
        <description><p>
            The entire system as depicted in the system authorization boundary.
        </p></description>
        <status state="operational" />
    </component>
    
</system-implementation>

Common Additional Components

For each FIPS 140 validated module, there must be a component that represents the service (e.g., cryptographic module, service, software, hardware, etc) that is validated, and another component of type validation that represents the validation certificate itself. A reference link with rel set to “validation” and href set to the UUID of the validation component must be used to specify the validation for the component.

Common Additional Component Representation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


<!-- system-characteristics -->
<system-implementation>
    <!-- user -->
    <!-- System Component -->
    
    <!-- Ports, Protocols and Services Entry -->
    <component uuid="uuid-of-service" type="service">
        <title>[SAMPLE]Service Name</title>
        <description><p>Describe the service</p></description>
        <purpose>Describe the purpose for which the service is needed.</purpose>
        <prop name="used-by" value="What uses this service?"/>
        <link rel="validation" href="#certificate-uuid-value"/>
        <status state="operational" />
        <protocol name="http">
            <port-range start="80" end="80" transport="TCP"/>
        </protocol>
        <protocol name="https">
            <port-range start="443" end="443" transport="TCP"/>
        </protocol>
    </component>
    
    <!-- FIPS 140 Validation Certificate Information -->
    <!-- Include a separate component for each relevant certificate -->
    <component uuid="certificate-uuid-value" type="validation">
        <title>Module Name</title>
        <description><p>FIPS 140 Validated Module</p></description>
        <prop name="validation-type" value="fips-140-2"/>
            <prop name="validation-reference" value="0000"/>
            <link href="https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/0000" />
            <status state="operational" />
    </component>
    
    <!-- service -->
</system-implementation>
<!-- control-implementation -->

Components as a Basis for System Inventory

OSCAL’s approach to component-based system modeling is to reduce redundancy of information and increase flexibility. OSCAL accomplishes this with separate component and inventory item modeling.

This is a one-to-many relationship: one component to many inventory item instances.

For example, if an open-source operating system (OS) is used in many places throughout the system, it is defined once as a component. All information about the product, vendor, and support are modeled within the component detail. If the OS is used four times within the system, each use is an inventory item, with the details pertain to each individual use, such as IP address.

Figure showing the relationship between components and inventory. — Relationship of Components and Inventory.

FedRAMP requires a component assembly for each model of infrastructure device used, and each version of software and database used within the system. FedRAMP is not asking for more detail than provided in the legacy inventory workbook, only that the information is organized differently.

As OSCAL continues to evolve its component approach, FedRAMP will re-evaluate its approach to system inventory representation.

Converting a Legacy SSP to OSCAL

OSCAL is also designed to support legacy conversion of SSPs without individual components defined and enables an SSP author to migrate to the component approach gradually over time. In this instance, only a single component is initially required, representing the system as a whole and designated with the special component type, “this-system”. The following provides an example of FedRAMP’s minimum required component approach:

Example control for legacy SSP conversion

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


<!-- system-characteristics -->
<system-implementation>
    <!-- Include a separate component for each relevant certificate -->
    <component uuid="uuid-value" type="this-system">
        <title>System Name</title>
        <description>
            <p>Component representing the entire system.</p>
        </description>
    </component>
</system-implementation>
<control-implementation>
    <description><p>FedRAMP SSP Template Section 13</p></description>
    <implemented-requirement control-id="ac-1" uuid="uuid-value">
        <statement statement-id="ac-1_stmt.a" uuid="uuid-value">
            <by-component component-uuid="Component-uuid-value" uuid="uuid-value">
                <description>
                    <p>Describe how Part a is satisfied within the system.</p>
                </description>
            </by-component>
        </statement>
        <statement statement-id="ac-1_stmt.b.1" uuid="uuid-value">
            <by-component component-uuid="Component-uuid-value" uuid="uuid-value">
                <description>
                    <p>Describe how Part b 1 is satisfied within the system.</p>
                </description>
            </by-component>
        </statement>
        <statement statement-id="ac-1_stmt.b.2" uuid="uuid-value">
            <by-component component-uuid="Component-uuid-value" uuid="uuid-value">
                <description>
                    <p>Describe how Part b 2 is satisfied within the system.</p>
                </description>
            </by-component>
        </statement>
    </implemented-requirement>
</control-implementation>

Relationship of Components and Inventory.