FedRAMP OSCAL Appendices & Attachments

Classic FedRAMP attachments include a mix of items. Some lend well to machine-readable format, while others do not. Machine-readable content is typically addressed within the OSCAL-based FedRAMP SSP syntax, while policies, procedures, plans, guidance, and the rules of behavior documents are all treated as classic attachments, as described in the Attachments and Embedded Content section. The resource’s title and description must be used to provide a human-readable indicator of what attachment is being referenced; however, OSCAL extensions must also be provided when applicable for machine readability. The following table describes how each attachment is handled:

Appendix Name Machine Readable How to Handle in OSCAL
Appendix A: FedRAMP Security Controls Yes This can be generated from the content in the Security Controls section and does not need to be maintained separately or attached.
Appendix B: Related Acronyms No Attach using the back-matter, resource syntax.

For Acronyms, resource must include a prop with @ns="http://fedramp.gov/ns/oscal", @name="type", and @value="fedramp-acronyms".
Appendix C: Security Policies and Procedures No Attach using the back-matter, resource syntax.

For Policies, resource must include a prop with @name=”type”, @value=”policy”, and @class=”control-family”.

For Procedures, resource must include a prop with @name=”type”, @value=”procedure”, and @class=”control-family”.
Appendix D: User Guide No Attach using the back-matter, resource syntax.

For User Guides, resource must include a prop with @name=”type” and @value=”users-guide”.
Appendix E: Digital Identity Worksheet Yes See the Digital Identity Determination section.
Appendix F: Rules of Behavior No Attach using the back-matter, resource syntax.

For Rules of Behavior, resource must include a prop with @name=”type” and @value="rules-of-behavior".
Appendix G: Information System Contingency Plan (ISCP) No Attach using the back-matter, resource syntax.

For ISCP, resource must include a prop with @name=”type”, @value="plan", and @class="information-system-contingency-plan".
Appendix H: Configuration Management Plan (CMP) No Attach using the back-matter, resource syntax.

For CMP, resource must include a prop with @name=”type”, @value="plan", and @class="configuration-management-plan".
Appendix I: Incident Response Plan (IRP) No Attach using the back-matter, resource syntax.

For IRP, resource must include a prop with @name=”type”, @value="plan", and @class="incident-response-plan".
Appendix J: CIS and CRM Workbook Yes This can be generated from the content in the Security Controls section and does not need to be maintained separately or attached.
Appendix K: FIPS 199 Worksheet Yes See the System Sensitivity Level (FIPS-199) section.
Appendix L: CSO-Specific Required Laws and Regulations No Attach using the back-matter, resource syntax.

For CSO-Specific Required Laws and Regulations, resource must include a prop with @name=”type” and @value=”law”.
Appendix M: Integrated Inventory Workbook Yes See the System Inventory section.
Appendix N: Continuous Monitoring Plan No Attach using the back-matter, resource syntax.

For ConMon, resource must include a prop with @name=”type”, @value="plan", and @class="continuous-monitoring-plan".
Appendix O: POA&M Yes This is maintained separately in an OSCAL POA&M but can be attached using the back-matter, resource syntax.

For POA&M, resource must include a prop with @name=”type”, @value="plan", and @class="poam".
Appendix P: Supply Chain Risk Management Plan (SCRMP) No Attach using the back-matter, resource syntax.

For SCRMP, resource must include a prop with @name=”type”, @value="plan", and @class="scrmp".
Appendix Q: Cryptographic Module Table Yes See the Cryptographic Modules section dealing with components.

Attachments

The following OSCAL representation of a FedRAMP SSP attachment demonstrates the back-matter and resource approach that must be implemented for classic SSP attachments that are not machine-readable, such as policies, procedures, plans, guidance, and rules of behavior documents.

Attachment Representation
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

<!-- cut -->
<back-matter>
    <resource uuid="uuid-value">
        <title>Document Title</title>
        <desc>Policy document</desc>
        <prop name="type" ns="http://fedramp.gov/ns/oscal" value="policy"/>
        <prop name="publication" ns="http://fedramp.gov/ns/oscal" value="2021-01-01Z"/>
        <prop name="version" ns="http://fedramp.gov/ns/oscal" value="1.2"/>
        <!-- Add rlink with relative path or embed with base64 encoding -->
        <base64>00000000</base64>
    </resource>
    <resource uuid="uuid-value" />
    <!-- cut: policies 3 - 13 -->
    <resource uuid="uuid-value" />
    <resource uuid="uuid-value" />
    <!-- cut: procedure 2 - 13 -->
</back-matter>
XPath Queries
1
2
3
4
5
6
7
8

  The Number of Policies Attached:
    count(/*/back-matter/resource/prop[@name="type"][@ns="http://fedramp.gov/ns/oscal"][string(./@value)="policy"])
  Attachment (Embedded Base64 encoded):
    /*/back-matter/resource[@id="att-policy-1"]/base64
  OR (Relative Link):
    /*/back-matter/resource[@id="att-policy-1"]/rlink/@href
  Title of First Policy Document:
    /*/back-matter/resource/prop[@name="type"][@ns="http://fedramp.gov/ns/oscal"][string(.)="policy"][1]/../prop[@name="title"][@ns="http://fedramp.gov/ns/oscal"]

System Inventory Approach

Screenshot of the Integrated Inventory Workbook in the FedRAMP SSP template.

FedRAMP SSP template Integrated Inventory Workbook.

OSCAL makes two approaches available for depicting the system inventory:

  • Flat-File Approach: Similar to today’s FedRAMP Integrated inventory workbook where all of the information on a spreadsheet row is captured in a single assembly.

  • Component-Based Approach: A component is defined once with as much known detail as possible, and inventory-items point to components for common information.

FedRAMP prefers the component-based approach but accepts the flat-file approach to aid CSPs who are converting their existing MS-Excel based FedRAMP Integrated Inventory Workbook to OSCAL. FedRAMP SSP tools must support both approaches.

Figure illustrating the 'flat-file' inventory approach where each inventory spreadsheet row is represented as a single OSCAL inventory-item.

FedRAMP OSCAL flat-file inventory approach.

With the flat-file approach, all content on a spreadsheet row appears in a single OSCAL inventory-item assembly. This results in a great deal of redundant information but is a simple transition from the current spreadsheet approach.

Figure illustrating the 'component-based' inventory approach where common information is captured once in a component, and each instance of that component has its own inventory-item.

FedRAMP OSCAL component-based inventory approach.

With the component-based approach, common information is captured once in a component assembly. Each instance of that component has its own inventory-item assembly, which cites the relevant component and only includes information unique to that instance.

For example, if the same Linux operating system is used as the platform for all database and web servers, most of the details about the Linux operating system can be captured once as a component. This includes information such as vendor name, version number, and patch level. If four Linux instances are used, each instance is an inventory item with a unique IP address and MAC address. Only those unique pieces are captured at the inventory level. All four inventory-items point back to the component for vendor name, version number, and patch level.

Flat File Approach

Flat-File 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
36
37
38
39
40
41
42
43
44
45
46
47

<!-- cut -->
<system-implementation>
    <!-- interconnection -->
    <system-inventory>
        <inventory-item uuid="uuid-value" asset-id="unique-asset-id">
            <description><p>Flat-File Example (No implemented-component).</p></description>
            <prop name="ipv4-address" value="0.0.0.0"/>
            <prop name="ipv6-address" value="0000:0000:0000:0000"/>
            <prop name="virtual" value="no"/>
            <prop name="public" value="no"/>
            <prop name="fqdn" value="example.com"/>
            <prop name="uri" value="https://example/query?key=value#anchor"/>
            <prop name="netbios-name" value="netbios-name"/>
            <prop name="mac-address" value="00:00:00:00:00:00"/>
            <prop name="software-name" value="software-name"/>
            <prop name="version" value="V 0.0.0"/>
            <prop name="asset-type" value="os"/>
            <prop name="vendor-name" value="Vendor Name"/>
            <prop name="model" value="Model Number"/>
            <prop name="patch-level" value="Patch-Level"/>
            <prop name="serial-number" value="Serial #"/>
            <prop name="asset-tag" value="Asset Tag"/>
            <prop name="vlan-id" value="VLAN Identifier"/>
            <prop name="network-id" value="Network Identifier"/>
            <prop name="scan-type" ns="http://fedramp.gov/ns/oscal" value="infrastructure"/>
            <prop name="allows-authenticated-scan"  value="no">
                <remarks><p>If no, explain why. If yes, omit remarks field.</p></remarks>
            </prop>
            <prop name="baseline-configuration-name" value="Baseline Config. Name" />
            <prop name="physical-location" value="Physical location of Asset" />
            <prop name="is-scanned" value="yes"/>
            <prop name="function" value="Required brief, text-based description."/>
            <link rel="validation" href="#uuid-of-validation-component" />
            <status state="operational"/>
            <responsible-party role-id="asset-owner">
                <party-id>person-7</party-id>
            </responsible-party>
            <responsible-party role-id="asset-administrator">
                <party-id>it-dept</party-id>
            </responsible-party>
            <implemented-component component-uuid="component-uuid-value " />
            <remarks><p>COMMENTS: Additional information about this item.</p></remarks>
        </inventory-item>
        <!-- Repeat the inventory-item assembly for each item in the inventory -->
    </system-inventory>
    <!-- system-implementation remarks -->
</system-implementation>

Notes:

The value of asset-type determines whether the identified asset-administrator is managing a system or an application. Currently, any FedRAMP-defined asset-type implies the management of a system, and therefore, is to be scanned as infrastructure.

Component-based Approach

Component-based 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
36
37
38
39
40
41
42
43
44
45
46
47

<!-- cut -->
<system-implementation>
    <component uuid="uuid-value" type="software">
        <prop name="virtual" value="no"/>
        <prop name="software-name" value="software-name"/>
        <prop name="version" value="V 0.0.0"/>
        <prop name="asset-type" value="operating-system"/>
        <prop name="vendor-name" value="Vendor Name"/>
        <prop name="model" value="Model Number"/>
        <prop name="patch-level" value="Patch-Level"/>
        <prop name="scan-type" ns="http://fedramp.gov/ns/oscal" value="infrastructure"/>
        <prop name="allows-authenticated-scan"  value="no">
            <remarks><p>If no, explain why. If yes, omit remarks field.</p></remarks>
        </prop>
        <prop name="baseline-configuration-name" value="Baseline Config. Name" />
        <prop name="function" value="Required brief, text-based description.">
            <remarks><p>Optional, longer, formatted description.</p></remarks>
        </prop>
        <link rel="validation" href="#uuid-of-validation-component" />
        <status state="operational"/>
        <responsible-party role-id="asset-owner">
            <party-id>person-7</party-id>
        </responsible-party>
        <responsible-party role-id="asset-administrator">
            <party-id>it-dept</party-id>
        </responsible-party>
    </component>
    <!-- service, interconnection -->
    <system-inventory>
        <inventory-item uuid="uuid-value" asset-id="unique-asset-id">
            <description><p>If needed, describe this instance.</p></description>
            <prop name="ipv4-address" value="0.0.0.0"/>
            <prop name="public" value="no"/>
            <prop name="fqdn" value="example.com"/>
            <prop name="uri" value="https://example/query?key=value#anchor"/>
            <prop name="mac-address" value=">00:00:00:00:00:00"/>
            <prop name="serial-number" value="Serial #"/>
            <prop name="vlan-id" value="VLAN Identifier"/>
            <prop name="network-id" value="Network Identifier"/>
            <prop name="is-scanned" value="yes" />
            <implemented-component component-uuid="component-uuid-value " />
            <remarks><p>COMMENTS: Additional information about this item.</p></remarks>
        </inventory-item>
        <!-- Repeat the inventory-item assembly for each use of the above component -->
    </system-inventory>
    <!-- system-implementation remarks -->
</system-implementation>

Notes:

  • If component-sample is an image of a Linux virtual machine (VM), and 10 instances of that VM are in use, there would be one (1) component assembly and ten (10) inventory-item assemblies, all referencing the same component.

Inventory Data Locations and XPath Queries

The following queries are intended to show where to find each piece of information within the system inventory template.

Figure describing guidance, valid values, requirements, cardinality, data location and other notes on fields that apply to all inventory items.

All Inventory.

Figure describing guidance, valid values, requirements, cardinality, data location and other notes on fields that apply to OS infrastructure inventory items.

OS Infrastructure Inventory.

Figure describing guidance, valid values, requirements, cardinality, data location and other notes on fields that apply to software and database inventory items.

Software and Database Inventory.

Figure describing guidance, valid values, requirements, cardinality, data location and other notes on fields that apply to any inventory item.

Any Inventory.

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

  Number of Inventory Items:
    count(/*/system-implementation/system-inventory/inventory-item)
  Number of Hardware Components:
    count(/*/system-implementation/component[@type="hardware"])
  Number of Software Components:
    count(/*/system-implementation/component[@type="software"])
  In Latest Scan?:
    /*/system-implementation/system-inventory/inventory-item[1]/prop[@name="is-scanned"]/@value

  List Inventory Items Not Scanned:
    /*/system-implementation/system-inventory/inventory-item/prop[@name="is-scanned"][@value='no']/../prop[@name='ipv4-address']
  List of Reasons Inventory Items Were Not Scanned:
    /*/system-implementation/system-inventory/inventory-item/prop[@name="is-scanned"][@value='no']/remarks/node()

Unlike most XPath 2.0 queries in this document, the following queries cannot be easily converted to XPath 1.0. If working with XPath 1.0, it may be necessary to perform each search with two separate queries. These queries will list all the IPv4 addresses for each scan type (infrastructure, web, and database), whether using the flat-file inventory approach or the component-based approach.

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

  IPv4 Address of All Inventory Items Identified for Infrastructure Scanning:
    distinct-values( (let $key:=/*/system-implementation/component[prop [@name='scan-type'] [@ns='http://fedramp.gov/ns/oscal']='infrastructure']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/ prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='http://fedramp.gov/ns/oscal']  [string(.)='infrastructure']]) )
  IPv4 Address of All Inventory Items Identified for Web Scanning: 
    distinct-values( (let $key:=/*/system-implementation/component[prop[@name='scan-type'][@ns='http://fedramp.gov/ns/oscal']='web']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='http://fedramp.gov/ns/oscal'][string(.)='web']]))
  IPv4 Address of All Inventory Items Identified for Database Scanning: 
    distinct-values( (let $key:=/*/system-implementation/component[prop [@name='scan-type'] [@ns='http://fedramp.gov/ns/oscal']='database']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='http://fedramp.gov/ns/oscal'][string(.)='database']]))
  IPv4 Address of All Items Where an Authenticated Scan is Possible:
    distinct-values( (/*/system-implementation/system-inventory/inventory-item/prop [@name='ipv4-address'][../prop[@name="allows-authenticated-scan"][@value='yes']] ) | (let $key:=/*/system-implementation/component[prop [@name='allows-authenticated-scan'][@value='yes']]/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']))
  IPv4 Address of All Items Where an Authenticated Scan is Not Possible:
    distinct-values( (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name="allows-authenticated-scan"][@value='no']] ) | ( let $key:=/*/system-implementation/component[prop [@name='allows-authenticated-scan'][@value='no']]/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) )
  Authenticated Scan Justification (if Authenticate Scan is "no"):
    /*/system-implementation/system-inventory/inventory-item/prop[@name="allows-authenticated-scan"][@value="no"]/remarks/node()
  OR
    /*/system-implementation/component/prop[@name="allows-authenticated-scan"] [@value="no"]/remarks/node()