0% found this document useful (0 votes)
26 views75 pages

Guide To OSCAL-based FedRAMP Content Rev5

OSCAL guide for use with FedRAMP

Uploaded by

Zibberzoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views75 pages

Guide To OSCAL-based FedRAMP Content Rev5

OSCAL guide for use with FedRAMP

Uploaded by

Zibberzoo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 75

Guide to OSCAL-Based

FedRAMP® Content
User Implementation Guide

Fedramp2.0.0-oscal1.0.x
June 30, 2023

Controlled Unclassified Information [email protected]


fedramp.gov
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

TEMPLATE REVISION HISTORY

Date Version Pages Description Author

06/30/2023 Fedramp2.0.0- All Initial release for FedRAMP rev 5 FedRAMP


oscal1.0.x baselines templates. PMO

How to contact us
For questions about FedRAMP, or for questions about this document including how to use it,
contact [email protected].

For more information about FedRAMP, see www.FedRAMP.gov.

fedramp.gov 1
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

TABLE OF CONTENTS
1. Overview ...................................................................................................................................4
1.1. Who Should Use This Document? ..................................................................................4
1.2. Related Documents .........................................................................................................4
1.3. Basic Terminology ...........................................................................................................4
6.1. XML and JSON Formats..................................................................................................5
6.2. OSCAL-based FedRAMP Templates ..............................................................................5
6.3. XML and JSON Technology Standards ..........................................................................6
6.3.1. NIST OSCAL Syntax Validation Mechanisms .......................................................... 6
6.3.2. NIST OSCAL Format Conversion Mechanisms ....................................................... 6
6.4. XPath Queries and References .......................................................................................7
7. Working with OSCAL Files .....................................................................................................8
7.1. File Content Concepts .....................................................................................................8
7.1.1. Resolved Profile Catalogs ...................................................................................... 10
7.2. Hierarchy and Sequence .............................................................................................. 11
7.2.1. Typical OSCAL Assembly Structure ....................................................................... 12
7.3. Multiple Layers of Validation ......................................................................................... 13
7.4. OSCAL’s Minimum File Requirements ......................................................................... 15
7.4.1. UTF-8 Character Encoding ..................................................................................... 17
7.4.2. OSCAL Syntax Version .......................................................................................... 17
7.4.3. Content Change Requirements .............................................................................. 19
7.4.4. Cryptographic Integrity (Future) .............................................................................. 19
7.4.5. Useful XPath Queries for Document Changes and OSCAL Syntax ...................... 19
7.4.6. OSCAL Syntax Versions......................................................................................... 20
7.5. Assigning Identifiers ...................................................................................................... 21
7.5.1. Uniqueness of Identifiers ........................................................................................ 21
7.5.2. Searching for Information by ID or UUID Values ................................................... 23
7.6. Handling of OSCAL Data Types ................................................................................... 25
7.6.1. Date and Time in OSCAL Files .............................................................................. 25
7.6.2. UUID Datatypes ...................................................................................................... 26
7.6.3. ID Datatypes ........................................................................................................... 27

fedramp.gov 2
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

7.6.4. Working With href Flags ......................................................................................... 28


7.6.5. Markup-line and Markup-multiline Fields in OSCAL .............................................. 29
7.6.6. Working with Markup-multiline Content .................................................................. 31
7.6.7. Special Characters in OSCAL ................................................................................ 32
7.7. Citations and Attachments in OSCAL Files.................................................................. 32
7.7.1. Citations .................................................................................................................. 33
7.7.2. Attachments ............................................................................................................ 34
7.7.3. Including Multiple rlink and base64 Fields ............................................................. 36
7.7.4. Handling Multiple rlink and base64 Fields .............................................................. 37
7.7.5. Citation and Attachment Details ............................................................................. 38
7.7.6. Citation and Attachment Conformity ....................................................................... 38
8. FedRAMP Extensions and Accepted Values .................................................................... 40
8.1.1. FedRAMP Extensions............................................................................................. 40
8.1.2. FedRAMP Conformity Tagging ............................................................................... 42
8.1.3. OSCAL and FedRAMP-Defined Identifiers ............................................................ 42
8.1.4. OSCAL and FedRAMP Accepted Values............................................................... 43
8.1.5. OSCAL and FedRAMP Allowed Values ................................................................. 43
9. Expressing Common FedRAMP Template Elements In OSCAL ..................................... 44
9.1. Title Page ...................................................................................................................... 45
9.2. Prepared By (Third Party) ............................................................................................. 47
9.3. Prepared By (CSP Self-Prepared)................................................................................ 48
9.4. Prepared For (CSP) ...................................................................................................... 49
9.5. Document Revision History .......................................................................................... 50
9.6. How to Contact Us ........................................................................................................ 52
9.7. Document Approvals..................................................................................................... 53
9.8. FedRAMP Standard Attachments (Acronyms, Laws/Regulations) .............................. 55
9.9. Additional Laws, Regulations, Standards or Guidance ................................................ 56
9.10. Attachments and Embedded Content .......................................................................... 57
APPENDICES ............................................................................................................................... 59

fedramp.gov 3
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

1. Overview

1.1. Who Should Use This Document?


This document is intended for technical staff and tool developers implementing solutions for
importing, exporting, and manipulating Open Security Controls Assessment Language
(OSCAL)-based FedRAMP content, such as system security plans (SSP), security assessment
plans (SAP), security assessment reports (SAR), and plans of action and milestones (POA&M).

It provides guidance and examples for an organization producing and using OSCAL-based,
FedRAMP-compliant files. Our goal is to enable your organization to develop tools that will
seamlessly ensure these standards are met so your security practitioners can focus on content
and accuracy rather than formatting and presentation.

1.2. Related Documents


This document does not stand alone. It provides foundational information and core concepts,
which apply to the following four guides:

• Guide to OSCAL-based FedRAMP System Security Plans (SSP) (rev4 | rev5)


• Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (rev4 | rev5)
• Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (rev4 | rev5)
• Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (rev4 | rev5)
Each of those documents will refer back to this one for common concepts. (rev4 | rev5)

1.3. Basic Terminology


2. XML and JSON use different terminology. Instead of repeatedly clarifying format-specific
terminology, this document uses the following format-agnostic terminology through the
document.

TERM XML EQUIVALENT JSON EQUIVALENT


Field A single element or node that can hold A single object that can hold a
a value or an attribute value or property
Flag Attribute Property
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Assembly A collection of elements or nodes. A collection of objects. Typically, a


Typically, a parent node with one or parent object with one or more
more child nodes. child objects.
These terms are used by National Institute of Standards and Technology (NIST) in the creation
of OSCAL syntax.
Throughout this document, the following words are used to differentiate between requirements,
recommendations, and options.

TERM MEANING
must Indicates a required action.
should Indicates a recommended action, but not necessarily required.
may Indicates an optional action.
3.

3.1. XML and JSON Formats


The examples provided here are in XML; however, FedRAMP accepts XML or JSON formatted
OSCAL content. NIST offers the ability to convert OSCAL-files between XML and JSON in
either direction without data loss.

You may submit your SSP, SAP, SAR, and POA&M to FedRAMP using either XML or JSON. If
necessary, FedRAMP's tools will convert the files for processing.

For more information on converting OSCAL files between XML and JSON, see Section
1.6.2, NIST OSCAL Format Conversion Mechanisms.

NOTE: NIST partially supports YAML (YAML) as an offshoot of JSON. FedRAMP will evaluate
the use of YAML for FedRAMP deliverables once NIST offers the same level of support for
YAML syntax validation and format conversion.

3.2. OSCAL-based FedRAMP Templates


FedRAMP offers OSCAL-based templates in both XML and JSON formats for the SSP, SAP,
SAR, and POA&M. These templates contain many of the FedRAMP required content and
placeholders to help get you started. This document is intended to work in concert with those
templates. The OSCAL-based FedRAMP templates are available here:

fedramp.gov 5
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

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

3.3. XML and JSON Technology Standards


For OSCAL compliance, mechanisms that interpret or generate OSCAL content must honor the
core syntax described at https://pages.nist.gov/OSCAL/concepts/layer/.

While not mandatory, organizations adopting OSCAL are strongly encouraged to use the NIST-
published validation and translation mechanisms. The validation mechanism ensures XML and
JSON files are using OSCAL-compliant syntax, while the translation mechanism converts
OSCAL content from either format to the other. NIST has an automated governance process,
which ensures these mechanisms remain aligned with the latest OSCAL syntax.

TIP: There are comments in the XML versions of the FedRAMP Templates. Unfortunately,
JSON does not formally support comments. JSON users may wish to review the
comments in the equivalent sections of the XML files.

3.3.1. NIST OSCAL Syntax Validation Mechanisms


The latest version of NIST OSCAL schema validation files are always available here:
XML: https://github.com/usnistgov/OSCAL/tree/main/xml/schema
JSON: https://github.com/usnistgov/OSCAL/tree/main/json/schema

Validating XML-based OSCAL files using the NIST-published schema validation requires:
XML Schema Definition Language (XSD) 1.1
[https://www.w3.org/TR/xmlschema11-1/]

Validating JSON-based OSCAL files using the NIST-published schema validation requires:
JSON Schema, draft-07
[https://json-schema.org/specification-links.html#draft-7]
There are several open-source and commercial tools that will process XSD 1.1 or JSON Schema, draft-07,
either as stand-alone capabilities or as programming libraries.
FedRAMP and NIST are unable to endorse specific products.

3.3.2. NIST OSCAL Format Conversion Mechanisms


The latest version of NIST OSCAL format conversion files are always available here:
XML to JSON: https://github.com/usnistgov/OSCAL/tree/main/json/convert
JSON to XML: https://github.com/usnistgov/OSCAL/tree/main/xml/convert

fedramp.gov 6
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

For more information on converting OSCAL files between supported formats, please see the
information at the following links:

• OSCAL Converters
• Converting OSCAL XML Content to JSON
• Converting OSCAL JSON Content to XML

3.4. XPath Queries and References


XPath is a standard query language for XML files, and libraries for using it are available in many
programming languages. Even if you do not use XPath to query OSCAL data files, the XPath
queries provide a concise and non-ambiguous way to communicate where the data is located
within the file.

Except where noted, all XPath queries in this document are based on XPath 2.0. Most modern
programming languages make XPath 1.0 available by default. XPath 2.0 can typically be added
with third-party libraries or calls to external command-line utilities.

JSON Users: There are several JSON query technologies available, such as JSONPath
[https://restfulapi.net/json-jsonpath/]; however, no one technology has emerged as a clear
standard as of this publication.

Most XPath queries in this document are absolute paths from the root of the document. In other
words, it is clear from the XPath query which of the major file sections described in Section 2.3
is being referenced, and where the field is located within the section.

Database Users: Some tool developers prefer to manage OSCAL data by first importing
it into a database, which is a perfectly acceptable approach. Any OSCAL file generated
from the database must still follow the OSCAL syntax. If the file is intended for delivery to
FedRAMP, it must also follow the guidance in these guides.

There are also database-like XML servers, such as the open-source tool BaseX
[http://www.basex.org/], which allow OSCAL files to remain in their native format yet be
queried more like a traditional database. These XML databases typically optimize queries
for better performance. Some will handle both XML and JSON files.

fedramp.gov 7
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4. Working with OSCAL Files


This section covers several important concepts and details that apply to OSCAL-based
FedRAMP files.

4.1. File Content Concepts


Unlike the traditional MS Word-based SSP, SAP, and SAR, the OSCAL-based versions of these
files are designed to make information available through linkages, rather than duplicating
information. In OSCAL, these linkages are established through import commands.

Security Security
FedRAMP
NIST SP 800-53 System Security Assessment Plan Assessment Report
Baseline
(OSCAL Catalog) Plan (OSCAL Assessment (OSCAL Assessment
(OSCAL Profile)
Plan) Results)

Each OSCAL file imports information from the one before it


For example, the assessment objectives and actions that appear in a blank test case workbook
(TCW), are defined in the FedRAMP profile, and simply referenced by the SAP and SAR. Only
deviations from the TCW are captured in the SAP or SAR.

fedramp.gov 8
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

NIST SP 800-53 FedRAMP Baseline System Security Security Security Plan of Action and
(OSCAL Catalog) (OSCAL Profile) Plan Assessment Plan Assessment Report Milestones
(OSCAL Assessment (OSCAL Assessment (POA&M)
Plan) Results)
Controls in this
Baseline Planned In-Scope
Control Definitions CSP s Control Actual In-Scope
Controls for
FedRAMP Implementation Controls Assessed
Assessment
Modifications

NIST SP 800-53A Empty Test Case Empty Test Case Populated Test Case POA&M Entries
Assessment Workbook Workbook Workbook
Objectives (With Adjustments) Assessment Actions
(by Control) FedRAMP Required Planned In-Scope and Findings
NIST SP 800-53A Assessment Actions Assessment Findings for Each
Assessment Actions for Each Objective Objectives and Objective
(by Control) Actions
SSP Discrepancies
TEST, INSPECT,
Found
INTERVIEW
Risk Exposure POA&M Entries
Table
Deviations: Deviations:
FP, OR, RA FP, OR, RA

System Description
and Architecture

Users
Planned In-Scope Assessed System Basic System
System Components System Details Details Information
& Inventory

Locations

Rules of Engagement Rules of Engagement

Planned Schedule Actual Events


and Activities and Activities

Planned Tools Tools Used

Baseline and SSP Information is referenced instead of duplicated.


For this reason, an OSCAL-based SAP points to the OSCAL-based SSP of the system being
assessed. Instead of duplicating system details, the OSCAL-based SAP simply points to the
SSP content for information such as system description, boundary, users, locations, and
inventory items.

The SAP also inherits the SSP's pointer to the appropriate OSCAL-based FedRAMP Baseline.
Through that linkage, the SAP references the assessment objectives and actions typically
identified in the FedRAMP TCW.

The only reason to include this content in the SAP is when the assessor documents a deviation
from the SSP, Baseline, or TCW.

fedramp.gov 9
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.1.1. Resolved Profile Catalogs


The resolved profile catalog for each FedRAMP baseline is a pre-processing the profile and
catalog to produce the resulting data. This reduces overhead for tools by eliminating the need to
open and follow references from the profile to the catalog. It also includes only the catalog
information relevant to the baseline, reducing the overhead of opening a larger catalog.

Where available, tool developers have the option of following the links from the profile to the
catalog as described above or using the resolved profile catalog.

Developers should be aware that at this time catalogs and profiles remain relatively static. As
OSCAL gains wider adoption, there is a risk that profiles and catalogs will become more
dynamic, and a resolved profile catalog becomes more likely to be out of date. Early adopters
may wish to start with the resolved profile catalog now, and plan to add functionality later for the
separate profile and catalog handling later in their product roadmap.

Security Security
FedRAMP
System Security Assessment Plan Assessment Report
Baseline
Plan (OSCAL Assessment (OSCAL Assessment
(OSCAL Resolved Profile Catalog)
Plan) Results)

The Resolved Profile Catalog for each FedRAMP Baseline reduce tool processing
For more information about resolved profile catalogs, see Appendix C, Profile Resolution.

fedramp.gov 10
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.2. Hierarchy and Sequence


For both XML and JSON, the hierarchy of syntax is important and must be followed. For
example, the metadata assembly must be at the top level of the OSCAL file, just below its root.
If it appears within any other assembly, it is invalid.

The same field name is interpreted differently in different assemblies. For example, the title
field under metadata is the document title, while the title field under role gives a human-
friendly name to that role.

For XML, the sequence of fields and assemblies (elements) is also important. JSON typically
does not require a specific sequence fields and assemblies (objects). Where sequence is
important, OSCAL uses array objects in JSON.

For example, within the metadata assembly, XML must find title, published, last-
modified, version, and oscal-version in exactly that order. The published field is
optional and may be omitted, but if present, it must be in that position relative to the other fields.
When using JSON, these fields are allowed in any order within the metadata assembly.

Tools must ensure this sequence is maintained when creating or modifying XML-based OSCAL
files. NIST’s XML documentation presents the fields and assemblies in the correct sequence.

Always use the hierarchy found here:

• SSP: https://pages.nist.gov/OSCAL/reference/latest/system-security-plan/xml-outline/
• SAP: https://pages.nist.gov/OSCAL/reference/latest/assessment-plan/xml-outline/
• SAR: https://pages.nist.gov/OSCAL/reference/latest/assessment-results/xml-outline/
• POA&M: https://pages.nist.gov/OSCAL/reference/latest/plan-of-action-and-milestones/xml-
outline/

fedramp.gov 11
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.2.1. Typical OSCAL Assembly Structure


Most assemblies in OSCAL follow a general pattern as follows:

• title (field): Typically only one title is allowed. Sometimes it is optional. This is a
markup-line datatype.
• description (field): Typically only one description field is allowed. Sometimes it is
optional. This is a markup-multiline datatype.
• prop (fields): There may be many prop fields. The name flag identifies the specific
annotation. The value flag is a string datatype and holds the intended value. The prop
field includes an optional uuid flag to give a globally unique identifier, an optional ns
field to allow for namespacing the prop and indicate it is optional information that is not
of core OSCAL syntax and a class flag to sub-class one or more instances of the prop
into specific sub-groups.
• link (fields): There may be many link fields. The href flag allows a uniform resource
identifier (URI) or URI fragment to a related item. Often, href fields point to a resource
in back matter using its UUID value in the form of href="#[uuid-value]".
• assembly-specific fields
• remarks (field): Typically only one remarks field is allowed. It is always optional. This
is a markup-multiline datatype.
While this is not universal in OSCAL, when any of these fields are present, they follow this
pattern.

The prop field is present to allow OSCAL extensions within each assembly. See Section 3,
FedRAMP Extensions and Accepted Values for more information on FedRAMP's use of OSCAL
extensions.

fedramp.gov 12
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.3. Multiple Layers of Validation


There are several layers at which an OSCAL file can be considered valid.
OSCAL-based FedRAMP files must be valid at all layers.

LAYER DESCRIPTION
Well-Formed The XML or JSON file follows the rules defined for that format.
Any tool that processes the format will recognize it as “well-formed,” which
means the tool can proceed with processing the XML or JSON.
XML: https://www.w3.org/TR/REC-xml/
JSON: https://json.org/
OSCAL Syntax The XML or JSON file only uses names and values defined by NIST for
OSCAL.
NIST publishes schema validation tools to verify syntax compliance based
on the following standards:
XML Syntax Validation: XML Schema Definition Language (XSD) 1.1
JSON Syntax Validation: JSON Schema, draft 07
OSCAL Content For certain OSCAL fields, the NIST syntax validation tools also enforce
content - allowing only a pre-defined set of values to be used in certain
fields.

For example, Within the SSP model, impact levels within the information
type assemblies only allow the following values: fips-199-low, fips-
199-moderate, and fips-199-high. Any other value will cause an
error when validating the file.

In the future, NIST intends to publish more robust content enforcement


mechanisms, such as Schematron. This enables more complex rules such
as, “If field A is marked ‘true’, field B must have a value.” FedRAMP is also
exploring the use of Schematron for enhanced validation and may publish
these in the future.
FedRAMP NIST designed OSCAL to represents the commonality of most
Syntax cybersecurity frameworks and provided the ability to extend the language
Extensions for framework-specific needs. FedRAMP makes use of these extensions.
NIST provides prop fields throughout most of its assemblies, always with
a name, class, and ns (namespace) flag:
<prop name="" class="" ns="">Data</prop>

In the core OSCAL syntax, the ns flag is never used. Where FedRAMP
extends OSCAL, the value for ns is always:
https://fedramp.gov/ns/oscal (case sensitive).

fedramp.gov 13
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

When ns='https://fedramp.gov/ns/oscal' the name flag is as


defined by FedRAMP. If the class flag is present, that is also defined by
FedRAMP.
FedRAMP Today, FedRAMP content is enforced programmatically. FedRAMP
Content intends to publish automated validation rules, which may be adopted by
tool developers to verify OSCAL-based FedRAMP content is acceptable
before submission.
Initial validation rules ensure a package has all required elements and will
evolve to perform more detailed validation. Separate details will be
published about this in the near future.

fedramp.gov 14
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.4. OSCAL’s Minimum File Requirements


Every OSCAL-based FedRAMP file must
have a minimum set of required Every OSCAL File
fields/assemblies, and must follow the core
OSCAL syntax found here: Root Element (Identifies Model)
[ catalog | profile | component |
https://pages.nist.gov/OSCAL/concepts/layer/
system-security-plan |
In addition to the core OSCAL syntax, the assessment-plan |
following FedRAMP-specific implementation assessment-results |
plan-of-actions-and-milestones ]
applies:

• The root element of the file indicates the Universally Unique Identifier (UUID)
type of content within the body of the file.
The recognized OSCAL root element Metadata
types are as follows: Must be at the start of every OSCAL file.
Syntax is the same, regardless of root element.
– catalog: Contains a catalog of
control definitions, control objectives,
and assessment activities, such as • Title, Modified Date, OSCAL Syntax Version
NIST SP 800-53 and 800-53A. • Document Date and Version
• Roles, People, Organizations, Locations
– profile: Contains a control baseline,
such as FedRAMP Moderate
Body
– component: Contains information Syntax is different for each root element.
about a product, service, or other
security capability, such as the
Back Matter
controls it can satisfy.
May be at the end of any OSCAL file.
– system-security-plan: Describes a Syntax is the same, regardless of root element.
system and its security capabilities,
including its authorization boundary • External Links and Citations
and a description of how each control • Attachments and Embedded Images
is satisfied.
– assessment-plan: Describes the
plan for assessing a specific system.
Anatomy of an OSCAL file
– assessment-results: Describes the
actual activities performed in the
assessment of a specific system, as well as the results of those activities.
– plan-of-action-and-milestones: Describes and tracks known risks to a system, as well
as the plan for remediation.
• The Universally Unique ID (UUID) at the root must be changed every time the content of the
file is modified.

fedramp.gov 15
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

• Every OSCAL file must have a metadata section and include a title, last-modified timestamp,
and OSCAL syntax version.
• The body of an OSCAL file is different for each model.
• Back matter syntax is identical in all OSCAL models. It is used for attachments, citations,
and embedded content such as graphics. Tool developers and content authors are
encouraged to attach content here and reference it from within the body of an OSCAL file.

fedramp.gov 16
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

The table below shows an empty OSCAL file, based purely on the NIST syntax; however,
FedRAMP requires much more in a minimum file. The latest OSCAL-based FedRAMP template
files can be found here in JSON and XML formats:

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

An Empty OSCAL File Representation


<?xml version="1.0" encoding="UTF-8"?>
<OSCAL-root-element xmlns="http://csrc.nist.gov/ns/oscal/1.0"
uuid="[generated-uuid]">
<metadata>
<title>Document Title</title>
<last-modified>2023-03-06T00:00:00.000Z</last-modified>
<version>0.0</version>
<oscal-version>1.0.4</oscal-version>
</metadata>

<!-- body cut -->

<back-matter />
</OSCAL-root-element>

4.4.1. UTF-8 Character Encoding


OSCAL uses UTF-8 character encoding. JSON files are always UTF-8 character encoded.

In XML, the first line in the example above ensures UTF-8 encoding is used. Other encoding
options will create unpredictable results.

4.4.2. OSCAL Syntax Version

Tools designed to read an OSCAL file must verify the oscal-version field to determine which
published syntax is used.

Tools designed to create or manipulate an OSCAL file must specify the syntax version of
OSCAL used in the file in the oscal-version field.

NIST ensures backward compatibility of syntax where practical; however, this is not always
possible. Some syntax changes between milestone releases leading up to OSCAL version 1.0
are unavoidable. NIST intends to keep all formally published schema validation files available,
which keeps validation and conversion tools available for older versions of OSCAL. See Section
2.4.6 OSCAL Syntax Versions for more information. FedRAMP releases indicate, in its trailing
half, the earliest version of OSCAL supported by baselines, templates, documentation, and

fedramp.gov 17
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

ancillary utilities. See the OSCAL Support and Deprecation Policy in the FedRAMP Automation
Github repository for further details.

fedramp.gov 18
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.4.3. Content Change Requirements


Any time a tool changes the contents of an OSCAL file, it must also:

• update the file's uuid flag (/*/@uuid) with a new UUID; and
• update the last-modified field (/*/metadata/last-modified) with the current
date and time. (Using the OSCAL date/time format, as described in Section 2.6.1 Date
and Time in OSCAL Files)
Tools that open or import OSCAL files should rely on the UUID value provided by the uuid flag,
and last-modified field as easy methods of knowing the file has changed.

See the following for more information:


https://pages.nist.gov/OSCAL/documentation/schema/overview/#common-high-level-structure

4.4.4. Cryptographic Integrity (Future)

NIST intends to add a cryptographic hash feature to OSCAL during calendar year 2021. Once
available, NIST will publish details here: https://pages.nist.gov/OSCAL/concepts/layer/

While tool developers are encouraged to perform their own integrity checking, it is important to
note cryptographic hash algorithms will produce a different result for inconsequential file
differences, such as different indentation or a change in the sequence of flags.

4.4.5. Useful XPath Queries for Document Changes and OSCAL Syntax
Below are a few important queries, which enable a tool to obtain critical information about any
OSCAL file.

XPath Queries
OSCAL syntax version used in this file:
/*/metadata/oscal-version
Last Modified Date/Time:
/*/metadata/last-modified
Unique Document ID:
/*/@uuid
Document Title:
/*/metadata/title

fedramp.gov 19
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.4.6. OSCAL Syntax Versions


NIST's approach to OSCAL development ensures the syntax validation and format conversion
tools remain available for release of OSCAL.

NIST always makes the latest version of syntax validation and format conversion files
available in the main OSCAL repository, including any changes since the last formal release.

To ensure stable resources, use a formal OSCAL release. NIST publishes formal OSCAL
releases here:
https://github.com/usnistgov/OSCAL/releases

To access OSCAL resources based on a particular release, click the tag to the left of the
release title.

fedramp.gov 20
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.5. Assigning Identifiers


Tools must generate
There are four ways identifiers are typically used in OSCAL: RFC4122 version 4 UUID
values and assign them
• ID flag: uniquely identifies a field or assembly. anyplace a UUID flag
• UUID flag: An RFC-4122 compliant universally unique
exists.
identifier, version 4.
• ID/UUID Reference: a flag or field that points to another
field or assembly using its unique ID or UUID flag value.
• Uniform Resource Identifier (URI) Fragment: A value in a flag or field with a URI data
type. A URI fragment starts with a hashtag (#) followed by a unique ID value.
Identifiers appear as an “id” or "uuid" flag to a data field or assembly. Examples include:

• <control id="ac-1">: Uniquely identifies the control.


• <party uuid="8e83458e-dde5-4ee2-88bc-152f8da3fc31">: Uniquely identifies the
party.
An ID reference typically appears with a name and hyphen in IDs and UUIDs are
front of the “id” (name-id) or "uuid" (name-uuid). It is typically a intended to be managed by
flag where the relationship is one-to-one, but sometimes a field tools "behind the scenes,"
when the relationship is one-to-many. The name of an ID and should not typically be
reference flag/field typically reflects the name of the field to exposed to users for
which it points. manipulating SSP, SAP,
Examples include: SAR and POA&M content.

• <responsible-party role-id="prepared-by">: points to a role identified by


“prepared-by”.
• <implemented-requirement id="imp-req-01" control-id="ac-2">: points to the
control identified by “ac-2”.

NIST provides some standard identifiers. Where appropriate, FedRAMP has adopted those and
defined additional identifiers as needed. To ensure consistent processing, FedRAMP encourage
content creators to use the NIST and FedRAMP-defined identifiers to the greatest degree
practical. Deviation is likely to result in processing errors.

4.5.1. Uniqueness of Identifiers


Within FedRAMP deliverables, only roles in the metadata assembly have ID flags. All other
OSCAL identifiers are UUID.

fedramp.gov 21
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Some role ID values are prescribed by NIST, and others by FedRAMP. These are "reserved"
and must not be assigned to other roles for other reasons. The scope of this requirement goes
beyond the current OSCAL file to all files in the OSCAL stack as a result of import statements,
as described in Section 2.1, File Content Concepts.

For UUID fields, if using a tool that properly generates version 4 UUID values, no two will be
alike; however, buggy tools have been known to create unexpected duplicate values. In an
abundance of caution, tool developers are encouraged to check for unintended duplicates
whenever generating a new UUID values. At least during the testing phase of your development
lifecycle.

fedramp.gov 22
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.5.2. Searching for Information by ID or UUID Values


When searching for an ID or UUID reference, the tool must look both in the current OSCAL file,
and other files in the OSCAL stack as described in Section 2.1, File Content Concepts.

For example, a UUID reference in an OSCAL-based FedRAMP SAR could refer to a field or
assembly in the SAR, SAP, or SSP. XPath and similar standards only search the current file.

This requires OSCAL tools to search the current file first. If the ID or UUID is not found, the tool
should follow the file's import statement and search the next file the same way. This must be
repeated until either the ID/UUID is found, or all files in the stack have been processed. Of
course, tools may limit

Searching for a Field or Assembly by ID or UUID

In general, it is very simple to query for an ID or UUID value within an XML file. Simply use the
following XPath query:
//*[@id='id-value']
-OR-
//*[@uuid='uuid-value']

Of course, the tool must replace 'id-value' or 'uuid-value' above with the appropriate
reference.

Ensuring the Field or Assembly Name Matches

Often flags that reference OSCAL information using its ID or UUID will have a name and context
that clarifies the expected target. For example, a flag may appear as follows:
<field-name component-uuid='1c23ddee-7001-4512-9de1-e062faa69c0a' />

To ensure this UUID value points to a component, use the following XPath query:
boolean(//*[@uuid='1c23ddee-7001-4512-9de1-e062faa69c0a']/name()='component')

If the above expression returns true, the UUID points to a component as intended.

Limiting Searches by Field or Assembly Name

Another approach is to limit the search only to fields or flags with a specific name.

The following will only find the UUID value if it is associated with a component. It would work in
the SSP, SAP, SAR and POA&M.
//component[@uuid='1c23ddee-7001-4512-9de1-e062faa69c0a']

fedramp.gov 23
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

The following will only find the UUID value if it is associated with a component in the system-
implementation assembly of the SSP. If the UUID value is

/*/system-implementation/component[@uuid='1c23ddee-7001-4512-9de1-
e062faa69c0a']

fedramp.gov 24
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.6. Handling of OSCAL Data Types


OSCAL fields and flags have data types assigned to them. NIST provides important information
about these data types here:
https://pages.nist.gov/OSCAL/reference/datatypes/

The following sections describe special handling considerations for data types that directly
impact FedRAMP content in OSCAL.

4.6.1. Date and Time in OSCAL Files


Except where noted, all dates and times in the OSCAL-based content must be in an OSCAL
dateTime-with-timezone format as documented here:

https://pages.nist.gov/OSCAL/reference/datatypes/#datetime-with-timezone

This means all dates and times must be represented in the OSCAL file using following format,
unless otherwise noted:

"Y-m-d\TH:i:s.uP" (See HERE for formatting codes.)

For example, a publication date of 5:30 pm EST, January 10, 2020 must appear as
2020-01-10T17:30:00.00-05:00

This includes:

• Numeric Year: Four-digits


• A dash
• Numeric Month: Two-digit, zero-padded
• A dash
• Numeric Day: Two digit, zero padded
• The capital letter “T” (Do not use lower case)
• Hour: Two digit, zero-padded, 24-hour clock (Use 18 for 6:00 pm)
• A colon
• Minute: Two digit, zero-padded
• A colon
• Seconds: Two digit, zero-padded
• A decimal point
• Fractions of a second: two or three digits, zero padded
Followed by either:

• A capital letter Z to indicate the time is expressed in Coordinated Universal Time (UTC)

fedramp.gov 25
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

OR:

• A plus or minus representing the offset from UTC


• Hour Offset: Difference from UTC, two-digit, padded
• A colon
• Minutes Offset: Difference from UTC, two-digit, padded
This is only for storing dates in the OSCAL file. NIST syntax verification tools will generate an
error if this format is not found.

Tool developers are encouraged to present dates as they have historically appeared in
FedRAMP documents. In other words, tools should convert "2020-03-04T00:00:00.00-
05:00" to "March 4, 2020" when presenting the publication date to the user.

Please use the appropriate UTC offset in your region. If you are storing a date and padding the
time with zeros, you may also pad the UTC offset with zeros.

4.6.2. UUID Datatypes

Any place a UUID flag or UUID reference exits, NIST requires UUID version 4, as defined by
RFC-4122. See here for more information:
https://pages.nist.gov/OSCAL/reference/datatypes/#uuid

Version 4 UUIDs are 128-bit numbers, represented as 32 hexadecimal (base-16) digits in the
pattern:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

All alphabetic characters (a-f) representing hexadecimal values must be lower case.

Strictly following the RFC ensures the probability of generating an unintended duplicate UUID
value is so close to zero it may be ignored. As calculated on Wikipedia, after generating 103
trillion version 4 UUIDs, there is a one in a billion chance of a duplicate.

There are several open-source algorithms and built-in functions for generating UUID. It is
important to use one that is known to be fully compliant. Unintended duplicate UUIDs become
more likely when using non-compliant or erroneous algorithms.

For more information about the use of UUIDs in OSCAL, see Section 2.5, Assigning
Identifiers.

fedramp.gov 26
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.6.3. ID Datatypes
NIST typically uses ID flags in OSCAL where the identifier is intended to be canonical, such as
the identifiers for role IDs or NIST SP 800-53 controls.

Any place an ID flag or ID reference exits, the datatype is token. It is similar to the NCName as
defined by the World Wide Web Consortium (W3C), but does not allow spaces. The allowable
values of an NCName are limited as follows:

• The first character must be alphabetic [a-z or A-Z], or an underscore [_].


• The remaining characters must be alphabetic [a-z or A-Z], numeric [0-9], an
underscore [_], period [.], or dash [-].
• Spaces are not allowed.
Token values are case sensitive. "This" does not match "this" in searches.

A tool developer may wish to assign UUID values to ID flags. UUIDs may start with a numeric
character, which is invalid for NCName. To ensure a valid datatype when using a UUID value in
an ID field, consider prepending "uuid-" to the UUID value.

For more information about the use of IDs in OSCAL, see Section 2.5, Assigning
Identifiers.

fedramp.gov 27
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.6.4. Working With href Flags


All OSCAL-based href flags are URIs formatted according to section 4.1 of RFC3986. When
assembling or processing an OSCAL-based FedRAMP file, please consider the following:

Absolute Paths: When using an absolute path within a FedRAMP OSCAL file, the path must
be publicly accessible from any location on the Internet, to ensure agency and FedRAMP
reviewers can reach the information.

Tool developers are encouraged to validate paths before storing or using them in OSCAL files
and raise issues to users if paths are not reachable.

Relative Paths: All relative paths are assumed to be based on the location of the OSCAL file,
unless tools are explicit as to other handling. Sensitive external documents should travel with
the OSCAL file and be linked using a relative path.

Internal Locations: These URI fragments appear as just a hashtag (#) followed by a name,
such as #a3e9f988-2db7-4a14-9859-0a0f5b0eebee. This notation points to a location
internal to the OSCAL content. Typically, this references to a resource assembly, but may
reference to any field or assembly with a unique ID or UUID.

If only a URI fragment (internal location) is present, the OSCAL tool must strip the hashtag (#)
and treat the remaining string as a UUID reference to a resource. The resource may exist in the
current OSCAL file, or one of the imported OSCAL files in the stack as described in Section 2.1,
File Content Concepts.

For example, the following OSCAL content contains a href flag with a URI fragment:

URI Fragment Example


<system-characteristics>
<authorization-boundary>
<diagram uuid="a04b5a0c-6111-420c-9ea3-613629599213">
<link href="#a3e9f988-2db7-4a14-9859-0a0f5b0eebee"/>
<caption>Authorization Boundary Diagram</caption>
</diagram>
</authorization-boundary>
</system-characteristics>

When a tool processes the above example, it should look inside the document for a field or
assembly with a UUID of "a3e9f988-2db7-4a14-9859-0a0f5b0eebee". This can be
accomplished with the following XPath query:
//*[@uuid="a3e9f988-2db7-4a14-9859-0a0f5b0eebee"]

fedramp.gov 28
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

If this is found to point to a resource assembly, see the Attachments and Embedded Content in
OSCAL Files section for additional handling.

The name of the field or assembly referenced by the above URI fragment can be determined
using the following XPath 2.0 query:
//*[@uuid="uri-fragment" | @id="uri-fragment"]/name()

To express this in XPath 1.0, you must use the following:

name(//*[@uuid="uri-fragment" | @id="uri-fragment"])

The above query will return "resource", if the URI Fragment references the UUID of a
resource assembly.

4.6.5. Markup-line and Markup-multiline Fields in OSCAL


As with most machine-readable formats, most of OSCAL's
fields are intended to capture short, discrete pieces of For markup-line and markup-
information; however, sometimes users require content to be multi-line, a subset of HTML
formatted using features such bold, underline, and italics. is used to format XML-based
OSCAL files, while
OSCAL provides two types of fields for this purpose:
Markdown is used to format
• markup-line: Allows some formatting within a single JSON-based OSCAL files.
line of text.
• Markup-multiline: Allows all the markup-line
formatting, plus allows multiple lines, ordered/ unordered lists, and tables.
In OSCAL-based XML files, markup-line and -multiline uses a subset of HTML.

In OSCAL-based JSON files, markup-line and -multiline uses a subset of markdown.

NIST has implemented only a subset of formatting tags from these standards. This is to
ensure formatted content converts completely and consistently between XML and JSON in
either direction.

Both markup-line and markup-multiline support:


• emphasis and important text
• inline code and quoted text
• sub/super-script
• images and links
Markup-multiline also supports:
• Paragraphs

fedramp.gov 29
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

• Headings (Levels 1-6)


• Preformatted text
• Ordered and Unordered Lists
• Tables
For a complete list of markup-line and markup-multiline features, please visit:
https://pages.nist.gov/OSCAL/reference/datatypes/#markup-data-types

fedramp.gov 30
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.6.6. Working with Markup-multiline Content


In JSON, markup-multiline is based on Markdown syntax and requires no special handling.
XML-based markup-multiline fields require all content to be enclosed in one of the following
tags: <p>, <h1> - <h6>, <ol>, <ul>, <pre>, or <table>. At least one of these tags
must be present. More than one may be present. All text must be enclosed within one of these
tags.

The example below is a common misuse of markup-multiline. The description contains text, but the
text is not enclosed in one of the required tags. This will produce an error when checked with the
OSCAL schema.

Incorrect Markup-multiline Representation


<system-characteristics>
<!-- cut -->
<description>The xyz system performs ...</description>
</system-characteristics>

The simplest way to correct the error is to enclose the text in <p></p> tags, within the
description field.

Correct Markup-multiline Representation


<system-characteristics>
<!-- cut -->
<description><p>The xyz system performs ... </p></description>
</system-characteristics>

The example below demonstrates a correct use of markup-multiline in XML. Please note, the
inclusion of a <p /> tag on a line by itself inserts an empty paragraph. Within XML and HTML,
this is treated as a shortcut, and is interpreted as "<p></p>"

Correct Markup-multiline Representation


<system-characteristics>
<!-- cut -->
<description>
<p>The <b>xyz system</b> performs ... </p>
<p>The xyz system further supports ... as follows:</p>
<table>
<tr>
<td>Cell A1</td>
<td>Cell B1</td>
</tr>
<tr>
<td>Cell A2</td>

fedramp.gov 31
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

<td>Cell B2</td>
</tr>
</table>
<h1>Big Header</h1>
<p>More detail</p>
<p><img alt="alt text" src="url" title="title text"/></p>
</description>
</system-characteristics>

For more information, please visit: https://pages.nist.gov/OSCAL/reference/datatypes/#markup-


data-types

4.6.7. Special Characters in OSCAL


While OSCAL itself does not directly impose special character handling requirements, XML and
JSON do. Characters, such as ampersand (&), greater than (>), less than (<), and quotes (")
require special treatment in OSCAL files, depending on the format. For a complete list of special
characters and the appropriate treatment for each format, please visit:
https://pages.nist.gov/OSCAL/reference/datatypes/#specialized-character-mapping

4.7. Citations and Attachments in OSCAL Files


OSCAL is designed so that all citations and attachments are defined once at the end of the file
as a resource, and then referenced as needed throughout the file. This includes logos,
diagrams, policies, procedures, plans, evidence, and interconnection security agreements
(ICAs).

Each resource may be referenced from anywhere in the OSCAL file, using its resource UUID.

<back-matter>
<resource uuid="3df7eeea-421b-459d-98cf-3d972bec610a">
<title>Attachment or Document Title</title>
<desc>An optional description of the attachment.</desc>
<rlink href="./relative/path/doc.pdf" media-type="application/pdf" />
<rlink href="/absolute/path/doc.pdf" media-type="application/pdf" />
<base64 filename="doc.pdf" media-type="application/pdf">
00000000
</base64>
</resource>
</back-matter>

fedramp.gov 32
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

The media-type flag should be present and must be set to an Internet Assigned Numbers
Authority (IANA) Media Type.

4.7.1. Citations
Citations are for reference. The content is not included with the authorization package.

Citations use an rlink field with an absolute path to content that is accessible by FedRAMP
and Agency reviewers from government systems.

Examples include links to publicly available laws such as FISMA, and applicable standards,
such NIST SP 800 series documents.

fedramp.gov 33
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.7.2. Attachments
Unlike citations, attachments are included with the authorization package when submitted.

Tools may either embed an attachment using the base64 field, or point to an attachment using
an rlink field. If no base64 embedded content is present, at least one rlink field must exist with
either an absolute path to content that is accessible by FedRAMP and Agency reviewers from
government systems, or a relative path.

If a relative path is used, the attachment must be delivered with the OSCAL file and packaged
such that the attachment exists in the correct relative location.

Examples include the logo for the CSP or 3PAO, authorization boundary diagrams, policies,
process, plans, raw scanner output, assessment evidence, and POA&M deviation request
evidence.

Tools should embed (base64) or link to (rlink) an attachment once as a resource in back-
matter, then use URI fragments to reference the attachment anyplace it is needed within the
body of the OSCAL file, as described in Section 2.5, Assigning Identifiers or Section 2.6.2,
Working With href Flags.

For example, a policy document that satisfies several control families is attached as a
resource in the back-matter, with a UUID of "3df7eeea-421b-459d-98cf-
3d972bec610a". Each control satisfied by that policy, links to the policy using a URI fragment
as follows:
<link href="#3df7eeea-421b-459d-98cf-3d972bec610a" rel="policy" />

As described in Section 2.6.2, Working With href Flags, when a tool identifies a URI fragment in
an href value, the leading hashtag (#) must be dropped and the remaining value is expected to
reference an OSCAL addressable ID or UUID. This ID/UUID may be either within the OSCAL
file itself, or within other OSCAL documents linked via the import field.

The policy's title, version, publication date and other details are defined once in the resource
and are displayed anyplace the policy is referenced. If a newer policy is published, only the one
resource in needs to be updated.

If the policy's location is identified as ="./policies/doc.pdf", the OSCAL file and the
doc.pdf file should be delivered together and packaged such that the folder containing the
OSCAL file includes a sub-folder named "policies", which contains the "doc.pdf" file.

fedramp.gov 34
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

When using attachments with relative paths, consider using a technology such as a ZIP archive
to package and deliver attachments while maintaining their relative position to the OSCAL file.

fedramp.gov 35
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.7.3. Including Multiple rlink and base64 Fields


Within a resource, there may be:

• no rlink nor base64 fields;


• one or more rlink fields;
• one or more base64-encoded data fields within the OSCAL file; or
• any combination of rlink and base64 fields.
OSCAL allows multiple rlink and base64 fields to exist within the same resource. This
provides the flexibility to identify multiple locations or multiple formats of the same resource.
Some examples of using multiple rlink and/or base64 fields within the same resource include:

• Multiple Locations: Multiple rlink fields allow an OSCAL tool to include one rlink
field with an absolute path to the authoritative location of a policy document within the
CSP's intranet. The same resource could have a second rlink field with a relative
path to the same policy document. Having both allows the CSP to maintain the link to
authoritative location of the policy when working with the OSCAL file internally, while
allowing a cached, local copy to travel with the OSCAL file when delivered to FedRAMP
for review.
• Multiple Quality Levels: Multiple rlink or base64 fields allow both low-resolution and
high-resolution versions of the same image, which is sometimes used to boost the
performance of web-based applications.
• Multiple Formats: Multiple rlink or base64 fields allow a portable network graphic
(PNG) version of an image may be provided for presentation by a web application, and a
more detailed portable document format (PDF) version of the same image for download
by users.

fedramp.gov 36
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.7.4. Handling Multiple rlink and base64 Fields


NIST designed resource assemblies to be flexible and wanted to offer developers the
flexibility to implement handling of multiple rlink and base64 fields on a case-by-case basis.

This section describes FedRAMP's processing of multiple rlink and base64 fields, which will
be used by default unless a compelling circumstance requires otherwise.

FedRAMP accepts both base64 and rlink option content for diagrams and graphics.
FedRAMP prefers documents, such as policies and plans, are attached using rlink fields and
relative paths.

If the tool is designed to work interactively with a user, the tool developer should consider
designing the tool to make intelligent choices based on context and circumstances where
practical. The tool could also present valid choices to the user where the correct choice is
ambiguous to the tool.

When more than one rlink and/or base64 field is present in a resource, FedRAMP's automated
processing tools will attempt to find valid content using the following priority, unless specified
otherwise:

1. FedRAMP tools will look first in base64 fields


a. Start with the first base64 field in the resource.
b. Check each base64 field in the sequence in which they appear in the
resource.
c. If valid content is found, stop looking and use the content.
d. If no valid content is found after checking all base64 fields in the resource,
proceed to step #2.
2. If no valid base64 content is found, look in rlink fields.
a. Start with the first rlink field in the resource.
b. Check each rlink field in the sequence in which they appear in the resource.
c. If valid content is found, stop looking and use the content.
d. If no valid content is found after checking all rlink fields, treat the resource as
invalid, which may include raising a warning or error message.

fedramp.gov 37
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

4.7.5. Citation and Attachment Details


IMPORTANT: As of 1.0.0, NIST includes type, version, and published properties as part of
core OSCAL, eliminating the requirement to treat this content as FedRAMP Extensions.

For policies, plans, user guides, and other documents, FedRAMP requires the document's title,
version, and publication date.

The following example demonstrates the inclusion of this content within a resource.
<back-matter>
<resource uuid="3df7eeea-421b-459d-98cf-3d972bec610a">
<title>Attachment or Document Title</title>
<prop name="type" value="policy"/>
<prop name="version" value="2.1"/>
<prop name="published" value="2018-11-11T00:00:00Z"/>
<base64>0000000</base64>
<rlink href="./rel/path/doc.pdf" media-type="application/pdf" />
<rlink href="/absolute/path/doc.pdf" media-type="application/pdf" />
</resource>
</back-matter>

4.7.6. Citation and Attachment Conformity


IMPORTANT: As of 1.0.0, NIST includes many aspects of OSCAL previously only possible with
conformity tags. For citations and attachments, FedRAMP now uses a combination of the
resource "type" property, and link statements from relevant portions of the OSCAL content.

The following represents an example linking a policy directly to the control it satisfies. (Legacy
approach)

<control-implementation>
<implemented-requirement control-id='ac-1' uuid="[uuid-value]">
<statement>
<link href="#090ab379-2089-4830-b9fd-26d0729e22e9"
rel="policy" />
</statement>
</implemented-requirement>
</control-implementation>

<back-matter>
<resource uuid="090ab379-2089-4830-b9fd-26d0729e22e9">
<title>Access Control and Identity Management Policy</title>
<description>

fedramp.gov 38
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

<p>Policy Document.</p>
</description>
<prop name="type" value="policy"/>
<base64 filename="./documents/policies/sample_policy.pdf">
0000
</base64>
</resource>
</back-matter>

The following represents an example linking a policy to the control it satisfies via the preferred
component-based approach.
<system-implementation>
<component uuid="f25e84bf-3e57-48c3-ac0b-7a567b3af79e" type="policy">
<title>[EXAMPLE]Access Control and Identity Management
Policy</title>
<description>
<p>[EXAMPLE]An example component representing a policy.</p>
</description>
<link href="#090ab379-2089-4830-b9fd-26d0729e22e9" rel="policy" />
<status state="operational"/>
</component>
</system-implementation>

<control-implementation>
<implemented-requirement control-id="ac-1" uuid="[uuid-value]">
<statement statement-id="ac-1_smt.a"
uuid="fb4d039a-dc4f-46f5-9c1f-f6343eaf69bc">
<by-component
component-uuid="f25e84bf-3e57-48c3-ac0b-7a567b3af79e">
<description>
<p>Describe how statement a is satisfied by this
policy.</p>
</description>
</by-component>
</statement>
</implemented-requirement>
</control-implementation>

<back-matter>
<resource uuid="090ab379-2089-4830-b9fd-26d0729e22e9">
<title>Access Control and Identity Management Policy</title>
<description>
<p>Policy Document.</p>
</description>
<prop name="type">policy</prop>
<base64
filename="./documents/policies/sample_policy.pdf">0000</base64>

fedramp.gov 39
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

</resource>
</back-matter>

5. FedRAMP Extensions and Accepted Values


NIST designed the core OSCAL syntax to meet model
cybersecurity information that is common to any organization A summary of the
and compliance framework. They recognized that each FedRAMP extensions and
framework and organization may have unique needs. Instead of accepted values appears
trying to provide a language that meets each of those unique in the FedRAMP OSCAL
needs, NIST gave organizations the ability to tailor OSCAL to Registry.
address specific needs.

FedRAMP has tailored OSCAL by specifying:

• Extensions: allow FedRAMP's OSCAL-based content to capture information that is not


available in the core OSCAL syntax.
• Accepted Values: For many fields, FedRAMP specifies a case-sensitive set of accepted
values. Only these values are recognized by FedRAMP processing tools.

5.1.1. FedRAMP Extensions All FedRAMP extensions include a


There are several pieces of information namespace (ns) flag set to
required in FedRAMP templates that cannot be "https://fedramp.gov/ns/oscal".
modeled using the OSCAL core syntax. NIST
wanted to limit the core OSCAL syntax to those elements that are universal across most
cybersecurity frameworks. They designed OSCAL to be extended where unique needs existed.

NIST allows organizations to extend OSCAL anyplace prop fields or part assemblies exist in
the core syntax. (Please note, there are currently no part assemblies in the SSP, SAP, SAR,
or POA&M.) There are two fundamental requirements for extending OSCAL:

• The organization must establish a unique namespace (ns) identifier, such as


(ns="http://domain.tld/ns/oscal"), and use it to consistently tag all prop and
part extensions from that organization.

fedramp.gov 40
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

• The organization is responsible for defining, managing, and communicating all names
(name="scan-type") defined and tagged with the above name space identifier.
NIST's core OSCAL prop assemblies have no ns flag. If an ns flag is present, it is an
organization-defined extension. This allows each industry standards body or organization to
create their own extensions in their own name space without concern for overlapping names.

The above approach ensures two different organizations can create their own extensions
without concern for reusing the same name values. At some point in the future, NIST may
provide a registry for organizational extensions. For now, FedRAMP is publishing its own
registry to document its extensions.

All FedRAMP extensions must have a namespace (ns) flag set to


"https://fedramp.gov/ns/oscal".

For example, if the core OSCAL syntax has a status field, but both FedRAMP and the payment
card industry (PCI) require their own framework-specific status field, each may define an
extension with the name="status" and assign their own ns flag. This results in three possible
status fields as follows:

NIST OSCAL User Representation


<!-- There is no @ns, so this is core OSCAL syntax -->
<prop name="status" value="active" />

XPath Query
//prop[@name="user"][not(@ns)]

When searching an OSCAL file for a prop or prop extensions that is part of the core
OSCAL syntax, developers must filter out any with an ns flag using the syntax above.

FedRAMP User Representation


<prop name="status" ns="https://fedramp.gov/ns/oscal"
value="FedRAMP Status" />

XPath Query
//prop[@name="status"][@ns="https://fedramp.gov/ns/oscal"]

(Possible) PCI User Representation


<prop name="user" ns="https://pcisecuritystandards.org/ns/oscal"
value="PCI User" />

fedramp.gov 41
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

XPath Query
//prop[@name="user"][@ns="https://pcisecuritystandards.org/ns/oscal"]

* This is an example, and is not intended to represent an actual PCI extension.

Tool developers must always refer to extensions using both the name and ns flags as a pair.

All FedRAMP extensions will appear as:


<prop name="____" ns="https://fedramp.gov/ns/oscal" value="Value"/>

NOTE: The catalog and profile OSCAL models also allow the part assembly to be used for
extensions. This is not currently the case for the OSCAL SSP, SAP, SAR, or POA&M.

FedRAMP extensions are cited in relevant portions of this document and summarized in
the FedRAMP OSCAL Registry.

Revised FedRAMP Registry Approach


The FedRAMP OSCAL Registry was originally provided as a spreadsheet. It now uses the
draft OSCAL Extensions syntax and is offered in XML and JSON formats, with a human-
readable HTML representation.

• XML Version
• JSON Version
• HTML Version

5.1.2. FedRAMP Conformity Tagging


FedRAMP collaborated with NIST to address the ambiguities in OSCAL syntax necessitating
conformity tags necessary.

5.1.3. OSCAL and FedRAMP-Defined Identifiers


NIST now defines allowed values in a way that supersedes FedRAMP's separate handling of
defined identifiers and accepted values. To better align with NIST, FedRAMP has also shifted to
this approach. Further, many FedRAMP defined values are now recognized by NIST as part of
the core OSCAL syntax.

fedramp.gov 42
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Any remaining defined identifiers or accepted values are enumerated in the FedRAMP OSCAL
registry as allowed values.

5.1.4. OSCAL and FedRAMP Accepted Values


NIST now defines allowed values in a way that supersedes FedRAMP's separate handling of
defined identifiers and accepted values. To better align with NIST, FedRAMP has also shifted to
this approach. Further, many FedRAMP defined values are now recognized by NIST as part of
the core OSCAL syntax.

Any remaining defined identifiers or accepted values are enumerated in the FedRAMP OSCAL
registry as allowed values.

5.1.5. OSCAL and FedRAMP Allowed Values


To facilitate consistent processing, the value for property names, annotation names, and some
field values is limited to a list of case-sensitive allowed values. In many instances, NIST defines
allowed values, which are enforced by OSCAL-based syntax validation mechanisms.

In some cases, FedRAMP defines or adds allowed values specific to FedRAMP ATO
processing. Where defined, only these values are recognized by FedRAMP processing tools.

For example, every control requires an implementation status. FedRAMP only accepts one of
five possible responses for this status, which must be provided using one of the specified
choices.

FedRAMP allowed values are cited in relevant portions of each guidebook and
summarized in the FedRAMP OSCAL Registry.

Revised FedRAMP Registry Approach


The FedRAMP OSCAL Registry was originally provided as a spreadsheet. It now uses the
draft OSCAL Extensions syntax and is offered in XML and JSON formats, with a human-
readable HTML representation. This enables tools to be extension-aware.
• XML Version
• JSON Version
• HTML Version

fedramp.gov 43
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6. Expressing Common FedRAMP Template


Elements In OSCAL
While each FedRAMP template has a unique purpose, they share common information
elements, such as title and publication date. These common elements are expressed using the
same OSCAL syntax for the SSP, SAP, SAR, and POA&M. This section provides OSCAL
syntax for these common elements, including:

• Document Basics:
– Document Title
– Document Publication Date
– Document Version
– Document Sensitivity & Ownership Markings
– Prepared By
– Prepared For
– Document Revision History
• OSCAL-Additional Document Basics:
– Last Modified Date
– OSCAL Syntax Version
• Logos:
– FedRAMP Logo
– CSP Logo
– Assessor Logo
– Consulting 3PAO Logo
• Attachments:
– FedRAMP Acronyms
– FedRAMP Citations (Laws, Regulations, Standards, and Guidance)

The following pages are formatted for tabloid (11" x 17") paper in landscape orientation.

fedramp.gov 44
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.1. Title Page FedRAMP Allowed Value


Required Role ID:
Representation • fedramp-pmo
<metadata>
<title>FedRAMP System Security Plan (SSP)</title>
<published>2022-06-01T00:00:00.000Z</published>
<last-modified>2023-03-03T00:00:00.000Z </last-modified>
<version>0.0</version>
<oscal-version>1.0.4</oscal-version>
<prop name="marking" value="Controlled Unclassified Information" />
<role id="fedramp-pmo">
<title>FedRAMP PMO</title>
<description><p>Description</p></description>
</role>
<!-- cut: location assemblies-->
<party uuid="77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d" type="organization">
<name>FedRAMP: Program Management Office</name>
<short-name>FedRAMP PMO</short-name>
<link href="#a2381e87-3d04-4108-a30b-b4d2f36d001f" rel="logo" />
JAB and NIST Logos are </party>
<responsible-party role-id="fedramp-pmo">
<party-id>77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d</party-id>
Not Necessary </responsible-party>
</metadata>
<!-- OSCAL File Body -->
<back-matter>
<resource uuid="a2381e87-3d04-4108-a30b-b4d2f36d001f">
<description><p>FedRAMP Logo</p></description>
<prop name="type" value="logo" />
<rlink href="https://www.fedramp.gov/assets/img/logo-main-fedramp.png"/>
The FedRAMP Logo is a resource in the back-matter section of the OSCAL-based FedRAMP <base64 filename="FedRAMP_LOGO.png">
<!-- Base64-encoded Logo Cut -->00000000
Templates, and can be referenced with the following XPath: </base64>
/*/metadata/party[@uuid=../responsible-party[@role-id='fedramp-pmo']/party- </resource>
uuid]/link[@rel='logo']/@href </back-matter>

As with any href value, this can include a relative or absolute URI external to the OSCAL file, or it XPath Queries
can contain a URI fragment, pointing to a resource inside the OSCAL file itself (or other OSCAL Document Title:
files in the stack). /*/metadata/title
Document Published Version #:
If the above returns an href value beginning with a hashtag (#), the rest of the value is the UUID /*/metadata/version
value for the resource containing the logo. Drop the hashtag and use the remaining value to locate
Document Published Date (will need to convert data for presentation):
the resource as follows: /*/metadata/published
/*/back-matter/resource[@uuid='[UUID-value-returned-above]']/rlink/@href FedRAMP's Logo:
/*/metadata/party[@uuid=../responsible-party[@role-id='fedramp-pmo']/party-
uuid]/link[@rel='logo']/@href
OR
Document Sensitivity Label (If more than one, tools should present all):
/*/back-matter/resource[@uuid='[UUID-value-returned-above]']/base64 /*/metadata/prop[@name="marking"]

45
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

NOTES:

• There may be more than one Document Sensitivity Label (marking) if needed.
– Tools should display and/or notify the user of all sensitivity markings.
• The logos on older FedRAMP Templates are not necessary. This includes the NIST Logo, as well as the three
Joint Authorization Board (JAB) Agency Logos.

46
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.2. Prepared By (Third Party)


The FedRAMP SAP and SAR must always indicate the assessing organization using this Prepared By syntax.

Representation
<metadata>
<role id="prepared-by">
<title>Prepared By</title> NIST Allowed Value
<description><p>Description</p></description> Required Role ID:
</role>
<!-- cut: other role assemblies--> • prepared-by
<!-- cut: location assemblies-->
<party uuid="f84d8edc-d83e-440d-96c9-09b28c395ad5">
<name>Name of Consulting Org</name>
<short-name>Acronym/Short Name</short-name>
<address type="work">
<!-- address lines cut here for space -->
</address>
</party>
<!-- cut: other party assemblies -->
<responsible-party role-id="prepared-by">
<party-id>f84d8edc-d83e-440d-96c9-09b28c395ad5</party-id>
</responsible-party>
</metadata>

See Section 6.4 for "Prepared for" <!-- OSCAL File Body -->

<back-matter>
<resource id="1507f5e0-635c-4e23-a5f3-93f368f8e022">
<description><p>Peparer Logo</p></description>
<prop name="type" value="logo" />
<!-- Use rlink and/or base64 -->
<rlink href="./party-1-logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>

XPath Queries
Preparer Organization's Name and Address:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-by']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.

NOTES:

• The responsible-party assembly connects the role to the party and is required for compliance.
• If the content was prepared by an organization other than the CSP, their logo should also appear in back-
matter.

47
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.3. Prepared By (CSP Self-Prepared)


This is applicable where the CSP creates or updates its own SSP or POA&M content. The FedRAMP SAP and SAR
must never be CSP self-prepared.

Representation
<metadata>
<role id="prepared-by">
<title>Prepared By</title> NIST Allowed Value
<description><p>Description</p></description> Required Role ID:
</role>
<!-- cut: location assemblies--> • prepared-by
<party id="2e0db7cf-08f5-472e-9360-fb3a9698476d">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym/Short Name</short-name>
<location-uuid>[uuid-value-of-location]</location-uuid>
</party>
<responsible-party role-id="prepared-by">
<party-id>c2e0db7cf-08f5-472e-9360-fb3a9698476dsp</party-id>
</responsible-party>
</metadata>

<!-- OSCAL File Body -->

<back-matter>
<resource id="74a61c36-ad18-4ee3-8bc4-6e2f917b0ce8">
<description><p>CSP Logo</p></description>
<prop name="type" value="logo" />
See Section 6.4 for "Prepared for" <!-- Use rlink and/or base64 -->
<rlink href="./logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>

XPath Queries
Preparer Organization's Name and Address:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-by']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.

NOTES:

• The responsible-party assembly connects the role to the party and is required for compliance.

48
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.4. Prepared For (CSP)


For FedRAMP SSP, SAP, SAR, and POA&M, the "Prepared For" is typically the CSP; however, it may be different if
an unforeseen circumstance requires another party to be named. For this reason, "Prepared For" and CSP have
separately defined roles.

Representation
<metadata>
<!-- prop -->
See Sections 6.2 and 6.3 for "Prepared by" <role id="prepared-for">
<title>Prepared For</title>
<description><p>The CSP for FedRAMP SSP, SAP, SAR, and POA&amp;M.</p></description>
</role>
<role id="cloud-service-provider">
<title>Cloud Service Provider</title>
<short-name>CSP</short-name>
</role>
<!-- cut: location assemblies-->
<party id="2e0db7cf-08f5-472e-9360-fb3a9698476d">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym/Short Name</short-name>
<location-uuid>[uuid-value-of-location]</location-uuid>
</party>
<!-- cut: other party assemblies -->
<responsible-party role-id="prepared-for">
<party-id>2e0db7cf-08f5-472e-9360-fb3a9698476d</party-id>
</responsible-party>
</metadata>
<!-- OSCAL File Body -->
<back-matter>
<resource id="74a61c36-ad18-4ee3-8bc4-6e2f917b0ce8">
<description><p>CSP Logo</p></description>
<prop name='type'>logo</prop>
<!-- Use rlink and/or base64 -->
<rlink href="./logo.png" media-type="image/png" />
<base64>00000000</base64>
</resource>
</back-matter>

XPath Queries
Prepared For (CSP) Details:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-for']/party-
id]]/org/org-name
Prepared For Details:
/*/metadata/party[@id=[/*/metadata/responsible-party[@role-id='prepared-for']/party-
id]]/org/org-name
NOTE: Replace "org-name" with "address/addr-line", "address/city", "address/state", or
"address/zip" as needed. There may be more than one addr-line.

49
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.5. Document Revision History


The OSCAL revision history requires one FedRAMP extension to fully meet FedRAMP's revision history requirements.

Representation
<metadata>
<!-- title, published, last-modified, version, oscal-version -->
<revisions>
<revision>
<published>2022-06-01T00:00:00.000Z</published>
<version>1.0</version>
<oscal-version>1.0.4</oscal-version>
<prop name="party-uuid" ns="https://fedramp.gov/ns/oscal"
value="f84d8edc-d83e-440d-96c9-09b28c395ad5"/>
<remarks><p>Initial publication.</p></remarks>
</revision>
<revision>
<published>2022-06-01T00:00:00.000Z</published>
<version>2.0</version>
<oscal-version>1.0.4</oscal-version>
<prop name="party-uuid" ns="https://fedramp.gov/ns/oscal"
value="2e0db7cf-08f5-472e-9360-fb3a9698476d"/>
<remarks><p>Updated for annual assessment.</p></remarks>
</revision>
<!-- Additional revision assemblies as needed. -->
</revisions>
<!-- doc-id, prop, link, role -->
</metadata> FedRAMP Extension (Author)
prop
(ns="https://fedramp.gov/ns/oscal"):
XPath Queries
• name="party-uuid"
Number of Revision Entries:
count(/*/metadata/revision-history/revision)
Revision Date for Individual Entry:
/*/metadata/revision-history/revision[1]/published
Description for Individual Entry:
/*/metadata/revision-history/revision[1]/remarks/string()
Version for Individual Entry:
The remarks field is Markup multiline, which enables the text to be formatted. This requires /*/metadata/revision-history/revision[1]/version
special handling. See Section 2.5.3 Markup-line and Markup-multiline Fields in OSCAL, or visit: Author for Individual Entry:
https://pages.nist.gov/OSCAL/documentation/schema/datatypes/#markup-multiline /*/metadata/party[@uuid=/*/metadata/revision-history/revision[1]/prop [@name='party-
uuid'][@ns='https://fedramp.gov/ns/oscal']]/org/short-name

Replace "[1]" with "[2]", "[3]", etc.


NOTE: At time of publication, NIST is evaluating the possibility of including party-uuid or similar
in the revision assembly. This section will be updated if that decision is made.
NOTES:

• The Revision History's Author field is addressed using a FedRAMP extension, which points to a metadata
party.

50
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

• The published field requires the OSCAL data type, dateTime-with-timezone.


• FedRAMP only requires the publication date, not the time.
– The time portion may be replaced with all zeros.
– FedRAMP tools should present only the date, and use a more user-friendly format.

51
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.6. How to Contact Us


The FedRAMP email and web site addresses are part of the organizational content for the FedRAMP PMO party. This
information already exists in OSCAL-based FedRAMP Templates.

There must be a role defined in the file with the ID value set to "fedramp-pmo". There must be a party defined
with FedRAMP's details, and there must be a responsible-party defined, linking the "fedramp-pmo" role-id
to the FedRAMP party uuid.

Representation
<metadata>

<role id="fedramp-pmo">
<title>FedRAMP Program Management Office</title>
</role>

<!-- location -->

<party uuid="77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d" type="organization">


<name>FedRAMP Program Management Office</name>
<short-name>FedRAMP PMO</short-name>
<link href="https://fedramp.gov" />
<email>[email protected]</email>
<address type="work">
<addr-line>1800 F St. NW</addr-line>
<addr-line/>
<city>Washington</city>
<state>DC</state>
<postal-code/>
<country>US</country>
</address>
</party>

<responsible-party role-id="fedramp-pmo">
<party-uuid>77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d</party-uuid>
</responsible-party>

</metadata> FedRAMP-Role Identifiers:


• fedramp-pmo

XPath Queries
FedRAMP Email Address:
/*/metadata/party[@uuid=/*/metadata/responsible-party[@role-id='fedramp-pmo']
/party-uuid]/email
FedRAMP Web Site Address:
/*/metadata/party[@uuid=/*/metadata/responsible-party[@role-id='fedramp-pmo']
/party-uuid]/link/@href

52
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.7. Document Approvals


The OSCAL syntax is the same for document approvers in the SSP, SAP, and SAR. For the SSP, approvers are
typically executives within the CSP. For the SAP and SAR, approvers are typically executives within the assessor's
organization.

Representation
<metadata>
<!-- title, published ... prop, link -->
<role id="content-approver">
<title>[SSP, SAP, or SAR] Approval</title>
<desc>The executive(s)accountable for the accuracy of this content.</desc>
</role>
<role id="cloud-service-provider">
<title>Cloud Service Provider</title>
<short-name>CSP</short-name> Defined Identifiers
</role>
<party uuid="uuid-of-csp" type="organization"> Required Role IDs:
<name>Cloud Service Provider (CSP) Name</name> • content-approver
<short-name>CSP Acronym/Short Name</short-name>
• cloud-service-provider
</party>
<party uuid="uuid-of-person-1" type="person">
<name>[SAMPLE]Person Name 1</name>
<prop name="title" ns="https://fedramp.gov/ns/oscal">Individual's Title</prop>
<member-of-organization>uuid-of-csp-party</member-of-organization>
</party>
<party uuid="uuid-of-person-2" type="person">
<name>[SAMPLE]Person Name 2</name>
<prop name="title" ns="https://fedramp.gov/ns/oscal">Individual's Title</prop>
<member-of-organization>uuid-of-csp</member-of-organization>
</party>
<responsible-party role-id="cloud-service-provider">
<party-uuid>uuid-of-csp</party-uuid>
</responsible-party> FedRAMP Extension (Person's Title)
<responsible-party role-id="content-approver">
<party-uuid>uuid-of-person-1</party-uuid> prop
<party-uuid>uuid-of-person-2</party-uuid> (ns="https://fedramp.gov/ns/oscal"):
</responsible-party> • name="title"
</metadata>

XPath Queries
Approver’s Name:
(/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='content-
approver']/party-uuid]]/party-name)[1]
Approver’s Title:
(/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='content-approver']
/party-uuid]]/prop[@name='title'][@ns='https://fedramp.gov/ns/oscal'])[1]
NOTE: For each additional approver, replace the "[1]" with "[2]", "[3]", and so on.
CSP Name:
/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id='cloud-service-
provider']/party-uuid]]/party-name
53
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

NOTES:

The code above is an SSP example For SAP and SAR, a similar approach is used for the assessor, using the
"assessor" role ID instead of the "cloud-service-provider" role ID.

54
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.8. FedRAMP Standard Attachments (Acronyms, Laws/Regulations)


The FedRAMP MS Word-based SSP, SAP and SAR templates included links to the FedRAMP Laws and Regulations
file, as well as the FedRAMP Acronyms file posted on https://fedramp.gov.

These are already included in the OSCAL-based FedRAMP templates as resources. The resource linking to the
FedRAMP citations file is identified with links from the property type, "fedramp-citations". The resource linking
to the FedRAMP acronyms file is identified with the property type, "fedramp-acronyms".

Representation
<metadata>
<!-- cut -->
<party uuid="77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d" type="organization">
<name>FedRAMP: Program Management Office</name>
<short-name>FedRAMP PMO</short-name>
<link href="#985475ee-d4d6-4581-8fdf-d84d3d8caa48" rel="reference" />
<link href="#1a23a771-d481-4594-9a1a-71d584fa4123" rel="reference" />
</party>
</metadata>

<back-matter>

<resource uuid="985475ee-d4d6-4581-8fdf-d84d3d8caa48">
<title>FedRAMP Applicable Laws and Regulations</title>
<prop ns="https://fedramp.gov/ns/oscal" name="type" value="fedramp-citations"/>
<rlink href="https://-cut-/SSP-A12-FedRAMP-Laws-and-Regulations-Template.xlsx"/>
</resource>

<resource uuid="1a23a771-d481-4594-9a1a-71d584fa4123">
<title>FedRAMP Master Acronym and Glossary</title>
<prop ns="https://fedramp.gov/ns/oscal" name="type" value="fedramp-acronyms"/>
<rlink href="https://-cut-/FedRAMP_Master_Acronym_and_Glossary.pdf" />
</resource>

</back-matter>

XPath Queries
Link to FedRAMP Applicable Laws and Regulations:
/*/back-matter/resource/prop[@name='type']
[string(.)='fedramp-citations']/../rlink/@href
Link to FedRAMP Acronyms and Glossary:
/*/back-matter/resource/prop[@name='type']
[string(.)='fedramp-acronyms']/../rlink/@href

55
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.9. Additional Laws, Regulations, Standards or Guidance


Additional citations must be represented as additional resource assemblies. One resource assembly per citation.
This applies to applicable laws, regulations, standards, or guidance beyond FedRAMP's predefined set.

Each must have a type defined. The value of the type filed must be set to "law", "regulation", "standard", or "guidance"
as appropriate. There may be more than one type defined. FedRAMP tools use the type property to differentiate
these resource assemblies from others.

Representation
<back-matter>
<resource uuid="d45612a9-cf25-4ef6-b2dd-69e38ba2967a">
<title>[SAMPLE]Name or Title of Cited Law</title>
<prop name="type" value="law"/>
<prop name="publication" value="Document Date"/>
<prop name="version" value="Document Version"/>
<doc-id type="doi">Identification Number</doc-id>
<rlink href="https://domain.example/path/to/document.pdf" />
</resource>
<resource uuid="a8a0cc81-800f-479f-93d3-8b8743d9b98d">
<title>[SAMPLE]Name or Title of Cited Regulation</title>
<prop name="type" value="regulation"/>
<prop name="publication" value="Document Date"/>
<prop name="version" value="Document Version"/>
<doc-id type="doi">Identification Number</doc-id>
<rlink href="https://domain.example/path/to/document.pdf" />
</resource>
<!-- repeat citation assembly for each law, regulation, standard or guidance -->
<!-- resource -->
</back-matter>

XPath Queries
Replace "[1]" with "[2]", "[3]", etc.
Number of Laws and Regulations (integer):
count(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])
Laws and Regulations - Identification Number:
(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])[1]/../doc-id
Laws and Regulations - Title:
(/*/back-matter/resource/prop[@name="type"]
[(string(.) = "law") or (string(.)="regulation")])[1]/../title
Laws and Regulations - Date:
(/*/back-matter/resource/prop[@name="type"][(string(.) = "law") or
(string(.)="regulation")])[1]/../prop[@name="publication"]
Laws and Regulations - Link:
(/*/back-matter/resource/prop[@name="type"][(string(.) = "law") or
(string(.)="regulation")])[1]/../rlink/@href
NOTE: For Standards and Guidance replace "law" with "standard" and "regulation" with
"guidance" in the above queries to generate the Standards and Guidance tables.

56
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

6.10.Attachments and Embedded Content


There are several attachments in a classic FedRAMP MS Word based SSP, SAP, SAR document or Deviation
Request (DR) form. Some lend well to machine-readable format, while others do not. Those that are readily modeled
in machine-readable format are typically addressed within the OSCAL syntax, while attachments such as policies,
procedures, plans, guides, and rules of behavior documents are all treated as attachments in OSCAL as well.
Further, any diagrams or images that normally appear in context, such as the authorization boundary diagram, are
attached in the back-matter and referenced from the body of the OSCAL file, as described in Section 2.7 Citations,
Attachments, and Embedded Content in OSCAL Files. The following table represents attachments and embedded
content.

Attachment Representation

<!-- cut -->


<back-matter>
<!-- citation -->
<resource uuid="fab59751-b855-40cb-93c1-492562e20e18">
<title>Name of Procedure Document</title>
<prop name="type" value="procedure"/>
<prop name="publication" value="Document Date"/>
<prop name="version" value="Document Version"/>
<!-- Add rlink with relative path OR embed with base64 encoding -->
<rlink href="./procedure.docx" />
<base64>00000000</base64>
</resource>

<resource id="diag-boundary-1">
<description>
<p>The primary authorization boundary diagram.</p>
</description>
<!-- Add rlink with relative path or embed with base64 encoding -->
<rlink media-type="image/png" href="./boundary.png" />
<base64 media-type="image/png" filename="boundary.png">00000000</base64>
<remarks><p>Set system-characteristics/authorization-boundary/diagram/link/@href =
"#diag-boundary-1"</p></remarks>
</resource> Replace "policy" with "plan", "rob",
</back-matter> etc. for each attachment type.

XPath Queries
PIA Attachment (Embedded Base64 encoded):
/*/back-matter/resource/prop[@name='type']
[string(.)='privacy-impact-assessment']/.. /base64
PIA Attachment (Relative Link):
/*/back-matter/resource/prop[@name=type]
[string(.)='privacy-impact-assessment']/.. /rlink/@href
Publication Date of PIA:
/*/back-matter/resource/prop[@name=type]
[string(.)='privacy-impact-assessment']/../prop[@name="publication"]

57
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Tools creating OSCAL content should include a media-type for all rlink and base64 fields, as well as a
filename for all base64 fields.
Tools should process rlink and base64 content with or without these fields. Where present they should be used
when validating or rendering the linked or embedded content.

58
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

APPENDICES
Appendix A. OSCAL-Based FedRAMP Baselines
NIST designed OSCAL catalogs as the primary source of control definition information from a
framework publisher. Catalogs are typically only published by organizations such as NIST for
NIST SP 800-53, or ISO/IEC for standards such as their 27000 series. If an organization has
unique control definitions that fall outside an applicable framework, the organization must create
a catalog containing those unique control definitions.

NIST designed profiles as the primary means of defining a baseline of controls. An OSCAL
profile may identify and even modify controls from one or more catalogs and even from other
profiles. This approach ensures control additions, modifications, or removal are fully traceable
back to the source of the modification.

OSCAL CATALOG OSCAL PROFILE OSCAL PROFILE


NIST 800-53 r4 NIST 800-53 r4 – High FedRAMP – High
NIST 800-53A r4
SP 800-53 Control Definition: SP 800-53 Control Selection
• Requirement Statements FedRAMP Control Modifications:
• Associated Guidance • Additional Requirement
• Parameter Definition Statements
• Assessment Objectives • Parameter Constraints
• Assessment Activities • Additional Guidance

SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection


FedRAMP Control Modifications

SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection

OSCAL CATALOG
FedRAMP
FedRAMP Control Definition FedRAMP Control Selection

FedRAMP Control Definition FedRAMP Control Selection

FedRAMP Control Definition FedRAMP Control Selection

FedRAMP's baselines are represented as OSCAL profiles. The correct profile must be selected
from the SSP based on the system's identified security categorization level. This can be
checked using the XPath syntax below.

fedramp.gov 59
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Security Sensitivity Level XPath Query


(SSP) Security Categorization Level:
/*/system-characteristics/security-sensitivity-level

This determines which URL should be entered for the import-profile field in an OSCAL-
based FedRAMP SSP.

Baseline Representation
<!-- metadata -->
<!-- This must point to the appropriate FedRAMP Baseline -->
<import-profile href="https://path/to/FedRAMP_MODERATE-baseline_profile.xml"/>
<!-- system-characteristics -->

fedramp.gov 60
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

FedRAMP validation tools will compare the identified security categorization level to the actual
FedRAMP baseline specified in the SSP and raise a warning if a different baseline was used.

High (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-
baseline_profile.xml

JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_HIGH-
baseline_profile.json

Moderate (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-
baseline_profile.xml

JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_MODERATE-
baseline_profile.json

Low (Rev 5)
XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_LOW-
baseline_profile.xml

JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_LOW-
baseline_profile.json

Do not copy and modify the FedRAMP baseline. FedRAMP will use the original, published
file for validation, ignoring any modified copies.

If you require a modification to the FedRAMP baselines, such as may be required when directed
to do so by an authorizing official, first contact FedRAMP to coordinate the modification, then
follow the instructions in Appendix B.

When FedRAMP publishes baselines for NIST SP 800-53 Revision 5, they will be located here:
https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/baselines

fedramp.gov 61
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

FedRAMP Tailored
FedRAMP Tailored for Low Impact – Software as a Service (LI-SaaS) Appendix B merges SSP,
SAP, and SAR information into a single document. The SSP portions of that document may be
represented using the same OSCAL conventions described in this document with only a few
minor differences.

Specific OSCAL-based FedRAMP Tailored guidance will be published at a later date; however,
fully representing Appendix B in OSCAL requires the SSP, SAP, and SAR syntax, used the
same way as they are explained for FedRAMP Low, Moderate, and High baselines.

For your convenience, FedRAMP has made the FedRAMP Tailored for LI-SaaS baseline
available now in both XML and JSON formats as follows:

Low-Impact SaaS (Tailored)


XML Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/xml/FedRAMP_rev5_LI-SaaS-
baseline_profile.xml

JSON Version:
https://raw.githubusercontent.com/GSA/fedramp-
automation/master/dist/content/rev5/baselines/json/FedRAMP_rev5_LI-SaaS-
baseline_profile.json

fedramp.gov 62
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Appendix B. Modifying a FedRAMP Baseline


OSCAL is designed to allow modification of controls Create a new profile, importing to the
and baselines, while maintaining traceability through appropriate FedRAMP profile, then use
each layer of modification. This means you must profile syntax to make necessary
create a new profile as a means of modifying an changes.
existing profile.
FedRAMP does not typically allow
If you require a change to a FedRAMP baseline, you modifications to its baselines. This
should first coordinate that change with the capability is present only in the event
FedRAMP JAB or PMO. Assuming FedRAMP of a policy change or unforeseen
agrees with the change, the correct way to circumstances.
implement the change is as follows:

1. Create a new, blank OSCAL Profile.


2. Point to the FedRAMP Baseline: Point it to the appropriate FedRAMP baseline using
an import field.
3. Select the Relevant Controls: Use the include and exclude fields to identify the
controls to include or exclude from the FedRAMP baseline.
a. For example, if you need all but one control, you can include all, then exclude
the one.
4. Specify How Controls Are Organized: FedRAMP prefers you merge "as-is" using
those merge fields. This is relevant when resolving the profile. See the Profile Resolution
section of this appendix for more information.
5. Modify the Selected Controls: Use the modify assembly to make modifications to
parameters and control definitions.
The next page contains an example profile, which accomplishes the following actions:

• Imports the FedRAMP Moderate baseline


• Includes all controls from that baseline
• Explicitly removes AT-4 from the baseline
• Indicates that if this profile is resolved, the organization of the controls should remain as-
is. See the Profile Resolution section of this appendix for more information.
• Adds a constraint to the third parameter of AC-1 (ac-1_prm_3), which is more restrictive
than the FedRAMP constraint, but changing it from "at least annually" to "at least every
six months."
• Removes the additional FedRAMP requirement statement in AU-11 and replaces it with
a more restrictive statement, which now requires online retention of audit records for at
least 180 days instead of 90 days.

fedramp.gov 63
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

For more information on working with profiles, please visit the NIST OSCAL site at:
https://pages.nist.gov/OSCAL

A complete OSCAL profile syntax reference is available here:


https://pages.nist.gov/OSCAL/concepts/layer/control/profile/

Sample Profile to Modify a FedRAMP Baseline


<profile xmlns="http://csrc.nist.gov/ns/oscal/1.0"
uuid="-UUID-value-cut-">
<metadata>
<title>[XYZ Org] Modification to FedRAMP Moderate Baseline</title>
<last-modified>2023-03-06T08:05:30.000Z</last-modified>
<version>fedramp2.0.0-oscal1.0.4</version>
<oscal-version>1.0.4</oscal-version>
</metadata>
<import href="https://path/to/FedRAMP_MODERATE-baseline_profile.xml">
<!-- Include every control (and child control) in the Moderate
baseline -->
<include-all />
<exclude-controls with-child-controls="yes">
<!-- Remove Control AT-4 -->
<with-id>at-4</with-id>
</exclude-controls>
</import>
<merge><as-is>yes</as-is></merge>
<modify>
<set-parameter id="ac-1_prm_3">
<!-- Change the constraint from "at least annually" -->
<constraint>
<description>
<p>at least every six months</p>
</description>
</constraint>
</set-parameter>
<alter control-id="au-11">
<remove by-id="au-11_fr" />
<add position="ending">
<part id="au-11_fr" name="item">
<title>[XYZ Org]Modified Requirement</title>
<part id="au-11_fr_smt.1" name="item">
<prop name="label">Requirement:</prop>
<p>The service provider retains audit records on-
line for at 180 days and further preserves audit records off-line for a
period that is in accordance with NARA requirements.</p>
</part>
</part>
</add>

fedramp.gov 64
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

</alter>
</modify>
</profile>

fedramp.gov 65
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Appendix C. Profile Resolution


Profiles are intended to identify upstream sources
of control definition information and show only the Profile resolution flattens or merges a
changes to those upstream sources. This enables profile and its imported catalog(s) and
humans and computers to trace control definition profiles into a single OSCAL file using
changes back to their source framework. the catalog syntax.

While this ensures traceability of selected controls and modified content, it can also be resource
intensive. Profile resolution flattens or merges a profile and its imported catalog(s) and profiles
into a single OSCAL file using the catalog syntax.

OSCAL CATALOG OSCAL PROFILE OSCAL PROFILE OSCAL RESOLVED PROFILE


NIST 800-53 r4 NIST 800-53 r4 – High FedRAMP – High FedRAMP High Resolved Profile
NIST 800-53A r4 Catalog
SP 800-53 Control Definition: SP 800-53 Control Selection SP 800-53 Control Definition
• Requirement Statements with FedRAMP Modifications:
FedRAMP Control Modifications:
• Associated Guidance • Additional Requirement
• Additional Requirement
• Parameter Definition Statements
Statements
• Assessment Objectives • Parameter Constraints

COLLAPSES ALL TO A SINGLE FILE


• Parameter Constraints
• Assessment Activities • Additional Guidance
• Additional Guidance

PROFILE RESOLUTION
SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection SP 800-53 Control Definition
with FedRAMP Modifications
FedRAMP Control Modifications

SP 800-53 Control Definition SP 800-53 Control Selection SP 800-53 Control Selection SP 800-53 Control Definition

OSCAL CATALOG
FedRAMP
FedRAMP Control Definition FedRAMP Control Selection FedRAMP Control Definition

FedRAMP Control Definition FedRAMP Control Selection FedRAMP Control Definition

FedRAMP Control Definition FedRAMP Control Selection FedRAMP Control Definition

This single file is essentially a pre-processed result of the profile import and modification
content. A resolved profile catalog is useful for the FedRAMP baselines given their static nature.
Any tool that would normally open an OSCAL-based FedRAMP profile and process it against
the NIST SP 800-53 catalog can instead simply use the resolved-profile catalog.

Each FedRAMP XML and JSON baseline profile has a resolved profile catalog in the same
location as the pre-processed profile. Where available, these may be used by tools to save
processing time.

The merge assembly within an OSCAL profile offers a profile resolver control over how the final
file is organized. To maintain the same organization as within the catalog, simply use the as-is
field and set it to "yes."

The complete profile syntax is available here:

fedramp.gov 66
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

https://pages.nist.gov/OSCAL/concepts/layer/control/profile/

fedramp.gov 67
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

NIST's Profile Resolution Tool


NIST created a profile resolution specification, and built a profile resolution capability based on
that specification. The specification can be found here:

https://github.com/usnistgov/OSCAL/tree/main/src/specifications/profile-resolution

The actual tool can be found here:

https://github.com/usnistgov/OSCAL/tree/main/src/utils/util/resolver-pipeline

Currently the tool requires the profile and all imported catalogs and profiles to be in XML format.
For now, JSON content must be converted to XML before using this tool.

The tool requires an XSLT 3.1 processor, which is the same requirement for XML to JSON and
JSON to XML conversions.

All XSL files provided at the link above must be in the same directory. Only oscal-profile-
RESOLVE.xsl must be identified to the XSLT processor. All other files are called by this file as
part of processing.

It is also possible to run the scripts directly from the NIST OSCAL repository by supplying the
following URL directly to the XSLT processor:

https://raw.githubusercontent.com/usnistgov/OSCAL/main/src/utils/util/resolver-pipeline/oscal-
profile-RESOLVE.xsl

This is a new capability provided by NIST and leveraged by FedRAMP. Please report bugs or
provide feedback related to this tool directly to NIST at [email protected] or by submitting an issue
here:

https://github.com/usnistgov/OSCAL/issues

Appendix D. Working with Roles, Locations, People, and Organizations


An OSCAL file defines roles, people, and organizations within the metadata as part of three
separate assemblies:

• role: A role ID and role title are required. Other content, such as a short-name,
description, or remarks are optional.
• location: Locations, such as corporate offices and data center addresses, are defined
as location assemblies
• party: People and organizations are defined as party assemblies. An organization is
any collection of people, and can represent a company, agency, department, or team.

fedramp.gov 68
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

• responsible-party: Links roles to parties. The same role can have more than one
party assigned to it. Also a party can be assigned to more than one role.
FedRAMP Defined Party Identifiers
FedRAMP has eliminated the use of FedRAMP-Defined Party Identifiers.

With the transition from ID to UUID for party identifiers this is no longer possible. Further, this
helps ensure OSCAL remains compatible with multiple compliance frameworks.

Working with Role Assemblies


All roles within the document are defined under the metadata element as follows:
<metadata>
<!--- cut --->
<role id="prepared-by">
<title>Prepared By</title>
<description>
<p>The organization that prepared this SSP.</p>
</description>
</role>
<role id="prepared-for">
<title>Prepared For</title>
<description>
<p>The organization for which this SSP was prepared</p>
</description>
</role>
<!--- cut --->
</metadata>

To ensure consistent processing, FedRAMP has defined a specific set of roles that must exist
with a FedRAMP SSP, SAP, SAR, or POA&M. Most are pre-populated in the OSCAL-based
FedRAMP Templates. They vary by template.

OSCAL-based FedRAMP tools must ensure these roles, titles, and descriptions exist using the
prescribed role IDs within an OSCAL-based FedRAMP file. Additional roles may be added,
provided these roles remain.

NIST-defined and FedRAMP-defined role-identifiers are cited in relevant portions of each


guide, and summarized in the FedRAMP OSCAL Registry.

fedramp.gov 69
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Working with Location Assemblies


The location assembly is intended to represent the address of a location such as the HQ of a
CSP or 3PAO, a data center, or an Agency.

Some locations are required. For example, the SSP must contain the at least one location
assembly with the primary business address of the CSP. The SAP and SAR must contain at
least one location assembly with the primary business address of the assessor.

OSCAL allows the title field to be optional. FedRAMP strongly encourages its use. If the
country field is missing, FedRAMP tools will assume the address is within the United States of
America.
<metadata>
<!-- role -->
<location uuid="uuid-of-hq-location">
<title>CSP HQ</title>
<address type="work">
<addr-line>1234 Some Street</addr-line>
<city>Haven</city>
<state>ME</state>
<postal-code>00000</postal-code>
<country>us</country>
</address>
<prop name="type" class="primary" value="data-center"/>
</location>
<!-- party -->
</metadata>

Some locations require type properties to ensure FedRAMP tools can accurately identify
required content. For example, the location assembly for a data center must include a type
property with a value of "data-center". The class may be used to indicate whether the data
center is "primary" or "alternate".

fedramp.gov 70
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Working with Party Assemblies


Party assemblies may be used to represent individuals, teams, or an entire company/agency.
When representing an individual, the type flag must have a value of "person". When
representing a team, company or agency, the type flag must have a value of
"organization". FedRAMP artifacts typically require an individual's title to be identified, the
prop “job-title" is designated for this purpose.

Contact details, such as an individual's email address and phone number, or a business web
site, may be included and are often required within FedRAMP artifacts. A short-name filed
provides an ability to define an organization's acronym or desired abbreviation. This is required
for the CSP, assessor, and any Agency.
<metadata>
<!-- role -->
<party uuid="uuid-of-csp" type="organization">
<name>Cloud Service Provider (CSP) Name</name>
<short-name>CSP Acronym</short-name>
<link href="https://www.csp.com" />
</party>

<party uuid="uuid-of-person-1" type="person">


<name>[SAMPLE]Person Name 1</name>
<prop name="job-title" value="Individual's Title"/>
<email-address>[email protected]</email-address>
<telephone-number>202-555-0000</telephone-number>
</party>
</metadata>

FedRAMP extensions are cited in relevant portions of each guide, and summarized in the
FedRAMP OSCAL Registry.

fedramp.gov 71
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Identifying Organizational Membership of Individuals


An individual may be affiliated with one or more teams/organizations.
Use one member-of-organization field for each team, and one to link the individual to their
employer.
<metadata>
<!-- role -->
<party uuid="uuid-of-csp" type="organization">
<name>Cloud Service Provider (CSP) Name</name>
</party>

<party uuid="uuid-of-it-dept" type="organization">


<name>CSP's IT Department</name>
</party>

<party uuid="uuid-of-person-1" type="person">


<name>[SAMPLE]Person Name 1</name>
<member-of-organization>uuid-of-csp</member-of-organization>
<member-of-organization>uuid-of-it-dept</member-of-organization>
</party>
</metadata>

fedramp.gov 72
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Identifying the Address of People and Organizations


Representing the address of people or organizations (parties) may be accomplished with one of
three approaches:

Preferred Approach: When multiple parties share the same address, such as multiple staff
members at a company HQ, define the address once as a location assembly, then use the
location-uuid field within each party assembly to identify the location of that individual or
team.

Alternate Approach: If the address is unique to this individual, it may be included in the party
assembly itself.

Hybrid Approach: It is possible to include both a location-uuid and an address assembly


within a party assembly. This may be used where multiple staff are in the same building, yet
have different office numbers or mail stops. Use the location-uuid to identify the shared
building, and only include a single addr-line field within the party's address assembly.

A tool developer may elect to always create a location assembly, even when only used once;
however, tools must recognize and handle all of the approaches above when processing
OSCAL files.
<metadata>
<!-- cut -->
<location uuid="uuid-of-hq-location">
<title>CSP HQ</title>
<address type="work">
<addr-line>1234 Some Street</addr-line>
<city>Haven</city>
<state>ME</state>
<postal-code>00000</postal-code>
</address>
</location>

<party uuid="uuid-of-csp" type="organization">


<name>Cloud Service Provider (CSP) Name</name>
<location-uuid>uuid-of-hq-location</location-uuid>
</party>

<party uuid="uuid-of-person-1" type="person">


<name>[SAMPLE]Person Name 1</name>
<prop name="mail-stop" value="A-1"/>
<location-uuid>uuid-of-hq-location</location-uuid>
</party>
</metadata>

fedramp.gov 73
Guide to OSCAL-Based FedRAMP® Content – Rev5
User Implementation Guide | Fedramp2.0.0-oscal1.0.x | 06/30/2023

Working with Responsible Party Assemblies


The responsible party assembly links party assemblies (people and organizations) to defined
roles. FedRAMP tools rely on these linkages to find required content.

For example, an OSCAL-based SSP must have a role defined for the System Owner using the
role ID value "system-owner". The responsible-party assembly links this required role to the
individual (party). FedRAMP tools follow this linkage to verify that a system owner was identified
in the SSP, and to display that information to reviewers.
<metadata>
<!-- party -->
<responsible-party role-id="system-owner">
<party-uuid>uuid-of-person-1</party-uuid>
</responsible-party>
</metadata>

fedramp.gov 74

You might also like