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).
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 Content**| Today, FedRAMP content is enforced programmatically. FedRAMP 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.| + +## 2.4. OSCAL's Minimum File Requirements + +Every OSCAL-based FedRAMP file must have a minimum set of required +fields/assemblies, and must follow the core OSCAL syntax found here: + + +In addition to the core OSCAL syntax, the following FedRAMP-specific +implementation applies: + +- The root element of the file indicates the type of content within + the body of the file. The recognized OSCAL root element types are as + follows: + + - **catalog**: Contains a catalog of control definitions, control + objectives, and assessment activities, such as NIST SP 800-53 + and 800-53A. + + - **profile**: Contains a control baseline, such as FedRAMP + Moderate + + - **component**: Contains information about a product, service, or + other security capability, such as the controls it can satisfy. + + - **system-security-plan**: Describes a system and its security + capabilities, including its authorization boundary and a + description of how each control is satisfied. + + - **assessment-plan**: Describes the plan for assessing a specific + system. + + - **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. + +- 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. + +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](https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/templates) + +#### An Empty OSCAL File Representation +{{< highlight xml "linenos=table" >}} + +
, \
- \,
+\, \, \
, or \
. 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
+{{< highlight xml "linenos=table" >}}
+
+
+ The xyz system performs ...
+
+{{< /highlight >}}
+
+
+The simplest way to correct the error is to enclose the text in
+\\
tags, within the ```description``` field.
+
+#### Correct Markup-multiline Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ The xyz system performs ...
+
+
+{{< /highlight >}}
+
+
+The example below demonstrates a correct use of markup-multiline in XML.
+Please note, the inclusion of a \ tag on a line by itself inserts
+an empty paragraph. Within XML and HTML, this is treated as a shortcut,
+and is interpreted as "\\
"
+
+#### Correct Markup-multiline Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ The xyz system performs ...
+ The xyz system further supports ... as follows:
+
+
+ Cell A1
+ Cell B1
+
+
+ Cell A2
+ Cell B2
+
+
+ Big Header
+ More detail
+ 
+
+
+{{< /highlight >}}
+
+For more information, please visit:
+[https://pages.nist.gov/OSCAL/reference/datatypes/#markup-data-types](https://pages.nist.gov/OSCAL/reference/datatypes/#markup-data-types)
+
+### 2.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](https://pages.nist.gov/OSCAL/reference/datatypes/#specialized-character-mapping)
+
+## 2.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.
+{{< highlight xml "linenos=table" >}}
+
+
+ Attachment or Document Title
+ An optional description of the attachment.
+
+ 00000000
+
+
+
+{{< /highlight >}}
+
+The ```media-type``` flag should be present and must be set to an [Internet
+Assigned Numbers Authority (IANA) Media
+Type](http://www.iana.org/assignments/media-types/media-types.xhtml).
+
+### 2.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.
+
+### 2.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:
+{{< highlight xml "linenos=table" >}}
+
+{{< /highlight >}}
+
+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.
+
+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.
+
+### 2.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.
+
+### 2.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.
+
+### 2.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.
+ {{< highlight xml "linenos=table" >}}
+
+
+ Attachment or Document Title
+ 0000000
+
+
+ {{< /highlight >}}
+
+### 2.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)
+
+ {{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+
+
+ Access Control and Identity Management Policy
+
+ Policy Document.
+
+
+ 0000
+
+
+
+ {{< /highlight >}}
+
+The following represents an example linking a policy to the control it
+satisfies via the preferred component-based approach.
+ {{< highlight xml "linenos=table" >}}
+
+
+ [EXAMPLE]Access Control and Identity Management
+ Policy
+
+ [EXAMPLE]An example component representing a policy.
+
+
+
+
+
+
+
+
+
+
+ Describe how statement a is satisfied by this policy.
+
+
+
+
+
+
+
+
+ Access Control and Identity Management Policy
+
+ Policy Document.
+
+ policy
+ 0000
+
+
+ {{< /highlight >}}
+
diff --git a/docs/content/guides/general/3-fedramp-extensions-and-accepted-values.md b/docs/content/guides/general/3-fedramp-extensions-and-accepted-values.md
new file mode 100644
index 000000000..46b1ab55f
--- /dev/null
+++ b/docs/content/guides/general/3-fedramp-extensions-and-accepted-values.md
@@ -0,0 +1,184 @@
+---
+title: FedRAMP Extensions and Accepted Values
+section: /general/
+toc:
+ enabled: true
+weight: 102
+---
+
+NIST designed the core OSCAL syntax to meet model cybersecurity
+information that is common to any organization and compliance framework.
+They recognized that each framework and organization may have unique
+needs. Instead of trying to provide a language that meets each of those
+unique needs, NIST gave organizations the ability to tailor OSCAL to
+address specific needs.
+
+{{}}
+_A summary of the FedRAMP extensions and accepted values appears in the FedRAMP OSCAL Registry._
+{{ }}
+
+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.
+
+### 3.1.1. FedRAMP Extensions
+
+There are several pieces of information required in FedRAMP templates
+that cannot be 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.
+
+{{}}
+_All FedRAMP extensions include a namespace (ns) flag set to "https://fedramp.gov/ns/oscal"._
+{{ }}
+
+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.
+
+- 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
+{{< highlight xml "linenos=table" >}}
+
+ }}
+_***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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_
+- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_
+- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_
+{{ }}
+
+### 3.1.2. FedRAMP Conformity Tagging
+
+FedRAMP collaborated with NIST to address the ambiguities in OSCAL
+syntax necessitating conformity tags necessary.
+
+### 3.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.
+
+Any remaining *defined identifiers* or *accepted values* are enumerated
+in the FedRAMP OSCAL registry as *allowed values*.
+
+### 3.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*.
+
+### 3.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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_
+- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_
+- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_
+{{ }}
diff --git a/docs/content/guides/general/4-expressing-common-fedramp-template-elements-in-oscal.md b/docs/content/guides/general/4-expressing-common-fedramp-template-elements-in-oscal.md
new file mode 100644
index 000000000..bf701a641
--- /dev/null
+++ b/docs/content/guides/general/4-expressing-common-fedramp-template-elements-in-oscal.md
@@ -0,0 +1,719 @@
+---
+title: Expressing Common FedRAMP Template Elements In OSCAL
+section: /general/
+toc:
+ enabled: true
+weight: 103
+---
+
+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.**
+
+## 4.1. Title Page
+
+
+
+{{}}
+The **FedRAMP Logo** is a resource in the back-matter section of the OSCAL-based FedRAMP Templates, and can be referenced with the following XPath:
+
+``` /*/metadata/party[@uuid=../responsible-party[@role-id='fedramp-pmo']/party-uuid]/link[@rel='logo']/@href```
+
+As with any href value, this can include a relative or absolute URI external to the OSCAL file, or it can contain a URI fragment, pointing to a resource inside the OSCAL file itself (or other OSCAL files in the stack).
+
+If the above returns an href value beginning with a hashtag (#), the rest of the value is the UUID value for the resource containing the logo. Drop the hashtag and use the remaining value to locate the resource as follows:
+
+``` /*/back-matter/resource[@uuid='[UUID-value-returned-above]']/rlink/@href```
+
+OR\
+
+``` /*/back-matter/resource[@uuid='[UUID-value-returned-above]']/base64```
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+ FedRAMP System Security Plan (SSP)
+ 2022-06-01T00:00:00.000Z
+ 2023-03-03T00:00:00.000Z
+ 0.0
+ 1.0.4
+
+ FedRAMP PMO
+ Description
+
+
+ FedRAMP: Program Management Office
+ FedRAMP PMO
+
+
+
+ 77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d
+
+
+
+
+
+ FedRAMP Logo
+ 00000000
+
+
+
+{{}}
+
+
+{{}}
+**FedRAMP Allowed Value** \
+Required Role ID:
+- fedramp-pmo
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+Document Title:
+ /*/metadata/title
+Document Published Version #:
+ /*/metadata/version
+Document Published Date (will need to convert data for presentation):
+ /*/metadata/published
+FedRAMP's Logo:
+ /*/metadata/party[@uuid=../responsible-party[@role-id='fedramp-pmo']/party-uuid]/link[@rel='logo']/@href
+Document Sensitivity Label (If more than one, tools should present all):
+ /*/metadata/prop[@name="marking"]
+
+{{}}
+
+**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.
+
+## 4.2. Prepared By (Third Party)
+
+
+
+The FedRAMP SAP and SAR must always indicate the assessing organization
+using this Prepared By syntax.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Prepared By
+ Description
+
+
+
+ Name of Consulting Org
+ Acronym/Short Name
+
+
+
+
+
+
+ f84d8edc-d83e-440d-96c9-09b28c395ad5
+
+
+
+
+
+
+
+ Peparer Logo
00000000
+
+
+{{}}
+
+
+{{}}
+**NIST Allowed Value** \
+Required Role ID:
+- prepared-by
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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.
+
+## 4.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
+{{< highlight xml "linenos=table" >}}
+
+
+ Prepared By
+ Description
+
+
+ Cloud Service Provider (CSP) Name
+ CSP Acronym/Short Name
+ [uuid-value-of-location]
+
+
+ c2e0db7cf-08f5-472e-9360-fb3a9698476dsp
+
+
+
+
+
+
+
+ CSP Logo
00000000
+
+
+{{}}
+
+
+{{}}
+**NIST Allowed Value** \
+Required Role ID:
+- prepared-by
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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.
+
+## 4.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
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Prepared For
+ The CSP for FedRAMP SSP, SAP, SAR, and POA&M.
+
+ Cloud Service Provider
+ CSP
+
+
+
+ Cloud Service Provider (CSP) Name
+ CSP Acronym/Short Name
+ [uuid-value-of-location]
+
+
+
+ 2e0db7cf-08f5-472e-9360-fb3a9698476d
+
+
+
+
+
+ CSP Logo
logo
+
+ 00000000
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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.
+{{}}
+
+## 4.5. Document Revision History
+
+
+
+{{}}
+The ```remarks``` field is Markup multiline, which enables the text to be formatted. This requires special handling. See Section 2.5.3 Markup-line and Markup-multiline Fields in OSCAL, or visit: https://pages.nist.gov/OSCAL/documentation/schema/datatypes/#markup-multiline
+
+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.
+
+{{ }}
+
+The OSCAL revision history requires one FedRAMP extension to fully meet
+FedRAMP\'s revision history requirements.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ 2022-06-01T00:00:00.000Z
+ 1.0
+ 1.0.4
+ Initial publication.
+
+ 2022-06-01T00:00:00.000Z
+ 2.0
+ 1.0.4
+ Updated for annual assessment.
+
+
+
+
+{{}}
+
+
+{{}}
+**FedRAMP Extension (Author)** \
+prop (ns="https://fedramp.gov/ns/oscal"):
+- name="party-uuid"
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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:
+ /*/metadata/revision-history/revision[1]/version
+Author for Individual Entry:
+ /*/metadata/party[@uuid=/*/metadata/revision-history/revision[1]/prop [@name='party-uuid'][@ns='https://fedramp.gov/ns/oscal']]/org/short-name
+
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+**NOTES:**
+
+- The Revision History\'s Author field is addressed using a FedRAMP
+ extension, which points to a metadata ```party```.
+
+- The published field requires the OSCAL data type,
+ [dateTime-with-timezone](https://pages.nist.gov/OSCAL/reference/datatypes/#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.
+
+## 4.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
+{{< highlight xml "linenos=table" >}}
+
+
+
+ FedRAMP Program Management Office
+
+
+
+
+
+ FedRAMP Program Management Office
+ FedRAMP PMO
+
+ oscal@fedramp.gov
+
+ 1800 F St. NW
+ Washington
+ DC
+ US
+
+
+
+
+ 77e0e2c8-2560-4fe9-ac78-c3ff4ffc9f6d
+
+
+
+{{}}
+
+
+{{}}
+**FedRAMP-Role Identifiers:**
+- fedramp-pmo
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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
+{{}}
+
+## 4.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
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ [SSP, SAP, or SAR] Approval
+ The executive(s)accountable for the accuracy of this content.
+
+
+ Cloud Service Provider
+ CSP
+
+
+ Cloud Service Provider (CSP) Name
+ CSP Acronym/Short Name
+
+
+ [SAMPLE]Person Name 1
+ Individual's Title
+ uuid-of-csp-party
+
+
+ [SAMPLE]Person Name 2
+ Individual's Title
+ uuid-of-csp
+
+
+ uuid-of-csp
+
+
+ uuid-of-person-1
+ uuid-of-person-2
+
+
+{{}}
+
+
+{{}}
+
+**Defined Identifiers** \
+Required Role IDs:
+- content-approver
+- cloud-service-provider
+
+**FedRAMP Extension (Person's Title)** \
+prop (ns="https://fedramp.gov/ns/oscal"):
+- name="title"
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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
+
+{{}}
+
+**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.
+
+## 4.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 .
+
+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
+{{< highlight xml "linenos=table" >}}
+
+
+
+ FedRAMP: Program Management Office
+ FedRAMP PMO
+
+
+
+
+
+
+
+
+ FedRAMP Applicable Laws and Regulations
+
+
+
+ FedRAMP Master Acronym and Glossary
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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
+{{}}
+
+## 4.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
+{{< highlight xml "linenos=table" >}}
+
+
+ [SAMPLE]Name or Title of Cited Law
+ Identification Number
+
+
+ [SAMPLE]Name or Title of Cited Regulation
+ Identification Number
+
+
+
+
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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.
+{{}}
+
+## 4.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*](#_Citations,_Attachments,_and). The following table represents
+attachments and embedded content.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ Name of Procedure Document
+ 00000000
+
+
+
+
+ The primary authorization boundary diagram.
+
+
+ 00000000
+ Set system-characteristics/authorization-boundary/diagram/link/@href = "#diag-boundary-1"
+
+{{}}
+
+
+{{}}
+Replace "policy" with "plan", "rob", etc. for each attachment type.
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+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"]
+
+{{}}
+
+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.
diff --git a/docs/content/guides/general/5-appendices.md b/docs/content/guides/general/5-appendices.md
new file mode 100644
index 000000000..51e1fcd99
--- /dev/null
+++ b/docs/content/guides/general/5-appendices.md
@@ -0,0 +1,517 @@
+---
+title: Appendices
+section: /general/
+toc:
+ enabled: true
+weight: 104
+---
+
+## 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.
+
+
+
+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.
+
+#### Security Sensitivity Level XPath Query
+{{< highlight xml "linenos=table" >}}
+ (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
+{{< highlight xml "linenos=table" >}}
+
+
+ |
+| **JSON Version:** |
+
+|**Moderate (Rev 5)**|
+| :-- |
+| **XML Version:** |
+| **JSON Version:** |
+
+|**Low (Rev 5)**|
+| :-- |
+| **XML Version:** |
+| **JSON Version:** |
+
+**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:\
+
+
+### *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:** |
+| **JSON Version:** |
+
+## Appendix B. Modifying a FedRAMP Baseline
+
+OSCAL is designed to allow modification of controls and baselines, while
+maintaining traceability through each layer of modification. This means
+you must create a new profile as a means of modifying an existing
+profile.
+
+If you require a change to a FedRAMP baseline, you should first
+coordinate that change with the FedRAMP JAB or PMO. Assuming FedRAMP
+agrees with the change, the correct way to 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.
+
+{{< callout >}}
+Create a new profile, importing to the appropriate FedRAMP profile, then use profile syntax to make necessary changes.
+
+**FedRAMP does not typically allow modifications to its baselines. This capability is present only in the event of a policy change or unforeseen circumstances.**
+{{}}
+
+
+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.
+
+For more information on working with profiles, please visit the NIST
+OSCAL site at:\
+
+
+A complete OSCAL profile syntax reference is available here:\
+[https://pages.nist.gov/OSCAL/concepts/layer/control/profile/](https://pages.nist.gov/OSCAL/concepts/layer/control/profile/)
+
+#### Sample Profile to Modify a FedRAMP Baseline
+{{< highlight xml "linenos=table" >}}
+
+
+ [XYZ Org] Modification to FedRAMP Moderate Baseline
+ 2023-03-06T08:05:30.000Z
+ fedramp2.0.0-oscal1.0.4
+ 1.0.4
+
+
+
+
+
+ at-4
+
+
+ yes
+
+
+
+
+ at least every six months
+
+
+
+
+
+
+ [XYZ Org]Modified Requirement
+
+ Requirement:
+ 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.
+
+
+
+
+
+
+{{}}
+
+## Appendix C. Profile Resolution
+
+Profiles are intended to identify upstream sources of control definition
+information and show only the changes to those upstream sources. This
+enables humans and computers to trace control definition changes back to
+their source framework.
+
+{{< callout >}}
+Profile resolution flattens or merges a profile and its imported catalog(s) and profiles into a single OSCAL file using 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.
+
+
+
+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:
+
+
+
+The actual tool can be found here:
+
+
+
+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:
+
+
+
+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 or by submitting an issue here:
+
+
+
+## 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.
+
+- **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:
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Prepared By
+
+ The organization that prepared this SSP.
+
+
+
+ Prepared For
+
+ The organization for which this SSP was prepared
+
+
+
+
+{{}}
+
+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.**
+
+### *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.
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ CSP HQ
+
+ 1234 Some Street
+ Haven
+ ME
+ 00000
+ us
+
+
+
+
+{{}}
+
+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\".
+
+### *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.
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Cloud Service Provider (CSP) Name
+ CSP Acronym
+
+
+
+
+ [SAMPLE]Person Name 1
+ name@org.domain
+ 202-555-0000
+
+
+{{}}
+
+**FedRAMP extensions are cited in relevant portions of each guide, and summarized in the FedRAMP OSCAL Registry.**
+
+### *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.
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+
+ CSP's IT Department
+
+
+
+ [SAMPLE]Person Name 1
+ uuid-of-csp
+ uuid-of-it-dept
+
+
+{{}}
+
+### *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.
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ CSP HQ
+
+ 1234 Some Street
+ Haven
+ ME
+ 00000
+
+
+
+
+ Cloud Service Provider (CSP) Name
+ uuid-of-hq-location
+
+
+
+ [SAMPLE]Person Name 1
+ uuid-of-hq-location
+
+
+{{}}
+
+### *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.
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ uuid-of-person-1
+
+
+{{}}
diff --git a/docs/content/guides/general/_index.md b/docs/content/guides/general/_index.md
new file mode 100644
index 000000000..6144fc52d
--- /dev/null
+++ b/docs/content/guides/general/_index.md
@@ -0,0 +1,127 @@
+---
+title: FedRAMP OSCAL-Based Content Guide
+heading: FedRAMP OSCAL-Based Content Guide
+menu:
+ primary:
+ name: Content
+ parent: Documentation
+ weight: 50
+toc:
+ enabled: true
+suppresstopiclist: true
+---
+
+## 1.4. 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.
+
+## 1.5. 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:
+
+- [https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/templates](https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/templates)
+
+## 1.6. 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/](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._
+{{ }}
+
+### 1.6.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](https://github.com/usnistgov/OSCAL/tree/main/xml/schema)\
+- JSON:
+[https://github.com/usnistgov/OSCAL/tree/main/json/schema](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%23draft-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.
+
+### 1.6.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](https://github.com/usnistgov/OSCAL/tree/main/json/convert)\
+- JSON to XML:
+[https://github.com/usnistgov/OSCAL/tree/main/xml/convert](https://github.com/usnistgov/OSCAL/tree/main/xml/convert)
+
+For more information on converting OSCAL files between supported
+formats, please see the information at the following links:
+
+- [OSCAL
+ Converters](https://pages.nist.gov/OSCAL/concepts/layer/overview/#oscal-converters)
+
+- [Converting OSCAL XML Content to
+ JSON](https://github.com/usnistgov/OSCAL/tree/master/json#converting-oscal-xml-content-to-json)
+
+- [Converting OSCAL JSON Content to
+ XML](https://github.com/usnistgov/OSCAL/tree/master/xml#converting-oscal-json-content-to-xml)
+
+## 1.7. 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._
+{{ }}
diff --git a/docs/content/guides/poam/3-working-with-oscal-files.md b/docs/content/guides/poam/3-working-with-oscal-files.md
new file mode 100644
index 000000000..2591e6855
--- /dev/null
+++ b/docs/content/guides/poam/3-working-with-oscal-files.md
@@ -0,0 +1,234 @@
+---
+title: Working with OSCAL Files
+section: /poam/
+toc:
+ enabled: true
+weight: 101
+---
+
+This section provides a summary of several important concepts and
+details that apply to OSCAL-based FedRAMP POA&M files.
+
+The [*Guide to OSCAL-based FedRAMP Content*](/guides/general/) provides important concepts necessary for working with any OSCAL-based
+FedRAMP file. Familiarization with those concepts is important to understanding this guide.
+
+## 3.1. XML and JSON Formats
+
+The examples provided here are in XML; however, FedRAMP accepts XML or JSON formatted OSCAL-based POA&M files. NIST offers a utility that
+provides lossless conversion of OSCAL-compliant files between XML and JSON in either direction.
+
+You may submit your POA&M to FedRAMP using either format. If necessary, FedRAMP tools will convert the files for processing.
+
+## 3.2. POA&M File Concepts
+
+Unlike the traditional MS Word-and Excel based SSP and POA&M, 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.
+
+
+
+_Each OSCAL file imports information from the one to the left_
+
+For example, the systems impacted by a vulnerability as listed in the POA&M are defined in the FedRAMP SSP and simply referenced by the POA&M.
+
+
+
+_Baseline and SSP Information is referenced instead of duplicated._
+
+For this reason, an OSCAL-based POA&M points to the OSCAL-based SSP of the system being assessed. Instead of duplicating system details, the OSCAL-based POA&M simply points to the SSP content for information such as system description, boundary, users, locations, and inventory items.
+
+The POA&M also inherits the SSP\'s pointer to the appropriate OSCAL-based FedRAMP Baseline. Through that linkage, the POA&M references the control baseline definitions for the system\'s baseline.
+
+### 3.2.1. Resolved Profile Catalogs
+
+The resolved profile catalog for each FedRAMP baseline is produced by applying the FedRAMP profiles as a set of tailoring instructions on top of the NIST control catalog. 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.
+
+
+
+_The Resolved Profile Catalog for each FedRAMP Baseline reduces tool processing._
+
+For more information about resolved profile catalogs, see the [*Guide to OSCAL-based FedRAMP Content*](guides/general/5-appendices/#appendix-c-profile-resolution) *Appendix C, Profile Resolution*.
+
+## 3.3. OSCAL-based FedRAMP POA&M Template
+
+FedRAMP offers an OSCAL-based POA&M shell file in both XML and JSON formats. This shell contains many of the FedRAMP required standards to help get you started. This document is intended to work in concert with that file. The OSCAL-based FedRAMP POA&M Template is available in XML and JSON formats here:
+
+- OSCAL-based FedRAMP POA&M Template (JSON Format):\
+
+
+- OSCAL-based FedRAMP POA&M Template (XML Format):\
+
+
+## 3.4. OSCAL's Minimum File Requirements
+
+Every OSCAL-based FedRAMP POA&M file must have a minimum set of required fields/assemblies, and must follow the OSCAL POA&M Model syntax found
+here:
+
+[https://pages.nist.gov/OSCAL/concepts/layer/assessment/poam/](https://pages.nist.gov/OSCAL/concepts/layer/assessment/poam/)
+
+
+
+## 3.5. Importing the System Security Plan
+
+OSCAL is designed for traceability. Because of this, the POA&M is designed to be linked to the SSP. Rather than duplicating content from the SSP, the POA&M is intended to reference the SSP content itself.
+
+{{}}
+***Unavailable OSCAL-based SSP Content OR Monthly Deliverable Option***
+
+OSCAL syntax requires the POA&M to import an OSCAL-based SSP, even if no OSCAL-based SSP exists.
+
+FedRAMP recognizes some system owners may adopt OSCAL for the POA&M before adopting it for their SSP. Similarly, FedRAMP does not currently require monthly delivery of the SSP with the monthly Continuous Monitoring POA&M delivery.
+{{ }}
+
+Use the import-ssp field to specify an existing OSCAL-based SSP. The href flag may include any valid uniform resource identifier (URI), including a relative path, absolute path, or URI fragment.
+
+#### SSP Import Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ [System Name] [FIPS-199 Level] SSP
+
+
+{{}}
+
+{{}}
+***Do Not Embed the SSP in the POA&M***
+
+While OSCAL provides the ability to embed the SSP in the POA&M, this approach does not align with FedRAMP's current delivery process and is discouraged.
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/xml']/@href
+
+
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/json']/@href
+
+{{}}
+
+Where the provided path is invalid, tool developers should ensure the tool prompts the user for the updated path to the OSCAL-based SSP.
+
+### 3.5.1. When OSCAL-based SSP Information is Inaccurate
+
+Ideally, when SSP information is missing or inaccurate the system ISSO should correct the SSP.
+
+If the POA&M must be updated with missing or inaccurate SSP information, the POA&M syntax allows for SSP information correction.
+
+Tool designers should ensure their tools can cite the relevant OSCAL-based SSP information when possible, and capture assessor-corrected SSP information in the POA&M\'s local-definitions or metadata sections when necessary. The relevant sections of this guide describe how to represent inaccurate SSP information in the POA&M when needed.
+
+{{}}
+***Monthly Continuous Monitoring (ConMon) Delivery***
+
+For monthly ConMon deliveries, the CSP may duplicate the component and inventory-item content from their SSP into the POA&M's local-definitions section. Delivering an OSCAL POA&M with all inventory in this way satisfies both the POA&M and System Inventory deliverables.
+{{ }}
+
+### 3.5.2. Delivering the POA&M and Inventory Without the SSP
+
+FedRAMP currently requires CSPs to deliver their POA&M, system inventory, and raw scanner tool output each month. OSCAL enables the delivery of POA&M and inventory without delivering the linked SSP.
+
+In this instance, the OSCAL allows the import-ssp syntax to be omitted; however, FedRAMP still requires the system-id content containing the system\'s FedRAMP-assigned unique identifier.
+
+All SSP inventory-item assemblies must be duplicated into the POA&M local-definitions assembly. Any SSP component cited by an inventory-item must also be duplicated to the POA&M\'s local-definitions assembly.
+
+Finally, any SSP component referenced by POA&M data must be duplicated, whether it is referenced by an inventory-item or not.
+
+#### POA&M Representation
+{{< highlight xml "linenos=table" >}}
+F00000000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+## 3.6. Resolution Resource Prop
+
+FedRAMP will be implementing a separate set of automated POA&M validation rules for the rev 5 OSCAL templates. To ensure FedRAMP initiates the appropriate validation rules when processing OSCAL POA&Ms, POA&M authors should add a new prop called "resolution-resource" in the metadata section and include an associated back-matter resource as shown below:
+
+#### SSP Resolution Resource
+{{< highlight xml "linenos=table, hl_lines=11-12" >}}
+
+
+ FedRAMP Security Assessment Plan (SAP)
+
+ fedramp2.0.0-oscal1.0.4
+ 1.0.4
+
+
+
+
+
+
+
+
+
+ Resolution Resource
+
+ This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAP (rev 4 or rev 5) this OSCAL document is for.
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) UUID of “resolution-resource”:
+ /*/metadata/prop[@name=”resolution-resource”]/@value
+
+(SAR)Target baseline version:
+ /*/back-matter/resource[@uuid=”uuid-of-resolution-resource”]/prop[@name=”dataset” and @class=”version”]/@value
+{{}}
+
+If the "resolution-resource" prop is not specified in the metadata section of the POA&M, FedRAMP will assume the POA&M should be validated using the rev 5 validation rules. If the "resolution-resource" prop is present, FedRAMP will use the validation rules that correspond with the version specified in the back-matter resource.
diff --git a/docs/content/guides/poam/4-poam-template-to-oscal-mapping.md b/docs/content/guides/poam/4-poam-template-to-oscal-mapping.md
new file mode 100644
index 000000000..7228c014e
--- /dev/null
+++ b/docs/content/guides/poam/4-poam-template-to-oscal-mapping.md
@@ -0,0 +1,1137 @@
+---
+title: POA&M Template to OSCAL Mapping
+section: /poam/
+toc:
+ enabled: true
+weight: 102
+---
+
+The OSCAL POA&M Model is used to represent the FedRAMP POA&M. This model
+includes:
+
+- Metadata and back-matter syntax, which is common to all OSCAL models
+
+- Local definitions
+
+- Observations
+
+- Risks; and
+
+- POA&M Items syntax. Individual POA&M item syntax is the same as the
+ Findings syntax in the SAR.
+
+{{}}
+This guide assumes tool developers are already familiar with the [Guide to OSCAL-based FedRAMP Content](/guides/general/).
+Instead of duplicating content from that guide, this document refers to them and only adds details that are unique to the POA&M.
+{{ }}
+
+## 4.1. Representing the POA&M
+
+This is based on the Excel-based [FedRAMP POA&M Template.](https://www.fedramp.gov/assets/resources/templates/FedRAMP-POAM-Template.xlsm)
+
+Content that is common across OSCAL file types is described in the
+*[Guide to OSCAL-based FedRAMP Content](/guides/general/).*
+This includes the following:
+
+| Topic | Location |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Title Page** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#title-page)_, Section 4.1_ |
+| **Prepared By/For** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#prepared-by-third-party)_, Section 4.2 - 4.4_ |
+| **Record of Template Changes** | Not Applicable. Instead follow [_Guide to OSCAL-based FedRAMP Content_](/guides/general/2-working-with-oscal-files/#oscal-syntax-version)_, Section 2.3.2, OSCAL Syntax Version_ |
+| **Revision History** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-revision-history)_, Section 4.5_ |
+| **How to Contact Us** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#how-to-contact-us)_, Section 4.6_ |
+| **Document Approvers** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-approvals)_, Section 4.7_ |
+| **Acronyms and Glossary** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#fedramp-standard-attachments-acronyms-lawsregulations)_, Section 4.8_ |
+| **Laws, Regulations, Standards and Guidance** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#additional-laws-regulations-standards-or-guidance)_, Section 4.9_ |
+| **Attachments and Citations** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#attachments-and-embedded-content)_, Section 4.10_
+
+**The following pages are intended to be printed landscape on tabloid (11" x 17") paper.**
+
+## 4.2. Individual POA&M Entries
+
+For those familiar with using the Excel-based FedRAMP POA&M template,
+each row in the spreadsheet is represented by a single poam-item
+assembly in OSCAL.
+
+OSCAL requires the poam-items assembly to include title, description,
+start and end fields. The value of the title and description fields may
+be anything the CSP feels is appropriate. FedRAMP suggests duplicating
+the title value used in the metadata section.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+ [System Name] FedRAMP Plan of Action and Milestones (POA&M)
+ 2023-06-30T00:00:00Z
+ 0.0.0
+ 1.0.4
+
+
+
+
+
+
+
+
+
+
+
+
+
+ [EXAMPLE]POA&M Item
+
+ The FedRAMP Extension, "POAM-ID" captures the traditional CSP-assigned unique POA&M identifier.
+
+
+
+
+
+
+
+{{}}
+
+### 4.2.1. Individual POA&M Entries: Findings
+
+As with the Excel-based POA&M template, there is typically a single
+poam-item for each unique vulnerability; however, in OSCAL, some of the
+details are included in observation or risk assemblies and linked to the
+poam-item assembly.
+
+The observation assembly identifies who, what, where, when and how. It
+identifies who performed what activity, how the activity was performed,
+what tools were used, and what evidence was collected. If appropriate,
+the location can be included as well. **More importantly, observation
+identifies the system components impacted by the risk.**
+
+The risk assembly includes risk details, such as the risk statement,
+likelihood, impact, mitigating factors, deviations, remediation plan,
+and resolution tracking. OSCAL allows more than one associated-risk to
+be assigned to be assigned to a poam-item; however, FedRAMP strongly
+recommends only one associated-risk per poam-item.
+
+The CSP-assigned unique POA&M ID must be present in the poam-item
+assembly using the FedRAMP extension, \"POAM-ID\".
+
+The related control must be present in the risk assembly using the
+\"impacted-control-id\" FedRAMP extension.
+
+The collected field must be set to the Original Detection Date, which
+may be the tool\'s timestamp.
+
+Within the poam-item assembly, there must be at least one observation
+assembly, and exactly one risk assembly.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=18" >}}
+
+
+
+
+
+
+
+
+
+
+
+
+ [EXAMPLE]POA&M Item
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+### 4.2.2. Individual POA&M Entries: Observations
+
+Within the observation assembly, the method field must be set to
+\"TEST\" for scanning results. Set this value to \"TEST\", \"EXAMINE\"
+or \"INTERVIEW\" as appropriate for risks identified by other means.
+
+The type field must be set to \"finding\".
+
+The uuid flag of the origin field must identify the Weakness Detector
+Source of the information. For monthly scanning, this must identify the
+automated tool\'s UUID, and the type flag must be set to \"tool\". The
+tool must be defined as a component in the local-definitions assembly,
+using the same syntax and approach described in the [*Guide to
+OSCAL-based Security Assessment Plans
+(SAP)*](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/Guide_to_OSCAL-based_FedRAMP_Security_Assessment_Plans_(SAP)_rev5.pdf),
+*Section 4.14, SAP Test Plan: Testing Performed Using Automated Tools*.
+
+The href flag in the relevant-evidence field must point to the resource
+containing the raw tool output attached in the back-matter using a URI
+fragment. Relevant evidence information is encouraged, but not required
+for POA&M entries.
+
+At the end of the finding assembly, the UUID for the operator of the
+scanning tool may be listed as the party-uuid for the finding. There may
+be more than one. Each party-uuid must reference a party assembly in
+either the POA&M\'s metadata section, or the metadata section of the
+imported SSP. Tool operator information is optional, but a POA&M tool
+should display the party information if one or more party-uuid fields
+are present.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=2-9 15-18" >}}
+
+
+ XYZ Vulnerability Scanning Tool
+
+
+
+ TEST
+ finding
+
+
+
+ Optional pointer to the raw scanner output that generated
+ this POA&M entry.
+ 2023-10-10T00:00:00Z
+
+
+
+
+
+
+{{}}
+
+### 4.2.3. Individual POA&M Entries: Asset Identifiers
+
+For scanner tool findings, impacted assets are identified using the
+subject field. One field for each impacted asset. The type flag should
+be set to either \"inventory-item\" or \"component\". The uuid-ref flag
+must point to an inventory item or component defined in the SSP
+inventory or POA&M local-definitions.
+
+All details about the asset become available as a result of that UUID
+reference, such as IP address, fully qualified domain name (FQDN), and
+the asset\'s point of contact. If an inventory-item contains an
+implemented-component field, those linked component details are also
+considered to be part of the inventory-item itself.
+
+When providing a monthly POA&M to FedRAMP using OSCAL, the inventory may
+be delivered either by:
+
+- delivering the entire OSCAL-based SSP file, including the latest
+ system inventory; or
+
+- duplicating all component and inventory-item assemblies from the
+ system-implementation assembly of the SSP to the local-definitions
+ assembly of the POA&M. Any role or party citations in this content
+ must also be duplicated from the SSP metadata assembly to the POA&M
+ metadata assembly.
+
+
+
+{{}}
+***System Inventory***
+
+When providing a monthly POA&M to FedRAMP using OSCAL, the OSCAL-based inventory may be delivered either:
+- by delivering the entire OSCAL-based SSP file, including the latest system inventory; or
+- by duplicating all component and inventory-item assemblies from the system-implementation assembly of the SSP to the local-definitions assembly of the POA&M.
+
+See [Section 3.5.2](/guides/poam/3-working-with-oscal-files/#35-importing-the-system-security-plan) for more information.
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=2-19 24-27" >}}
+
+
+ Component Definition
+
+ A virtual component.
+
+
+
+ An instance of the above component.
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+### 4.2.4. Individual POA&M Entries: Weakness Information
+
+Weakness details are identified in the risk assembly. The Weakness Name
+appears in the title field, and the Weakness Description appears in the
+description field. The status field is initially set to \"open\".
+
+The Weakness Source Identifier requires a FedRAMP extension. Within the
+characterization\'s origin, an actor must be specified for the tool
+itself. Assign the \"vulnerability-id\" and \"plugin-id\" FedRAMP
+extensions as properties to this actor.
+
+And information provided by the tool that characterizes the risk are
+captured as facet fields. When the scanner tool provides risk values
+from other recognized systems, such as a CVE number, IAVAM severity, or
+CVSS metric, the NIST-defined name and system values must be used, in
+addition to the tool value being assigned to the value attribute. For
+example, if the scanner tool provides a CVE number, the risk-metric
+field\'s system flag should reflect \"http://cve.mitre.org\" as the
+system, not the scanner tool.
+
+FedRAMP required facet fields, such as likelihood and impact, have a
+system flag with a value of \"https://fedramp.gov\". FedRAMP required
+facets must also have a prop with the name flag set to \"state\" and the
+value flag set to either \"initial\" or \"adjusted\". There must always
+be \"initial\" facets. If adjusted, there may be a \"adjusted\" facets
+as well.
+
+
+
+{{}}
+***Risk Metric Fields***
+
+The facet fields are designed to allow risk values and identifiers from different frameworks, systems, and tools to co-exist in the same risk assembly. For example, a scanning tool may provide risk values assigned by the tool itself, as well as a CVE identifier, IAVM severity score, and CVSS metrics. If the system is subject to multiple frameworks using different risk score values or risk calculation methods, they may each be expressed in their own characterization assembly.
+
+Common values for the system flag include:
+- FedRAMP: https://fedramp.gov
+- USCERT IAVM: https://us-cert.cisa.gov
+- CVE: http://cve.mitre.org
+- CVSS: (v2): http://www.first.org/cvss/v2,
+ (v3): http://www.first.org/cvss/v3,
+ (v3.1): http://www.first.org/cvss/v3.1
+
+If a tool provides a value with no clear source of information for defining the value, use the special "unknown" system value:
+ http://csrc.nist.gov/ns/oscal/unknown
+
+Ideally scanner tool vendors will define a "system" value for their own tools. Until that happens, FedRAMP recommends either using the URL for the vendor's web site or the NIST-defined system value for an "unknown system:
+ http://csrc.nist.gov/ns/oscal/unknown
+
+Until this matures and clear system values are widely available across the industry, FedRAMP only requires the same system value be used consistently throughout the POA&M for a given tool and keep the facet values from a given tool within the same characterization assembly which cites the tool as an actor.
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=2-7 17-20" >}}
+
+ Weakness Name
+ This is the Weakness Description.
+ This is the tool-provided statement about the identified risk.
+ If no risk statement from tool, set to 'No Risk Statement'.
+
+
+ open
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+### 4.2.5. Binding Operational Directive 22-01 Vulnerabilities
+
+FedRAMP, in accordance with Binding Operational Directive (BOD) 22-01
+and in consultation with the JAB and DHS CISA, emphasized that CSPs who
+maintain federal information fall within the scope defined by the BOD.
+CSPs must track their system's vulnerabilities against the CISA catalog
+of known exploited vulnerabilities (KEV). CSPs must identify in their
+POA&M any system vulnerabilities that are in the KEV catalog.
+
+A FedRAMP extension property with the name flag set to \"kev-catalog\"
+is used to indicate that a vulnerability is in the CISA KEV catalog. The
+\"kev-catalog\" property's value flag may be set to \"yes\" or \"no\",
+however the property need only be present when its value is \"yes\".
+
+CSP vulnerabilities that are in the CISA KEV catalog must be remediated
+by the due date specified in the catalog. This date must be included in
+the CSP's POA&M via a FedRAMP extension property with the name flag set
+to \"kev-due-date\". This property's value must be set to a [valid date
+data type](https://pages.nist.gov/OSCAL/reference/datatypes/#date).
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+ Weakness Name
+ This is the Weakness Description.
+ This is the tool-provided statement about the identified risk.
+ If no risk statement from tool, set to 'No Risk Statement'.
+
+ open
+
+
+
+
+{{}}
+
+## 4.3. Recommended and Planned Remediation
+
+Within the risk assembly, there must be a response assembly containing
+the tool\'s recommended mitigation. The type flag must be set to
+\"recommendation\". The origin field\'s actor type flag must be set to
+\"tool\", and the uuid-ref must contain the UUID of the tool that
+generated the recommendation. Additional remediation recommendations may
+also be present, such as the assessor\'s recommendation copied from the
+SAR.
+
+There must also be a response assembly containing the CSP\'s intended
+mitigation plan. The type flag must be set to \"planned\". The origin
+field\'s actor type flag must be set to \"party\", and the uuid-ref must
+contain the UUID of either the CSP organization itself or the individual
+overseeing the activities, such as the ISSO.
+
+\"Resources Required\" are identified within the \"planned\" response
+assembly using the required assembly. Use the description field for a
+free-form explanation of required resources. Use one or more subject
+fields to link to a specific party, component, inventory-item, system
+user, or resource.
+
+
+
+{{}}
+***Accepted Values***
+- The type flag on the remediation field:
+ - recommendation
+ - planned
+- The type flag on the recommendation-origin field:
+ - party
+ - tool
+- The type flag on the subject field:
+ - party
+ - component
+ - inventory-item
+ - location
+ - user
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=19-33" >}}
+
+
+
+ Tool's Recommendation
+ Tool-provided recommendation.
+
+
+
+
+ Assessor's Recommendation
+ Assessor-provided recommendation.
+
+
+
+
+ CSP's Remediation Plan
+
+ Describe the CSP's intended approach to remediating this risk.
+
+
+
+
+
+ Describe required resources.
+
+
+
+{{}}
+
+### 4.3.1. Planned Remediation Schedule
+
+The Planned Milestones are identified within the response assembly using
+the task assemblies. There must be at least one task assembly of type
+\"milestone\". There may be additional tasks assemblies of type
+\"action\" or \"milestone\". This collection of \"action\" and
+\"milestone" tasks serve as a high-level remediation timeline. A POA&M
+tool should offer the option of viewing either just the milestones or
+all actions and milestones.
+
+Each task assembly must have a title field that briefly names the
+milestone and a description field. OSCAL requires both the title and
+description fields to be present; however, FedRAMP allows description to
+be empty. All \"milestone\" task assemblies must contain a timing
+assembly with an on-date field, whereas the timing assembly for
+\"action\" tasks must contain either an on-date or within-date-range
+field. FedRAMP presumes the Scheduled Completion Date for the POA&M item
+is the farthest specified timing assembly date in the future because it
+indicates when all remediation schedule milestones and actions will be
+complete.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=17-30" >}}
+
+
+
+ CSP's Remediation Plan
+
+ Describe the CSP's intended approach to remediating this risk.
+
+
+
+
+
+ Describe required resources.
+
+ [Example]Milestone 1
+ Optional description
+
+
+
+ [Example]Milestone 2
+ Optional description
+
+
+
+
+
+
+{{}}
+
+OSCAL supports relationships between
+tasks, via sub-tasks and task dependencies. FedRAMP does not require the
+use of sub-tasks or dependencies, however if present, such tasks are
+subject to the same constraints mentioned above.
+
+## 4.4. Risk Tracking
+
+Tracking is initiated by adding the risk-log assembly to the risk
+assembly, which must have one or more entry assemblies. Each milestone
+change, vendor check-in, periodic status update, and action performed in
+the pursuit of remediating the risk are entered here as individual entry
+assemblies.
+
+Each entry assembly must have a title, description, and start field.
+There may also be an end, logged-by, and related-response fields. If the
+end field is missing it is presumed to have the same value as the start
+field. The logged-by field is optional and contains the UUID of the
+person (party) who made the entry. The related-response field is
+optional and contains the UUID of the risk response that describes the
+recommended or actual plan for addressing the risk.
+
+For performed actions, start should reflect when the action was
+performed. For status updates, this should reflect the effective date of
+the status information.
+
+If it is appropriate to attach evidence related to risk tracking, add an
+observation assembly with the appropriate evidence attached. If used,
+the observation assembly must have a type tag of \"risk-tracking\".
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=3-35" >}}
+
+
+
+
+ Activity 1
+ 2023-07-02T00:00:00Z
+ 2023-08-02T00:00:00Z
+
+
+ Activity 2
+ 2023-07-07T00:00:00Z
+
+
+ Vendor Check-in
+ Description of the result of the vendor check-in.
+ 2023-07-07T00:00:00Z
+
+
+ Risk Closed
+
+ Describe what action(s) the CSP took to close the risk.
+ [EXAMPLE]Applied patch. Vulnerability no longer found in subsequent
+ scan.
+
+ 2023-07-07T00:00:00Z
+ closed
+
+
+
+
+{{}}
+
+## 4.5. Deviations and Vendor Dependencies
+
+After risks are identified a deviation may be appropriate, or a vendor
+dependency may exist. As deviations are identified, the original risk
+information is [not]{.underline} modified. Additional content is added
+to identify these changes. Typically, an additional observation is added
+and linked to the poam-item, and additional facet fields are added to
+the risk assembly. There may be both Operational Requirement (OR) and
+Risk Assessment (RA) information in the same risk assembly, each with
+its own observation.
+
+{{}}
+**Deviations and Vendor Dependency Requirements**
+
+FedRAMP's requirements for deviation requests and vendor dependency handling are defined in the [Continuous Monitoring Strategy Guide](https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf), and remain the same when delivering content in OSCAL format.
+
+{{ }}
+
+### 4.5.1. False Positive (FP)
+
+To initially identify a false positive, add a \"false-positive\" FedRAMP
+Extension property to the risk field and set its value to
+\"investigating\". Once evidence is identified to support the FP, change
+the risk assembly\'s \"false-positive\" value to \"pending\" and add an
+observation with the type field set to \"false-positive\". Typically,
+the method is set to \"EXAMINE\". Add an additional related-observation
+field linking the poam-item to the new observation.
+
+Once the FP is approved, change the \"false-positive\" extension\'s
+value to \"approved\" and close the risk as described in [*Section 4.6,
+Risk Closure*](/guides/poam/4-poam-template-to-oscal-mapping/#46-risk-closure).
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=3 5 6-8 22" >}}
+
+ False Positive
+ Describe the false positive here.
EXAMINE
+ false-positive
+
+ A screen shot showing the setting is correct
+
+ Vendor detail describing why this happens.
+ 2023-10-10T00:00:00Z
+
+
+
+ Vulnerability Title
+ Vulnerability description
Risk statement.
open
+
+
+
+
+
+
+{{}}
+
+Add an entry to the risk log when investigating, as well as for submission and approval events respectively.
+
+### 4.5.2. Operationally Required (OR)
+
+To initially identify an OR, add an \"operational-requirement\" FedRAMP
+Extension property to the risk field and set its value to
+\"investigating\". Once evidence is identified to support the OR, change
+the risk assembly\'s \"operational-requirement\" value to \"pending\"
+and add an observation with the type field set to
+\"operational-requirement\". Typically, the method is set to EXAMINE;
+however, another method may be identified if more appropriate. Add an
+additional related-observation field linking the poam-item to the new
+observation.
+
+Once the OR is approved, change the \"operational-requirement\"
+extension value to \"approved\".
+
+If a risk adjustment is also required for OR approval (such as FedRAMP
+requires for High ORs), simply also follow the instructions in the next
+section for risk adjustments. When there is both an OR and an RA, each
+will have their own observation assembly and respective
+related-observation entries in the poam-item assembly.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=3 5-9 21" >}}
+
+ Operational Requirement
+ Provide the justification for the OR.
EXAMINE
+ operational-requirement
+
+ A screen shot showing impact when patch is applied.
+
+
+ Vendor detail describing why this happens.
+ 2023-10-10T00:00:00Z
+
+
+
+ Vulnerability Title
+ Vulnerability description
Risk statement.
open
+
+
+
+
+
+
+{{}}
+
+Add an entry to the risk log when investigating, as well as for
+submission and approval events respectively.
+
+### 4.5.3. Risk Adjustment (RA)
+
+To initially identify an RA, add a \"risk-adjustment\" FedRAMP Extension
+property to the risk field and set its value to \"investigating\". Once
+evidence is identified or mitigating factors are implemented, change the
+risk assembly\'s \"risk-adjustment\" value to \"pending\" and add an
+observation with the type field set to \"risk-adjustment\". Typically,
+the method is set to EXAMINE; however, another method may be identified
+if more appropriate. Add an additional related-observation field linking
+the poam-item to the new observation.
+
+As mitigating factors are identified or implemented, add
+mitigating-factor assemblies to the risk assembly. There must be at
+least one mitigating factor for an RA. Based on those factors, add
+additional facet assemblies with adjusted risk values.
+
+Once the RA is approved, change the \"risk-adjustment\" extension value
+to \"approved\".
+
+If the RA is performed in concert with an OR (such as FedRAMP requires
+for High ORs), simply also follow the instructions in the previous
+section for operationally required risks. When there is both an OR and
+an RA, each will have their own observation assembly and respective
+related-observation entries in the poam-item assembly.
+
+
+
+{{}}
+***Calculated Risk***
+
+Both initial and residual risk values are calculated based on likelihood and impact values.
+
+Every POA&M entry must have initial likelihood and impact values:
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+{{}}
+
+When justifying a risk adjustment, either the likelihood or impact may be lowered. It is possible to justify lowering both. Even if just one value is lowered, both residual risk values must be present:
+
+{{< highlight xml "linenos=table" >}}
+
+
+{{}}
+
+{{ }}
+
+{{}}
+Add an entry to the risk log when investigating, for the completion of each mitigating factor's implementation (if appropriate), as well as for submission and approval events respectively.
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=2-9 13 21-34 36-38" >}}
+
+ risk-adjustment
+
+
+ Describe the risk adjustment evidence here.
+
+
+
+ 2023-10-10T00:00:00Z
+
+
+
+
+
+
+
+
+
+
+ Explain why likelihood was adjusted.
+
+
+
+
+
+
+ Explain why impact was adjusted.
+
+
+
+
+
+ Describe mitigating factor
+
+
+
+
+{{}}
+
+### 4.5.4. Vendor Dependency
+
+To initially identify a vendor dependency, add a \"vendor-dependency\"
+FedRAMP Extension property to the risk field and set its value to
+\"investigating\". Once evidence is identified to support the
+dependency, change the risk assembly\'s \"vendor-dependency\" value to
+\"tracking\" and add an observation with the type field set to
+\"vendor-dependency\". Typically, the method is set to EXAMINE; however,
+another method may be identified if more appropriate. Add an additional
+related-observation field linking the poam-item to the new observation.
+
+Within the observation assembly, explain the dependency in the
+description field. The observation assembly must include a
+subject-reference identifying the component or inventory-item. The
+Vendor Dependency Product Name is provided from the component or
+inventory-item details.
+
+Add a separate relevant-evidence assembly for each piece of evidence
+supporting the dependency. Attached evidence, such as screen shots, must
+be defined as a resource in the back-matter, and cited using a URI
+fragment (hashtag, followed by the UUID of the resource.)
+
+Once the vendor publishes a resolution, change the \"vendor-dependency\"
+extension value to \"resolved\".
+
+
+
+{{}}
+If the Vendor Dependent Product Name is not already defined as an individual component, add a component to the local-definitions assembly describing the component.
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=5 6 10-13 21" >}}
+
+ Vendor Dependency
+ Describe the vendor dependency here.
INTERVIEW
+ vendor-dependency
+
+ A screen shot showing the setting is correct
+
+ Vendor detail describing why this happens.
+ 2023-10-10T00:00:00Z
+
+
+
+ Vulnerability Title
+ Vulnerability description
Risk statement.
open
+
+
+
+
+
+
+{{}}
+
+Add an entry to the risk log when investigating, as well as for each
+vendor check-in. As the CSP performs the required regular vendor
+check-ins, each must be added to the risk-log assembly as an additional
+entry. The title should be set to \"Vendor Check-in\", the start field
+must indicate when the check-in occurred. The result of the check-in
+must be described in the description field.
+
+When the vendor publishes the resolution, add another risk log entry
+reflecting the date the resolution was published.
+
+### 4.5.5. Evidence and Artifacts
+
+All evidence collected must be attached (by relative URI path or
+embedded Base64) as a resource in the back-matter. See the [*Guide to OSCAL-based FedRAMP Content*](/guides/general/2-working-with-oscal-files/#27-citations-and-attachments-in-oscal-files),
+*Section 2.7, Citations and Attachments in OSCAL
+Files* for more information.
+
+Evidence must have the FedRAMP extension \"type\" with the value set to
+\"evidence\".
+
+Additional type fields may also be added with values such as plan,
+policy, or image. This adds clarity and can ensure specific tables are
+generated properly.
+
+Artifacts may be cited from an observation as an observation-source.
+
+Evidence may be cited from an observation as relative-evidence.
+
+A POA&M tool could use either an rlink or base64 field here, and may use
+both. If both are present, FedRAMP tools will give preference to the
+base64 content. If an rlink is used, its href should have a relative
+path to ensure the path remains valid when the OSCAL content is
+delivered to FedRAMP.
+
+Tools may include multiple rlink fields within the same resource
+assembly. This may be useful if the CSP wanted to maintain an absolute
+link to the file\'s authoritative source location as well as a relative
+link suitable for delivery to FedRAMP.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ [EXAMPLE]AC Policy
+ 2.1
+ 2018-11-11T00:00:00Z
+ 00000000
+
+
+
+ [EXAMPLE]Screen Shot
+ 00000000
+
+
+
+{{}}
+
+## 4.6. Risk Closure
+
+When a risk is closed through remediation or false-positive approval,
+they must be closed. The risk should remain in the POA&M with the
+following changes.
+
+First, in the risk assembly, change the status field to \"closed\". Then
+make a final entry in the risk-log assembly. In the entry assembly
+summarize the reason for closure in the description field, set the start
+field to indicate the date of closure, and the status-change field to
+\"closed\". Individual actions performed for closure should each have
+their own entries in the risk log.
+
+If it is appropriate to attach evidence of
+closure, add an observation assembly with the type field set to
+\"closure\", and cite the appropriate evidence.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=5 13 25-33" >}}
+
+ Risk Closure
+ Describe the closure evidence here.
EXAMINE
+ closure
+
+ A screen shot showing the setting is correct
+
+ Vendor detail describing why this happens.
+ 2023-10-10T00:00:00Z
+
+
+
+
+
+
+
+
+
+
+
+
+ Risk Closed
+
+ Describe what action(s) the CSP took to close the risk.
+ [EXAMPLE]Applied patch. Vulnerability no longer found in subsequent scan.
+
+ 2023-07-07T00:00:00Z
+ closed
+
+
+
+
+
+
+
+{{}}
+
+## Appendix A. CVSS Scoring
+
+Common Vulnerability Scoring System (CVSS) metrics may be added to any
+risk-assembly using risk-metric fields.
+
+Tools should accept either the upper-case abbreviation or the lower-case
+name on a field-by-field basis. For example, it should be acceptable to
+use \"AV\" for access vector, and \"privileges-required\" for privileges
+required, provided both have a system value of \"[http://www.first.org/cvss/v3.1](http://www.first.org/cvss/v3-1)\".
+
+All CVSS metrics must be in the same CVSS version, as identified by the
+system flag, for successful computation. Tool developers should ensure
+the tool performs CVSS calculations as defined by the Forum of Incident
+Response and Security Teams (FIRST) at [https://www.first.org/cvss/](https://www.first.org/cvss/).
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+
+
+{{}}
\ No newline at end of file
diff --git a/docs/content/guides/poam/_index.md b/docs/content/guides/poam/_index.md
new file mode 100644
index 000000000..44a6629fa
--- /dev/null
+++ b/docs/content/guides/poam/_index.md
@@ -0,0 +1,30 @@
+---
+title: FedRAMP OSCAL POA&M Guide
+heading: FedRAMP OSCAL POA&M Guide
+menu:
+ primary:
+ name: POA&M
+ parent: Documentation
+ weight: 500
+toc:
+ enabled: true
+---
+
+## 2. FedRAMP Extensions and Allowed Values
+
+NIST designed the core OSCAL syntax to model cybersecurity information
+that is common to most organization and compliance frameworks; however,
+NIST also recognized the need to provide flexibility or organizations
+with unique information needs.
+
+Instead of trying to provide a language that meets each organization\'s
+unique needs, NIST provided designed OSCAL with the ability to be
+extended.
+
+As a result, FedRAMP-compliant OSCAL files are a combination of the core
+OSCAL syntax and extensions defined by FedRAMP. The [*Guide to OSCAL-Based FedRAMP Content*](/guides/general/)
+describes the concepts behind FedRAMP extensions and allowed values. The
+extensions related to the Plan of Action and Milestones (POA&M) are
+cited in this document in context of their use.
+
+**FedRAMP extensions and allowed values are cited in relevant portions of this document and summarized in the FedRAMP OSCAL Registry.**
\ No newline at end of file
diff --git a/docs/content/guides/sap/3-working-with-oscal-files.md b/docs/content/guides/sap/3-working-with-oscal-files.md
new file mode 100644
index 000000000..f76392f90
--- /dev/null
+++ b/docs/content/guides/sap/3-working-with-oscal-files.md
@@ -0,0 +1,319 @@
+---
+title: Working with OSCAL Files
+section: /sap/
+toc:
+ enabled: true
+weight: 101
+---
+
+This section provides a summary of several important concepts and
+details that apply to OSCAL-based FedRAMP SAP files.
+
+The [*Guide to OSCAL-based FedRAMP Content*](/guides/general/)
+provides important concepts necessary for working with any OSCAL-based
+FedRAMP file. Familiarization with those concepts is important to
+understanding this guide.
+
+## 3.1. XML and JSON Formats
+
+The examples provided here are in XML; however, FedRAMP accepts XML or
+JSON formatted OSCAL-based SAP files. NIST offers a utility that
+provides lossless conversion of OSCAL-compliant files between XML and
+JSON in either direction.
+
+You may submit your SAP to FedRAMP using either format. If necessary,
+FedRAMP tools will convert the files for processing.
+
+## 3.2. SAP File 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.
+
+
+
+*Each OSCAL file imports information from the one to the left*
+
+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.
+
+
+
+*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.
+
+### 3.2.1. Resolved Profile Catalogs
+
+The resolved profile catalog for each FedRAMP baseline is produced by
+applying the FedRAMP profiles as a set of tailoring instructions on top
+of the NIST control catalog. 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.
+
+
+
+*The Resolved Profile Catalog for each FedRAMP Baseline reduces tool
+processing.*
+
+For more information about resolved profile catalogs, see the [*Guide to OSCAL-based FedRAMP Content*](/guides/general/5-appendices/#profile-resolution) *Appendix C, Profile Resolution*.
+
+## 3.3. OSCAL-based FedRAMP SAP Template
+
+FedRAMP offers an OSCAL-based SAP shell file in both XML and JSON
+formats. This shell contains many of the FedRAMP required standards to
+help get you started. This document is intended to work in concert with
+that file. The OSCAL-based FedRAMP SAP Template is available in XML and
+JSON formats here:
+
+- OSCAL-based FedRAMP SAP Template (JSON Format):\
+ [https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sap/json/FedRAMP-SAP-OSCAL-Template.json](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sap/json/FedRAMP-SAP-OSCAL-Template.json)
+
+- OSCAL-based FedRAMP SAP Template (XML Format):\
+ [https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sap/xml/FedRAMP-SAP-OSCAL-Template.xml](https://github.com/GSA/fedramp-automation/raw/master/dist/content/templates/sap/xml/FedRAMP-SAP-OSCAL-Template.xml)
+
+## 3.4. OSCAL's SAP Minimum File Requirements
+
+Every OSCAL-based FedRAMP SAP file must have a minimum set of required
+fields/assemblies and must follow the OSCAL Assessment Plan model syntax
+found here:
+
+[https://pages.nist.gov/OSCAL/documentation/schema/assessment-layer/assessment-plan/](https://pages.nist.gov/OSCAL/concepts/layer/assessment/assessment-plan/)
+
+
+## 3.5. Importing the System Security Plan
+
+OSCAL is designed for traceability. Because of this, the assessment plan
+is designed to be linked to the system security plan. Rather than
+duplicating content from the SSP, the SAP is intended to reference the
+SSP content itself. **If a system security plan is available in OSCAL
+format, it must be used with the OSCAL-based security assessment plan.**
+
+Use the import-ssp field to specify an existing OSCAL-based SSP. The
+href flag may include any valid uniform resource identifier (URI),
+including a relative path, absolute path, or URI fragment.
+
+#### SAP Import Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ [System Name] [FIPS-199 Level] SSP
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) Referenced OSCAL-based SSP
+ XML:
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/xml']/@href
+ OR JSON:
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/json']/@href
+
+{{}}
+
+FedRAMP SSPs are delivered by the Cloud Service Provider (CSP), while
+FedRAMP SAPs are delivered by the assessor. For this reason, FedRAMP
+strongly encourages the use of relative paths from the OSCAL-based
+FedRAMP SAP to the OSCAL-based FedRAMP SSP.
+
+Where the provided path is invalid, tool developers should ensure the
+tool prompts the user for the updated path to the OSCAL-based SSP.
+
+### 3.5.1. When OSCAL-based SSP Information is Inaccurate
+
+When an assessor encounters inaccurate information in an OSCAL-based
+SSP, they should encourage the CSP to fix it and use the corrected
+version of the SSP. The CSP is responsible for all SSP content. An
+assessor\'s tools must not change an SSP.
+
+If an assessor must move forward with inaccurate SSP information, the
+SAP syntax allows for SSP information correction. Performing these
+corrections in the SAP instead of the SSP ensures the corrected content
+is clearly attributed to the assessor.
+
+Tool designers should ensure their tools can cite the relevant
+OSCAL-based SSP information when possible and capture assessor-corrected
+SSP information in the SAP\'s local-definitions or metadata sections
+when necessary. The relevant sections of this guide describe how to
+represent inaccurate SSP information in the SAP when needed.
+
+### 3.5.2. If No OSCAL-based SSP Exists (General)
+
+The OSCAL-based SAP must always have an import-ssp field, even if no
+OSCAL-based SSP is available. To compensate for this, use a URI fragment
+that points to a resource in the back-matter. The resource must have a
+\"type\" property with the value of **no-oscal-ssp**
+
+#### SAP Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ System's Full Name
+
+ Briefly describe the system. This will appear in the SAR.
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) Resource representing system details when no OSCAL-based SSP exists:
+ /*/back-matter/resource/prop[@name='type'][@value='no-oscal-ssp']
+
+{{}}
+
+The system\'s authorization date, purpose, and description have not
+historically been displayed in the SAP but must be present in the SAP
+for the SAR to reference.
+
+Include the system name in the title field, and the system description
+in the description field. Add FedRAMP Extension properties to capture
+the system\'s short name as \"title-short\", FedRAMP-assigned system
+identifier as \"system-id" and describe the system\'s purpose in
+\"purpose\".
+
+Also include the \"import-profile\" extension and supply either a URI to
+the profile externally or a URI fragment with the UUID of the SAP
+resource containing the relevant profile details.
+
+In addition to defining the system here, SAP tools must place other
+relevant SSP information in the SAP\'s metadata and local-definitions
+section as needed for the SAP to reference this information, essentially
+treating all relevant SSP content as \"missing\" from an OSCAL
+perspective.
+
+The relevant sections of this guide describe how to represent missing
+SSP in formation in the SAP when needed.
+
+## 3.6. Resolution Resource Prop
+
+FedRAMP will be implementing a separate set of automated SAP validation
+rules for the rev 5 OSCAL templates. To ensure FedRAMP initiates the
+appropriate validation rules when processing OSCAL SAPs, SAP authors
+should add a new prop called "resolution-resource" in the metadata
+section and include an associated back-matter resource as shown below:
+
+#### SSP Resolution Resource Representation
+{{< highlight xml "linenos=table, hl_lines=11-14" >}}
+
+
+ FedRAMP Security Assessment Plan (SAP)
+
+ fedramp2.0.0-oscal1.0.4
+ 1.0.4
+
+
+
+
+
+
+
+
+
+ Resolution Resource
+
+ This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAP (rev 4 or rev 5) this OSCAL document is for.
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAR) UUID of “resolution-resource”:
+ /*/metadata/prop[@name=”resolution-resource”]/@value
+ (SAR)Target baseline version:
+ /*/back-matter/resource[@uuid=”uuid-of-resolution-resource”]/prop[@name=”dataset” and @class=”version”]/@value
+
+{{}}
+
+If the "resolution-resource" prop is not specified in the metadata
+section of the SAP, FedRAMP will assume the SAP should be validated
+using the rev 5 validation rules. If the "resolution-resource" prop is
+present, FedRAMP will use the validation rules that correspond with the
+version specified in the back-matter resource.
diff --git a/docs/content/guides/sap/4-sap-template-to-oscal-mapping.md b/docs/content/guides/sap/4-sap-template-to-oscal-mapping.md
new file mode 100644
index 000000000..0b9385298
--- /dev/null
+++ b/docs/content/guides/sap/4-sap-template-to-oscal-mapping.md
@@ -0,0 +1,1792 @@
+---
+title: SAP Template to OSCAL Mapping
+section: /sap/
+toc:
+ enabled: true
+weight: 102
+---
+
+For SAP-specific content, each page of the SAP is represented in this
+section, along with OSCAL code snippets for representing the information
+in OSCAL syntax. There is also XPath syntax for querying the code in an
+OSCAL-based FedRAMP SAP represented in XML format.
+
+Content that is common across OSCAL file types is described in the
+*[Guide to OSCAL-based FedRAMP Content](/guides/general/).*
+This includes the following:
+
+| Topic | Location |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Title Page** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#title-page)_, Section 4.1_ |
+| **Prepared By/For** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#prepared-by-third-party)_, Section 4.2 - 4.4_ |
+| **Record of Template Changes** | Not Applicable. Instead follow [_Guide to OSCAL-based FedRAMP Content_](/guides/general/2-working-with-oscal-files/#oscal-syntax-version)_, Section 2.3.2, OSCAL Syntax Version_ |
+| **Revision History** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-revision-history)_, Section 4.5_ |
+| **How to Contact Us** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#how-to-contact-us)_, Section 4.6_ |
+| **Document Approvers** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-approvals)_, Section 4.7_ |
+| **Acronyms and Glossary** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#fedramp-standard-attachments-acronyms-lawsregulations)_, Section 4.8_ |
+| **Laws, Regulations, Standards and Guidance** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#additional-laws-regulations-standards-or-guidance)_, Section 4.9_ |
+| **Attachments and Citations** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#attachments-and-embedded-content)_, Section 4.10_
+
+It is not necessary to represent the following sections of the SAR
+template in OSCAL; however, tools should present users with this content
+where it is appropriate:
+
+- Any blue-text instructions found in the SAP template where the
+ instructions are related to the content itself.
+
+- Table of Contents.
+
+- Introductory and instructive content in each section.
+
+The Annual SAP was used, which includes all information typically found
+in the Initial SAP, plus a scope section that is unique to annual
+assessments. OSCAL always requires a scope. For initial assessments, the
+scope is all controls. For annual assessments, it is the controls
+required by FedRAMP.
+
+**NOTE: The FedRAMP SAP template screenshots in the sections that follow
+vary slightly from the most current version of the FedRAMP rev 5 SAP
+template.**
+
+**The following pages are intended to be printed landscape on tabloid
+(11\" x 17\") paper.**
+
+---
+## 4.1. Background
+
+The *Background*, *Purpose*, and *Applicable Laws* sections of the
+FedRAMP SAP template contain references to the CSP name, the CSO name,
+and the independent assessor (IA) name. The information in these
+sections may be represented as a part assembly within the
+terms-and-conditions element of an OSCAL SSP. This approach is optional
+as the specific data items can simply be queried from an OSCAL SAP and
+its associated documents.
+
+
+
+#### SAP Import Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ Background
+ Insert text from FedRAMP template
+ Insert text from FedRAMP template
+
+ Insert text from FedRAMP template
+
+
+
+ Purpose
+ This SAP has been developed by [IA Name] and is for [an initial assessment/an annual assessment/an annual assessment and significant change assessment/a significant change assessment] of the [CSP Name], [CSO Name]. The SAP provides the goals for the assessment and details how the assessment will be conducted.
+
+
+
+ Applicable Laws, Regulations, Standards and Guidance
+ The FedRAMP-applicable laws, regulations, standards and guidance is included in the [CSO Name] SSP section – System Security Plan Approvals. Additionally, in Appendix L of the SSP, the [CSP Name] has included laws, regulations, standards, and guidance that apply specifically to this system.
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) IA Name:
+ /assessment-plan/metadata/party[@uuid="uuid-of-ia"]/name
+ (SAP) Initial assessment, annual assessment, or significant change?
+ /assessment-plan/metadata/prop[@ns="https://fedramp.gov/ns/oscal" and @name="assessment-type"]/@value
+ (SAP) Are there no/one/many significant changes in SAP scope?
+ /assessment-plan/metadata/prop[@ns="https://fedramp.gov/ns/oscal" and @name="significant-changes-scope"]/@value
+ (SAP) CSP Name:
+ /assessment-plan/metadata/party[@uuid="uuid-of-csp"]/name
+ (SSP) CSO Name:
+ /system-security-plan/system-characteristics/system-name
+
+{{}}
+
+---
+## 4.2. Scope
+
+This information should come entirely from the imported SSP. If the
+OSCAL-based SSP exists and is accurate, the tool should query that file
+for this information as follows:
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Table 2-1
+ (SSP) Unique Identifier:
+ /*/system-characteristics/system-id[@identifier-type='https://fedramp.gov']
+ (SSP) Information System Name:
+ /*/system-characteristics/system-name
+ (SSP) Information System Abbreviation:
+ /*/system-characteristics/system-name-short
+
+{{}}
+
+If no OSCAL-based SSP exists, as described in *Section 3.5.2, If No
+OSCAL-based SSP Exists (General)*, the resource with the no-oscal-ssp
+type must designate the system\'s identifier, name, and abbreviation.
+
+**NOTE:**
+
+The system\'s authorization date, purpose, and description have not
+historically been displayed in the SAP but must be present when the SAR
+references this content.
+
+### 4.2.1. Location of Components
+
+The SAP reference location information in the SSP using its ID and must
+explicitly cite each location within the scope of the assessment. While
+all is valid OSCAL syntax, FedRAMP requires locations to be explicitly
+cited, so that the assessor can add their own description of the
+location. Also, the SSP will likely also contain locations that are not
+data centers.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ A description of the locations.
+
+
+
+ Briefly describe the components at this location.
+
+
+
+
+ Briefly describe the components at this location.
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SSP) List the Data Center UUIDs in the SSP (Primary and Alternate):
+ /*/metadata/location[prop[@name='type'][@value='data-center']]/@uuid
+ (SSP) List the Primary Data Center UUIDs in the SSP:
+ /*/metadata/location[prop[@name='type'][@value='data-center'][@class='primary']]/@uuid
+ NOTE: For just alternate data centers, replace 'primary' with 'alternate'.
+ (SAP) Location UUID (First Location cited in SAP):
+ /*/assessment-subject[@type='location']/include-subject[1]/@subject-uuid
+ NOTE: Replace "[1]" with "[2]", "[3]", etc.
+ (SSP) Data Center Site Name (Lookup in SSP, using ID cited in SAP):
+ /*/metadata/location[@id='location-2']/prop[@name='title'] [@ns='https://fedramp.gov/ns/oscal']
+ NOTE: Replace 'location-2' with the SSP location as cited in the SAP.
+ (SSP or SAP) Address:
+ /*/metadata/location[@uuid='uuid-value-from-SAP']/address/addr-line
+ NOTE: Replace addr-line with city, state, and postal-code as needed.
+ There may be more than one addr-line.
+ NOTE: Replace 'location-2' with the SSP location as cited in the SAP.
+
+ (SSP) CSP's Description of Location (from SSP):
+ /*/metadata/location[@uuid='uuid-value-for-location-2']/remarks
+ (SAP) Assessor's Description of Components at the first location:
+ /*/assessment-subject[@type='location']/include-subject[1]/remarks/node()
+
+ NOTE: Replace "[1]" with "[2]", "[3]", etc.
+
+{{}}
+
+If no OSCAL-based SSP exists, or the location of components is not
+accurately reflected in the SSP, this information may be added to the
+SAP\'s metadata section using the same syntax as the SSP. The
+include-subject citations are still required as described above;
+however, the IDs point to the SAP\'s location data instead of the
+SSP\'s.
+
+The same queries work as presented above; however, the queries are used
+in the SAP instead of the SSP.
+
+---
+### 4.2.2. IP Addresses Slated for Testing
+
+The SAP references SSP content for this information. Each subnet should
+be represented in the SSP as a component with type=\'subnet\'. If the
+SSP does not enumerate subnets in this way, the SAP tool should allow
+the assessor to add them to the SAP\'s local-definitions as components.
+
+Beyond subnets, this section is an enumeration of the SSP\'s
+inventory-item assemblies, which always contain the hostname and IP
+address of the item. Other details, such as the software and version
+information, may be found in the inventory item itself or the SSP
+inventory item may be linked to an SSP component containing those
+details, depending on whether the SSP is using the legacy (flat)
+approach or the preferred component approach.
+
+If the assessor needs to add missing component or inventory-item
+entries, or if the assessor needs to correct this information, the SAP
+tool must add this assessor-provided information to the SAP\'s
+local-definitions.
+
+See the [*Guide to OSCAL-based FedRAMP System Security Plans*](/guides/ssp/)
+to learn more about legacy (flat-file) and component-based inventory
+approaches. Use a combination of include-subject and exclude-subject
+assemblies to specify the SSP IDs of all in-scope components and
+inventory-items. Excluding items is typically used in association with
+the rules of engagement.
+
+If an inventory-item is linked to a component in the SSP, the component
+is automatically within scope as this is often necessary to get the
+software and version information. Tools should honor this relationship
+and consider linked components to be implicitly in-scope even if the
+component was not explicitly cited in the SAP.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+ A description of the included component.
+
+
+ Description of the included inventory.
+
+
+ Description of the included inventory.
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) Should all inventory-items be included? (true/false):
+ boolean(/*/assessment-subject[@type='inventory-item']/include-all)
+ NOTE: This means all inventory-items in the SSP's system-implementation as well as all inventory-items in the SAP's local definitions
+ (SAP) Get the first inventory-item UUID from the SAP:
+ /*/assessment-subject[@type='inventory-item']/include-subject[1]/@subject-uuid
+ (SSP) Get Host Name from inventory-item in the SSP:
+ /*/system-implementation/system-inventory/inventory-item[@uuid='uuid-value-from-above']/prop[@name='fqdn']
+
+{{}}
+
+
+---
+#### 4.2.2.1 If No OSCAL-based SSP Exists or Has Inaccurate Information (IP Addresses)
+
+If no OSCAL-based SSP exists, or the inventory information is not
+accurately reflected in the SSP, this information may be added to the
+SAP\'s local-definition section as described below. The include-subject
+citations are still required as described above; however, the UUIDs
+point to the SAP\'s local definitions instead of the SSP.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ A Windows laptop, not defined in the SSP inventory.
+
+
+
+
+ A subnet not defined in the SSP inventory.
10.20.30.0/24
+
+
+
+
+
+ Description of the included inventory.
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) Get the included ID the same way:
+ /*/assessment-subject[@type='inventory-item']/include-subject[2]/@subject-uuid
+ (SAP) Get Subnet from inventory-item in the SAP:
+ /*/local-definitions/inventory-item[@uuid='value-from-above']/prop[@name='ipv4-subnet']/@value
+
+{{}}
+
+---
+### 4.2.3. SAP Web Applications Slated for Testing
+
+The SSP inventory data should already indicate which assets have a web
+interface, with the following FedRAMP extension:
+
+{{< highlight xml "linenos=table" >}}
+
+
+ Web Application Test #1
+ Describe this web application test.
+
+
+
+ Web Application Tests
+
+ Web Application Test #1
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SAP) Login URL:
+ (/*//task[prop[@name='type'][@ns="https://fedramp.gov/ns/oscal"][@value='web-application']])[1]/prop[@name='login-url'][@ns="https://fedramp.gov/ns/oscal"]
+ (SAP) Login ID:
+ (/*//task[prop[@name='type'][@ns="https://fedramp.gov/ns/oscal"][@value='web-application']])[1]/prop[@name='login-id'][@ns="https://fedramp.gov/ns/oscal"]
+ (SAP) Inventory-ID of host:
+ (/*//task[prop[@name='type'][@ns="https://fedramp.gov/ns/oscal"][@value='web-application']])[2]/ associated-activity/subject[@type='inventory-item']/include-subject/@subject-uuid
+ NOTE: Replace "[2]" with "[2]", "[3]", etc.
+ REMEMBER: The inventory-item could be in the SSP's system-implementation or the SAP's local-definitions.
+
+{{}}
+
+---
+### 4.2.2. SAP Databases Slated for Testing
+
+The SSP inventory data should already indicate which assets are a database, with the following FedRAMP extension:
+
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Assessor Specified Role
+
+ id-for-assessor-specified-role
+
+ Full administrative access (root)
+ Add/remove users and hardware
+ install and configure software
+ OS updates, patches and hotfixes
+ perform backups
+
+
+
+
+{{}}
+
+For every role to be tested, whether pre-identified in the SSP or
+identified by the assessor, there must be an assessment-subject entry,
+and at least one corresponding task. A SAP tool should enable the
+assessor to add a test user ID here via FedRAMP extension properties.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+ A description of the included roles.
+ A description of an excluded role.
+
+
+
+
+
+ Role-Based Tests
+
+ Role Based Test #1
+
+
+ Role Based Test #2
+
+
+
+
+
+{{}}
+
+---
+## 4.3. SAP Assumptions
+
+SAP Assumptions use syntax similar to OSCAL control catalog statements.
+They have a sort-id, which a tool can use to ensure the intended
+sequence is maintained.
+
+The insert elements can be used by tool developers as insertion points
+for data items that the tool may manage as parameters. The use of insert
+within an OSCAL part is described on the [NIST OSCAL Concepts page](https://pages.nist.gov/OSCAL/resources/concepts/layer/control/catalog/sp800-53rev5-example/#parts).
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ This SAP is based on
+
+
+ The
+
+
+ The
+
+
+ The
+
+
+ Security controls that ... on these security controls.
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Obtain Sort IDs, for sorting by the SAP tool:
+ /*/terms-and-conditions/part[@name='assumptions']/ part[@name='assumption']/prop[@name='sort-id']
+(SAP) The first assumption statement:
+ /*/terms-and-conditions/part[@name='assumptions']/ part[@name='assumption']/prop[@name='sort-id'] [.='001']/../(* except prop)
+NOTE: Replace '001' with '002', '003', etc. for each sort-id based on desired order.
+
+{{}}
+
+**NOTES:**
+
+- If the tool is using XPath 1.0 or 2.0, the tool must sort the
+ results of the sort-id list, and then obtain the assumptions in the
+ intended sequence. XPath 3.0 has a sort function, which can perform
+ the sort for the tool.
+
+- OSCAL does not support the insertion of values within Markup
+ Multiline at this time. The tool must either replace each \"\[CSP
+ Name\]\" and \"\[3PAO Name\]\" with the appropriate value or enable
+ the assessor to manually make those changes. This feature may be
+ added to future version of OSCAL.
+
+---
+## 4.4. SAP Methodology
+
+In general, the methodology is simply a single markup multiline field, which enables the assessor to modify the content using rich text formatting. The FedRAMP SAP template includes subsections for *Control Testing, Data Gathering, Sampling,* and *Penetration Test*. Each of these sections must be present in the FedRAMP OSCAL SAP terms-and-condition assembly, within part named "methodology" as sub-parts. The subparts are specifically defined for FedRAMP SAP, so they have namespace "https://fedramp.gov/ns/oscal" and attributes are named "control-testing", "data-gathering", "sampling", and "pen-testing".
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Methodology
+
+
+ Control Testing
+ [IA Name] will ...
+
+
+
+ Data Gathering
+ [IA Name] data gathering activities will ...
+
+
+
+ Sampling
+ The sampling methodology for evidence/artifact gathering, related to controls assessment, is described in Appendix B.
+ [IA Name] [will/will not] ...
+
+
+
+ The Penetration Test Plan and Methodology is attached in Appendix C.
+
+
+
+
+
+{{}}
+
+FedRAMP requires the presence of the sampling property, which indicates whether sampling will be used by the
+assessor for the assessment. The insert elements can be used by tool developers for insertion points for data items that the tool may manage as parameters. CSP tools must display a definitive statement based on the value of the sampling property.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Methodology
+
+
+
+ Sampling
+ The sampling methodology for evidence/artifact gathering, related to controls assessment, is described in Appendix B.
+ [IA Name] [will/will not] ...
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Will the assessor use sampling?:
+ /*/terms-and-conditions/part[@name='methodology']/prop[@name='sampling']/@value
+(SAP) Methodology Description:
+ /*/terms-and-conditions/part[@name='methodology']/(* except prop)
+
+{{}}
+
+**NOTES:**
+
+- The SAP tool should provide the assessor with an automated way to
+ replace \[CSP Name\] and \[3PAO Name\] with the actual names of
+ those parties.
+
+- The SAP tool should allow the assessor to modify this content as
+ needed.
+
+## 4.5. Control Testing
+
+An OSCAL SAP must always explicitly select the in-scope controls from
+the applicable FedRAMP Baseline/Profile. For initial assessments, this
+can be as simple as specifying include-all. For annual assessments, use
+include-control instead - one for each control included in the
+assessment. Controls may also be explicitly excluded from the control
+scope.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ Include all controls in the baseline.
+ Then exclude any specific controls if necessary.
+ Provide rationale/justification for control exclusion here.
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Include All Controls? (true or false):
+ boolean(/*/objectives/controls/include-all)
+(SAP) Exclude Controls Specified? (true or false):
+ boolean(/*/objectives/controls/exclude-control)
+(SAP) Exclude Controls Total (integer):
+ count(/*/objectives/controls/exclude-control)
+(SAP) Exclude Specific Control (string):
+ /*/objectives/controls/exclude-control[1]/@control-id
+NOTE: Replace "exclude-control" with "include-control" above for any explicitly included controls; however, this is redundant when used with 'all'.
+
+{{}}
+
+**NOTES:**
+
+- Tools should validate the control IDs for explicitly included or
+ excluded controls using the relevant baseline.
+
+- FedRAMP\'s guidance and requirements regarding which controls are
+ in-scope for each assessment does not change with OSCAL.
+
+---
+## 4.6. SAP Test Plan
+
+### 4.6.1. Assessor\'s Name, Address, and URL
+
+The SAP\'s metadata is used to represent
+the assessor\'s name address and URL. This uses the OSCAL common role,
+party, and responsible-party assemblies. Some roles are specific to the
+SAP. In the responsible-party assembly, the party-uuid may point to a
+party in the SSP or SAP. The SAP tool must not assign a role ID or party
+ID that duplicates one used in the SSP.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Assessment Organization
+ The organization performing the assessment.
+
+
+
+ Suite 0000
+ 1234 Some Street
+ Haven
+ ME
+ 00000
+ US
+
+
+
+ Assessment Organization Name
+ Acronym/Short Name
+ sap-location-1
+ https://assesor.web.site
+ 0000.00
+
+
+ uuid-of-assessor
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Assessor's Name:
+ /*/metadata/party[@id=(/*/metadata/responsible-party[@role-id='assessor']/party-uuid)] /org/org-name
+(SAP) Assessor's Street Address (replace addr-line with city, state, etc.):
+ /*/metadata/location[@id=/*/metadata/party[@id=(/*/metadata/responsible-party[@role-id='assessor']/party-uuid)]/org/location-id]/address/addr-line
+(SAP) Assessor's Web Site:
+ /*/metadata/party[@id=(/*/metadata/responsible-party[@role-id='assessor']/party-uuid)] /org/url
+(SAP) 3PAO's A2LA Certification Number:
+ /*/metadata/party[@id=(/*/metadata/responsible-party[@role-id='assessor']/party-uuid)] /org/prop[@name='iso-iec-17020-identifier'][@ns='https://fedramp.gov/ns/oscal']
+
+{{}}
+
+---
+### 4.6.2. Security Assessment Team
+
+The SAP\'s metadata is used to represent the assessment team and
+assessment lead. This uses the OSCAL common role, party, and
+responsible-party assemblies. Some roles are specific to the SAP. The
+SAP tool must not assign a role ID or party ID that duplicates one used
+in the SSP.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Assessment Team
+ The individual or individuals performing the assessment.
+
+
+ [SAMPLE]Person Name 2
+ assessment-org
+ sap-location-1
+ name@org.domain
+ 202-000-0000
+
+
+
+ sap-person-2
+ sap-person-3
+ sap-person-4
+ sap-person-5
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of Assessment Team Members (integer):
+ count(/*/metadata/responsible-party[@role-id='assessment-team']/party-uuid)
+(SAP) Name of First Assessment Team Member:
+ /*/metadata/party[@id=/*/metadata/responsible-party[@role-id='assessment-team'] /party-uuid[1]]/person/person-name
+(SAP) Role of First Assessment Team Member:
+ /*/metadata/role[@id='assessment-team']/title
+(SAP) Contact Information of First Assessment Team Member (phone):
+ /*/metadata/party[@id=/*/metadata/responsible-party[@role-id='assessment-team'] /party-uuid[1]]/person/phone
+NOTE: Replace 'phone' with 'email'
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+---
+### 4.6.3. CSP Testing Points of Contact
+
+The SAP\'s metadata is used to represent the CSP\'s points of contact.
+This uses the OSCAL common role, party, and responsible-party
+assemblies. In the responsible-party assembly, the party-uuid may point
+to a party in the SSP or SAP. The SAP tool must not assign a role ID or
+party ID that duplicates one used in the SSP. If an individual is
+already identified via a party assembly in the SSP, that individual\'s
+information should not be duplicated in the SAP. Instead, the SAP should
+reference the SSP party ID for that individual.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ CSP POCs During Testing
+ At least three CSP POCs must be identified in a FedRAMP SAP.
+
+
+
+
+
+
+ person-1
+ person-2
+ soc
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of CSP Assessment POCs (integer):
+ count(/*/metadata/responsible-party[@role-id='csp-assessment-poc']/party-uuid)
+(SAP) ID of the first CSP Assessment POC:
+ /*/metadata/responsible-party[@role-id='csp-assessment-poc']/party-uuid[1]
+NOTE: Replace [1] as needed with [2], [3], etc.
+(SAP) Role:
+ /*/metadata/role[@id='csp-assessment-poc']/title
+(SSP) Name of the first person or organization:
+ /*/metadata/party[@id='person-1']/(./person/person-name | ./org/org-name)
+(SSP) Phone for the first person or organization:
+ /*/metadata/party[@id='person-1']//phone
+(SSP) Email for the first person or organization:
+ /*/metadata/party[@id='person-1']//email
+NOTE: Replace 'person-1' with each party-uuid found in the responsible role.
+
+{{}}
+
+**NOTES:**
+- IDs used for roles or parties in the SAP must not duplicate IDs used
+ for roles or parties in the SSP.
+
+- Only define a CSP party in the SAP when no appropriate party exists
+ in the SSP.
+
+---
+### 4.6.4. Testing Performed Using Automated Tools
+
+Automated tools are enumerated in the assets section of the SAP using
+the tools assembly. Each tool is listed using the same component syntax
+available in the SSP.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ XYZ Vulnerability Scanning Tool
+
+ Describe the purpose of the tool here.
+
+
+
+
+ XYZ Database Scanning Tool
+
+ Describe the purpose of the tool here.
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of Tools (integer):
+ count(/*/assessment-assets/component)
+(SAP) Name of first tool:
+ /*/assessment-assets/component[1]/prop[@name='name']/@value
+(SAP) Vendor/Organization Name of first tool:
+ /*/assessment-assets/component[1]/prop[@name='vendor']/@value
+(SAP) Version of first tool:
+ /*/assessment-assets/component[1]/prop[@name='version']/@value
+(SAP) Purpose of first tool:
+ /*/assessment-assets/component[1]/description/node()
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- OSCAL syntax requires a status field within each component assembly.
+ For FedRAMP, assessment tools state should typically be
+ \'operational\', otherwise a remark must be provided.
+
+---
+### 4.6.5. Testing Performed Through Manual Methods
+
+In OSCAL, the manual assessment methods are described in the activity
+assembly as shown below:
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Title of the Manual Test
+
+ Description of the manual test
+
+
+ Describe test step #1
+
+ Describe test step #2
+
+ Describe test step #3
003
+
+
+
+ [SAMPLE]Forceful Browsing
+
+ We will login as a customer ...cut... browser to various URLs
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of manual test methods (integer):
+ count(/*/local-definitions/activity[prop[@name='type'][@value='manual']])
+(SAP) Test ID of first manual test method:
+ (/*/local-definitions/activity[prop[@name='type'][@value='manual']]) [1]/prop[@name='label']
+(SAP) Test Name of first manual test method:
+ (/*/local-definitions/activity[prop[@name='type'][@value='manual']]) [1]/title
+(SAP) Description of first manual test method:
+ (/*/local-definitions/activity[prop[@name='type'][@value='manual']]) [1]/description/node()
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- If a test method represents more than one test type, such as manual
+ test that is also a role-based test, the test-type property should
+ appear twice, indicating each type.
+
+---
+#### Including Manual Test Methods in the OSCAL SAP Test Plan Section
+
+The FedRAMP OSCAL SAP terms-and-condition assembly, should contain a
+part with ns=\"https://fedramp.gov/ns/oscal\" name=\"manual-methods-testing\" when needed to facilitate rending of
+OSCAL SAP by tools. The insert elements can be used by tool developers
+as insertion points for data items such as test ID, test name, and test
+description if the tool is able manage them as parameters. The use of
+insert within an OSCAL part is described on the [NIST OSCAL Concepts page](https://pages.nist.gov/OSCAL/concepts/layer/control/catalog/sp800-53rev5-example/#parts). The XPath queries below show how to identify manual test information within the OSCAL SAP.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Test Plan
+
+
+ Testing Performed Using Manual Methods
+
+
+ Test ID
+ Test Name
+ Description
+
+
+
+ [Insert test ID]
+ [Insert test name]
+ [Insert test description text]
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Test ID:
+ /assessment-plan/local-definitions[1]/activity[1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="label"]/@value
+(SAP) Test Name:
+ /assessment-plan/local-definitions[1]/activity[1]/title
+(SAP) Description:
+ /assessment-plan/local-definitions[1]/activity[1]/description/p
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+---
+### 4.6.6. Schedule
+
+In OSCAL, the assessment schedule is described using an array of task
+assemblies as shown below:
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+ Prepare Test Plan
+
+ optional description here
+
+
+
+
+
+ Meeting to Review Test Plan
+
+ optional description here
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of tasks in schedule (integer):
+ count(/*/task)
+(SAP) Name of first task:
+ /*/task[1]/title
+(SAP) Start date of first task:
+ /*/task[1]/timing/within-date-range/@start
+(SAP) Finish date of first task:
+ /*/task[1]/timing/within-date-range/@end
+(SAP) Optional Description of first task:
+ /*/task[1]/description/node()
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- In the OSCAL file, the start and end fields must use the OSCAL data
+ type
+ [dateTime-with-timezone](https://pages.nist.gov/OSCAL/reference/datatypes/#date-with-timezone).
+
+- The time may be entered as all zeros.
+
+- For FedRAMP, a SAP tool should display only the date and ignore the
+ time. The date should be presented to the user in a more
+ user-friendly format.
+
+---
+## 4.7. SAP Rules of Engagement (ROE)
+
+### 4.7.1. Origination Addresses
+
+The scan origination IP address(es) are included in the
+assessment-platform assembly. See the next page for other disclosures.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Assessment Laptop
+
+
+ XYZ Vulnerability Scanning Tool
+
+
+ XYZ Database Scanning Tool
+
+
+ Scanning Tools
+
+ Cites assessment laptop.
+
+ Cites assessment laptop.
+
+ Cites Vulnerability Scanning Tool
+
+ Cites Database Scanning Tool
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Count scan origination addresses (integer):
+ count(/*/assessment-assets/assessment-platform/prop[@name='ipv4-address'])
+(SAP) First scan origination address:
+ /*/assessment-assets/assessment-platform/prop[@name='ipv4-address'][1]
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- A SAP tool should present the scan origination addresses using the
+ statement:\
+ \"All scans will originate from the following IP address(es):\",
+ followed by the list of addresses.
+
+---
+### 4.7.2. Disclosures
+
+The scan origination IP address(es) are included in the
+assessment-platform assembly. See the next page for other disclosures\`.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Any testing will be performed according to terms and conditions designed to minimize risk exposure that could occur during security testing.
+
+
+ A disclosure statement
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Count other disclosure statements (integer):
+ count(/*/terms-and-conditions/part[@name='disclosures']/part[@name='disclosure'])
+(SAP) Obtain Sort IDs, for sorting by the SAP tool:
+ /*/terms-and-conditions/part[@name='disclosures']/part[@name='disclosure']/prop[@name='sort-id']
+(SAP) The first assumption statement:
+ /*/terms-and-conditions/part[@name='disclosures']/part[@name='disclosure']/prop[@name='sort-id'] [string()='001']/../(* except prop)
+NOTE: Replace '001' with '002', '003', etc. for each sort-id based on desired order.
+
+{{}}
+
+**NOTES:**
+
+- A SAP tool should present the scan origination addresses using the
+ statement:\
+ \"All scans will originate from the following IP address(es):\",
+ followed by the list of addresses.
+
+---
+### 4.7.3. Security Testing May Include
+
+SAP authors should describe the security testing that may be included
+within the terms-and-conditions assembly, in the "included-activities"
+part and its "included-activity" sub-parts.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Included Activities
+ The following activities are to be included as part of the FedRAMP assessment.
+
+
+
+
+ Port scans and other network service interaction and queries
+
+
+ Network sniffing, traffic monitoring, traffic analysis, and host discovery
+
+
+ Attempted logins or other use of systems, with any account name/password
+
+
+ Attempted structured query language (SQL) injection and other forms of input
+ parameter testing
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of Included Activities:
+ count(/*/terms-and-conditions/part[@name='included-activities']/part[@name='included-activity'])
+(SAP) First Included Activity:
+ /*/terms-and-conditions/part[@name='included-activities']/part[@name='included-activity'][1]/node()
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- An assessment tool should present a list of included activities with
+ a preceding phrase such as, \"Security testing may include the
+ following activities:\"
+
+---
+### 4.7.4. Security Testing Will Not Include
+
+SAP authors should describe exclusive disclosures within the
+terms-and-conditions assembly, in the "excluded-activities" part and its
+"included-activity" sub-parts.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Excluded Activities
+ The following activities are explicitly excluded from the assessment.
+
+ Changes to assigned user passwords
+
+
+ Modification of user files or system files
+
+
+ Telephone modem probes and scans (active and passive)
+
+
+ Intentional viewing of [CSP Name] staff email, Internet caches, and/or personnel
+ cookie files
+
+
+ Denial of service attacks
+
+
+ Exploits that will introduce new weaknesses to the system
+
+
+ Intentional introduction of malicious code (viruses, Trojans, worms, etc.)
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of Excluded Activities:
+ count(/*/terms-and-conditions/part[@name='excluded-activities']/part[@name='excluded-activity'])
+(SAP) First Excluded Activity:
+ /*/terms-and-conditions/part[@name='excluded-activities']/part[@name='excluded-activity'][1]/node()
+NOTE: Replace [1] as needed with [2], [3], etc.
+
+{{}}
+
+**NOTES:**
+
+- An assessment tool should present a list of included activities with
+ a preceding phrase such as, \"Security testing will not include any
+ of the following activities:\"
+
+---
+### 4.7.5. End of Testing
+
+This indicates who the Independent Assessor (IA) should notify within
+the CSP\'s organization when testing is complete.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ CSP's End of Testing Notification POC
+ A role for an individual within the CSP to be notified by the assessor when testing is complete.
+
+
+
+
+
+
+ person-2
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of CSP Parties to notify at EOT (integer):
+ count(/*/metadata/responsible-party[@role-id='csp-end-of-testing-poc']/party-uuid)
+(SAP) ID of the first CSP Party to Notify:
+ /*/metadata/responsible-party[@role-id='csp-end-of-testing-poc']/party-uuid[1]
+NOTE: Replace [1] as needed with [2], [3], etc.
+(SSP) Name of the first person or team:
+ /*/metadata/party[@id='person-2']/(./person/person-name | ./org/org-name)
+(SSP) Phone for the first person or team:
+ /*/metadata/party[@id='person-2']//phone
+(SSP) Email for the first person or team:
+ /*/metadata/party[@id='person-2']//email
+NOTE: Replace 'person-2' with each party-uuid found in the responsible role.
+
+{{}}
+
+**NOTES:**
+
+- IDs used for roles or parties in the SAP must not duplicate IDs used
+ for roles or parties in the SSP.
+
+- Only define a CSP party in the SAP when no appropriate party exists
+ in the SSP.
+
+---
+### 4.7.6. Communication of Test Results
+
+This indicates who the Independent Assessor (IA) should send all the
+assessment results to at the CSP\'s organization.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ CSP Results POCs
+ A role for the individuals within the CSP who are to receive the assessment results.
+
+
+
+
+
+
+ person-1
+ person-2
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Number of CSP Test Result POCs (integer):
+ count(/*/metadata/responsible-party[@role-id='csp-results-poc']/party-uuid)
+(SAP) ID of the first CSP Assessment POC:
+ /*/metadata/responsible-party[@role-id='csp-results-poc']/party-uuid[1]
+NOTE: Replace [1] as needed with [2], [3], etc.
+(SSP) Name of the first person or organization:
+ /*/metadata/party[@id='person-1']/person/person-name
+(SSP) Role/Title of the first person:
+ /*/metadata/party[@id='person-1']/person/prop[@name='title'] [@ns='https://fedramp.gov/ns/oscal']
+(SSP) Phone for the first person or organization:
+ /*/metadata/party[@id='person-1']//phone
+(SSP) Email for the first person or organization:
+ /*/metadata/party[@id='person-1']//email
+NOTE: Replace 'person-1' with each party-uuid found in the responsible role.
+
+{{}}
+
+**NOTES:**
+
+- IDs used for roles or parties in the SAP must not duplicate IDs used
+ for roles or parties in the SSP.
+
+- Only define a CSP party in the SAP when no appropriate party exists
+ in the SSP.
+
+---
+### 4.7.7. Limitation of Liability
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ FedRAMP Required Limitation of Liability Statements
+
+
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Count individual limitations of liability statements (integer):
+ count(/*/terms-and-conditions/part[@name='liability-limitations']/ part[@name='liability-limitation'])
+(SAP) Obtain Sort IDs, for sorting by the SAP tool:
+ /*/terms-and-conditions/part[@name='liability-limitations']/part[@name='liability-limitation'] /prop[@name='sort-id']
+(SAP) The first liability limitation statement:
+ /*/terms-and-conditions/part[@name='liability-limitations']/part[@name='liability-limitation']/prop [@name='sort-id'] [string()='001']/../(* except prop)
+NOTE: Replace '001' with '002', '003', etc. for each sort-id based on desired order.
+
+{{}}
+
+---
+## 4.8. SAP Signatures
+
+Using a machine-readable format such as OSCAL for SAP content creates a
+challenge in the handling of acceptance signatures. Early adopters are
+encouraged to approach the FedRAMP PMO to discuss specific solutions on
+a case-by-case basis. Until such time as the FedRAMP PMO and JAB have a
+well-established capability for handling signatures, one of the
+following approaches is encouraged:
+
+- Manual \"Wet\" Signature Approach (Document or Letter)
+
+- Digital Signature
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Signed SAP
00000000
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Link to signed SAP in PDF Format:
+ /*/back-matter/resource/prop[@name='type'] [.='signed-sap']/../rlink/@href
+(SAP) Base64-encoded signed SAP in PDF Format:
+ /*/back-matter/resource/prop[@name='type'] [.='signed-sap']/../base64
+
+{{}}
+
+### 4.8.1. Manual \"Wet\" Signature Approach (Document or Letter) Print, manually sign, scan, and attach.
+
+1. Print one of the following:
+
+ a. The OSCAL-based SAP content with a tool that renders the SAP in
+ a format that resembles the MS-Word based FedRAMP SAP Template;
+ or
+
+ b. A separate letter, which uses the same language.
+
+2. Have all parties manually sign the document or letter in ink.
+
+3. Scan the signed copy.
+
+4. Attach it to the OSCAL-based SAP as a resource.
+
+### 4.8.2. Digital Signature Approach Render, digitally sign, and attach.
+
+1. Render the OSCAL-based SAP content as a PDF that resembles the
+ MS-Word based FedRAMP SAP Template.
+
+2. Have all parties digitally sign the PDF document.
+
+3. Attach it to the OSCAL-based SAP as a resource.
+
+---
+## 4.9. SAP Appendices
+
+### 4.9.1. Security Controls Selection Worksheet
+
+An OSCAL SAP must always explicitly select the in-scope controls from
+the applicable FedRAMP Baseline/Profile. See section 4.5 Controls
+Testing for additional guidance.
+
+### 4.9.2. Test Case Procedures
+
+The assessment objectives and actions (Examine, Interview, and Test)
+from the test case workbook are now part of the [OSCAL-based FedRAMP
+baselines](https://github.com/GSA/fedramp-automation/tree/master/baselines),
+with the detail imported from the OSCAL-based NIST SP 800-53 Catalog via
+the baseline.
+
+#### 4.9.2.1. Baseline Objectives and Methods
+
+To include an assessment objective and associated actions in the SAP,
+its control must be designated in-scope as described in *Sections 4.1,
+SAP Scope*. SAP tools should support and enforce this constraint.
+
+In most cases, a FedRAMP assessor must adopt these without change. In
+this case, a SAP tool may simply specify all, to indicate that all
+assessment objectives should be included for all in-scope controls. If
+needed, objectives can be explicitly included or excluded as well.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Control Scope
+
+ Control Objective Scope
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Include All Objectives for in-scope controls? (true or false):
+ boolean(/*/reviewed-controls/control-objective-selection/include-all)
+(SAP) Exclude Controls Specified? (true or false):
+ boolean(/*/objectives/control-objectives/exclude-objective)
+(SAP) Exclude Objectives Total (integer):
+ count(/*/objectives/control-objectives/exclude-objective)
+(SAP) Exclude Specific Objective (string):
+ /*/objectives/control-objectives/exclude-objective[1]/@objective-id
+
+NOTE: Replace "exclude-objective" with "include-objective" above for any explicitly included objective; however, this is redundant when used with 'all'.
+
+{{}}
+
+#### 4.9.2.2. Sampling Methodology
+
+The sampling methodology may continue to be a separate, attached
+document. This should be provided as a back-matter resource, containing
+a FedRAMP "type" prop with an allowed value, sampling-methodology.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Sampling Methodology
+
+ Embed or reference copies of the sampling methodology for security controls assessment and vulnerability scanning (if applicable).
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Link to Sampling Methodology:
+ /*/back-matter/resource/prop[@name='type'] [@value='sampling-methodology']/../rlink/@href
+(SAP) Base64-encoded Sampling Methodology:
+ /*/back-matter/resource/prop[@name='type'] [@value=''sampling-methodology ']/../base64
+
+{{}}
+
+---
+### 4.9.3. SAP Penetration Testing Plan and Methodology
+
+The penetration test plan methodology may continue to be a separate,
+attached document. This should be provided as a back-matter resource,
+containing a FedRAMP "type" prop with an allowed value,
+penetration-test-plan.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Penetration Testing Plan and Methodology
+
+ . . . /p>
+
+
+
+ Include
+ Mandatory Attack Vectors
+ Include
+ Threat Models
+ Include
+ Attack Models
+
+
+ x
+ External to Corporate
+ Internet based (untrusted)
+ Enterprise
+
+ . . .
+
+
+ 00000000
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Link to Penetration Test Plan:
+ /*/back-matter/resource/prop[@name='type'] [@value='penetration-test-plan']/../rlink/@href
+(SAP) Base64-encoded Penetration Test Plan:
+ /*/back-matter/resource/prop[@name='type'] [@value='penetration-test-plan']/../base64
+
+{{}}
+
+---
+### 4.9.4. Significant Change Documentation
+
+The significant change documentation must be provided as a back-matter
+resource, containing a FedRAMP "type" prop with an allowed value,
+significant-change-request.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Significant Change Request Documentation
+
+ . . .
+
+
+
+ Role Name
+ Test User ID
+ Associated Functions
+
+ . . .
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAP) Link to Significant Change Documentation:
+ /*/back-matter/resource/prop[@name='type'] [@value=' significant-change-request ']/../rlink/@href
+(SAP) Base64-encoded Significant Change Documentation:
+ /*/back-matter/resource/prop[@name='type'] [@value= significant-change-request ']/../base64
+
+{{}}
\ No newline at end of file
diff --git a/docs/content/guides/sap/5-generated-content.md b/docs/content/guides/sap/5-generated-content.md
new file mode 100644
index 000000000..ab7915733
--- /dev/null
+++ b/docs/content/guides/sap/5-generated-content.md
@@ -0,0 +1,58 @@
+---
+title: Generated Content
+section: /sap/
+toc:
+ enabled: true
+weight: 103
+---
+
+The following artifacts are historically generated by hand to summarize
+content found in other FedRAMP-required content. When using OSCAL, these
+artifacts can be generated from content found elsewhere. This includes
+the:
+
+- **IP Addresses Slated for Testing**
+
+- **Databases Slated for Testing**
+
+- **Test Case Workbook**
+
+If delivering FedRAMP content in OSCAL, assessors are no longer required
+to manually generate and maintain these artifacts, provided the content
+in their OSCAL-based FedRAMP SAP and the CSP\'s OSCAL-based FedRAMP SSP
+remains accurate.
+
+There are many ways a tool developer can generate these artifacts.
+FedRAMP is developing Extensible Stylesheet Language Transformation
+(XSLT) files to generate them. When ready, FedRAMP will make this freely
+available to the public here:
+
+[https://github.com/GSA/fedramp-automation/tree/master/dist/content/resources](https://github.com/GSA/fedramp-automation/tree/master/dist/content/resources)
+
+**Tool developers are also encouraged to develop their own solutions to generating this content.**
+
+## 5.1. Generating the \"IP Addresses Slated for Testing\" List
+
+The SAP must still identify the in-scope inventory items - either by
+reference or using the \"all\" clause. Once identified, the list of IP
+addresses slated for testing should be derived from the machine-readable
+inventory found in the SSP.
+
+As described in *Section 4.4.1, If No OSCAL-based SSP Exists or Has
+Inaccurate Information (IP* Addresses), if the assessor finds SSP
+information inventory to be missing or inaccurate, the SAP tool must
+allow the assessor to insert inventory information into the
+local-definitions section of the SAP.
+
+## 5.2. Generating the \"Databases Slated for Testing\" List
+
+The SAP must still identify the in-scope inventory items - either by
+reference or using the \"all\" clause. Once identified, the list of
+Databases slated for testing should be derived from the machine-readable
+inventory found in the SSP.
+
+As described in *Section 4.4.1, If No OSCAL-based SSP Exists or Has
+Inaccurate Information (IP* Addresses), if the assessor finds SSP
+information inventory to be missing or inaccurate, the SAP tool must
+allow the assessor to insert inventory information into the
+local-definitions section of the SAP.
diff --git a/docs/content/guides/sap/_index.md b/docs/content/guides/sap/_index.md
new file mode 100644
index 000000000..5927df8f5
--- /dev/null
+++ b/docs/content/guides/sap/_index.md
@@ -0,0 +1,31 @@
+---
+title: FedRAMP OSCAL SAP Guide
+heading: FedRAMP OSCAL SAP Guide
+menu:
+ primary:
+ name: SAP
+ parent: Documentation
+ weight: 200
+toc:
+ enabled: true
+---
+
+## 2. FedRAMP Extensions and Allowed Values
+
+NIST designed the core OSCAL syntax to model cybersecurity information
+that is common to most organization and compliance frameworks; however,
+NIST also recognized the need to provide flexibility or organizations
+with unique information needs.
+
+Instead of trying to provide a language that meets each organization\'s
+unique needs, NIST provided designed OSCAL with the ability to be
+extended.
+
+As a result, FedRAMP-compliant OSCAL files are a combination of the core
+OSCAL syntax and extensions defined by FedRAMP. The [*Guide to OSCAL-Based FedRAMP Content*](/guides/general/)
+describes the concepts behind FedRAMP extensions and allowed values. The
+extensions related to the Security Assessment Plan (SAP) are cited in
+this document in context of their use.
+
+**FedRAMP extensions and allowed values are cited in relevant portions
+of this document and summarized in the FedRAMP OSCAL Registry.**
\ No newline at end of file
diff --git a/docs/content/guides/sar/3-working-with-oscal-files.md b/docs/content/guides/sar/3-working-with-oscal-files.md
new file mode 100644
index 000000000..5107469eb
--- /dev/null
+++ b/docs/content/guides/sar/3-working-with-oscal-files.md
@@ -0,0 +1,268 @@
+---
+title: Working with OSCAL Files
+section: /sar/
+toc:
+ enabled: true
+weight: 102
+---
+
+This section provides a summary of several important concepts and details that apply\ to OSCAL-based FedRAMP SAR files.
+
+The [*Guide to OSCAL-based FedRAMP Content*](/guides/general/) provides important concepts necessary for working with any OSCAL-based
+FedRAMP file. Familiarization with those concepts is important to understanding this guide.
+
+## 3.1. XML and JSON Formats
+
+The examples provided here are in XML; however, FedRAMP accepts XML or JSON formatted OSCAL-based SAR files. NIST offers a utility that
+provides lossless conversion of OSCAL-compliant files between XML and JSON in either direction.
+
+You may submit your SAR to FedRAMP using either format. If necessary, FedRAMP tools will convert the files for processing.
+
+## 3.2. SAR File 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.
+
+
+*Each OSCAL file imports information from the one to the left*
+
+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.
+
+ \
+*Baseline Information is referenced instead of duplicated.*
+
+For this reason, an OSCAL-based SAR points to the OSCAL-based SAP for this assessment.
+
+In turn, the SAP points to the OSCAL-based SSP of the system being assessed. Instead of duplicating system details, the OSCAL-based SAR
+simply points to the SSP content (via the SAP) for information such as system description, boundary, users, locations, and inventory items.
+
+The SAR also inherits the SSP\'s pointer to the appropriate OSCAL-based FedRAMP Baseline via the SAP. Through that linkage, the SAR references the assessment objectives and actions typically identified in the FedRAMP TCW, as well as any changes to this content made in the SAP during planning.
+
+The only reason to include this content in the SAR is when there is a deviation from the SAP.
+
+### 3.2.1. Resolved Profile Catalogs
+
+The resolved profile catalog for each FedRAMP baseline is a pre-processing of 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 for the separate profile and catalog handling later in their product roadmap.
+
+ \
+*The Resolved Profile Catalog for each FedRAMP Baseline reduces tool processing.*
+
+For more information about resolved profile catalogs, see the [*Guide to OSCAL-based FedRAMP Content*](/guides/general/5-appendices/#profile-resolution) *Appendix, Profile Resolution*.
+
+### 3.2.2. Assessment Deviations and SAP/SAR Syntax Overlap
+
+The SAP represents the assessment intentions before it starts and should not be modified once the assessment starts. The SAR represents what actually happened during the assessment, in addition to reporting the results.
+
+
+
+The SAR reference SAP content when those references are accurate and defines content locally when the assessment details deviate from the SAP. Similarly, the SAR\'s assessment log captures the actual timing of events and can be linked to the SAP\'s defined tasks (schedule).
+
+FedRAMP\'s requirement to report assessment deviations can be very straightforward if the above approach is supported by tools.
+
+For schedule deviations, a SAR's tools can simply compare the SAR assessment log to the SAP tasks and report differences.
+
+Any other changes are essentially summarized in the SAR\'s local definitions. The overarching local definitions captures changes to
+defined activities or control objectives. The \"Result\" local definitions capture missing or inaccurate components, inventory items, users, and assessment tools.
+
+Instead of an assessor manually summarizing assessment deviations, a tool can simply compare the SAP and SAR content and report the
+differences automatically.
+
+### 3.2.3. Copying SAR Residual Risks to the POA&M
+
+FedRAMP requires residual risks from an initial or annual assessment to be reflected in the POA&M. The observation and risk assemblies syntax of the SAR and POA&M are identical to facilitate ease of transfer. The SAR finding assembly and POA&M poam-item assembly are also as similar as possible to further facilitate this transfer.
+
+At the end of an assessment, copy all \"open\" risks from the SAR to POA&M. For every copied risk, also copy all related observations. Risks are linked to observations in the finding assembly.
+
+If available, use the finding/target citation in the SAR to determine the impacted control and set the value in the risk section of the POA&M using the \"impacted-control\" FedRAMP Extension. If the identified SAR risk is not associated with a specific control, the SAR tool should prompt the assessor to assign a value for the risk in the resulting POA&M export.
+
+It may also be necessary to copy content from the AP or SAR into the POA&M\'s Local Definitions, such as to ensure Observation/Origin references remain valid.
+
+
+
+A SAR tool can transfer residual risks to a POA&M using the same OSCAL syntax.
+
+Ideally, tools will automatically detect potential duplicate risks between a new SAR and existing POA&M. In any case, tools should offer a mode for manual review and merging of duplicate risks from different sources.
+
+A SAR tool should collect Test Case Workbook, Automated Tool Output, Manual Test Results, and Penetration Test Results as a series of individual finding assemblies.
+
+As these findings become risks, the SAR tool should allow the risk information to be added to the finding.
+
+As risks are closed during testing, the SAR tool should allow the assessor to mark the status as closed. Likewise, as a risk is found to be a false positive or operationally required, the tool should allow the assessor to make these changes as well. The tool should also provide for risk adjustments, by preserving the initial risk information and adding mitigating factors and adjusted risk values.
+
+Allowing for these adjustments, the Risk Exposure table is simply a view or presentation of the findings that have risks with an open status that have not been marked as a false positive. These are also the entries that are copied to the Cloud Service Provider (CSP)\'s POA&M.
+
+
+
+A SAR allows the assessor to update finding and risk information during the assessment.
+
+### 3.2.4. Previous Assessment Results
+
+The OSCAL assessment results model is designed to support both continuous assessment as well as snapshot in time assessments. Currently, FedRAMP assessments represent a snapshot in time. This means a single result assembly should be used for all of the current assessment findings.
+
+Any findings from previous assessments may be included in the SAR by including each in its own result assembly. In this way, the assessor can include the \"snapshot\" of each previous assessment with the current assessment, eliminating the need to manually copy past findings into that portion of the TCW.
+
+#### SAR Representation
+{{< highlight xml "linenos=table" >}}
+
+ 2023 Annual Assessment
+ 2023-03-01T00:00:00Z
+ 2023-03-12T00:00:00Z
+
+
+
+ 2022 Annual Assessment
+ 2022-03-01T00:00:00Z
+ 2022-03-12T00:00:00Z
+
+
+
+ 2021 Initial Assessment
+ 2021-03-01T00:00:00Z
+ 2021-03-12T00:00:00Z
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) Number of Assessments Represented:
+ count(/*/result)
+(SAR) Start Date of First Results Set:
+ /*/result/start[1]
+NOTE: Replace "[1]" with "[2]", "[3]", etc.
+NOTE: Compare start dates of each result set to identify the newest.
+
+{{}}
+
+## 3.3. OSCAL-based FedRAMP SAR Template
+
+FedRAMP offers an OSCAL-based SAR shell file in both XML and JSON formats. This shell contains many of the FedRAMP required standards to
+help get you started. This document is intended to work in concert with that file. The OSCAL-based FedRAMP SAR Template is available in XML and JSON formats here:
+
+- OSCAL-based FedRAMP SAR Template (JSON Format):\
+ [https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sar/json/FedRAMP-SAR-OSCAL-Template.json](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sar/json/FedRAMP-SAR-OSCAL-Template.json)
+
+- OSCAL-based FedRAMP SAR Template (XML Format):\
+ [https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sar/xml/FedRAMP-SAR-OSCAL-Template.xml](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/sar/xml/FedRAMP-SAR-OSCAL-Template.xml)
+
+## 3.4. OSCAL's Minimum File Requirements
+
+Every OSCAL-based FedRAMP SAR file must have a minimum set of required fields/assemblies, and must follow the OSCAL Assessment Results model syntax found here:
+
+[https://pages.nist.gov/OSCAL/concepts/layer/assessment/assessment-results/](https://pages.nist.gov/OSCAL/concepts/layer/assessment/assessment-results/)
+
+## 3.5. Importing the Security Assessment Plan
+
+OSCAL is designed for traceability. Because of this, the assessment report is designed to be linked to the security assessment plan. Rather than duplicating content from the SSP and SAP, the SAR is intended to reference the SSP and SAP content itself.
+
+{{}}
+#### *Unavailable or Inaccurate OSCAL-based SSP Content*
+*The SAR must import an OSCAL-based SAP, even if no OSCAL-based SSP exists. FedRAMP enables an assessor to use the OSCAL SAP and SAR, when no OSCAL-based SSP exists, or where the assessor finds it to be inaccurate. The [Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)](/guides/sap/4-sap-template-to-oscal-mapping/) describes when and how to represent missing or inaccurate SSP content.*
+
+*SAR tools must search both the SSP (if any) and the SAP for any SSP-related references. If an ID in the SAR references content in both the SSP and the SAP, the tool should treat the SAP content as an update to the SSP content. See the [Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)](/guides/sap/4-sap-template-to-oscal-mapping/) for more details.*
+{{ }}
+
+Use the import-ap field to specify an existing OSCAL-based SAP. The href flag may include any valid uniform resource identifier (URI), including a relative path, absolute path, or URI fragment.
+
+#### SAR Import Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ [System Name] [FIPS-199 Level] SAP
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) Referenced OSCAL-based SAP:
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type= 'application/xml']/@href
+
+{{}}
+
+Where the provided path is invalid, tool developers should ensure the tool prompts the user for the updated path to the OSCAL-based SAP.
+
+## 3.6. Resolution Resource Prop
+
+FedRAMP will be implementing a separate set of automated SAR validation rules for the rev 5 OSCAL templates. To ensure FedRAMP initiates the appropriate validation rules when processing OSCAL SARs, SAR authors should add a new prop called "resolution-resource" in the metadata section and include an associated back-matter resource as shown below:
+
+#### Resolution Resource
+{{< highlight xml "linenos=table, hl_lines=11-13" >}}
+
+
+ FedRAMP Security Assessment Results (SAR)
+
+ fedramp2.0.0-oscal1.0.4
+ 1.0.4
+
+
+
+
+
+
+
+
+
+ Resolution Resource
+
+ This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAR (rev 4 or rev 5) this OSCAL document is for.
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) UUID of “resolution-resource”:
+ /*/metadata/prop[@name=”resolution-resource”]/@value
+(SAR)Target baseline version:
+ /*/back-matter/resource[@uuid=”uuid-of-resolution-resource”]/prop[@name=”dataset” and @class=”version”]/@value
+
+{{}}
+
+If the "resolution-resource" prop is not specified in the metadata section of the SAR, FedRAMP will assume the SAR should be validated using the rev 5 validation rules. If the "resolution-resource" prop is present, FedRAMP will use the validation rules that correspond with the version specified in the back-matter resource.
diff --git a/docs/content/guides/sar/4-sar-template-to-oscal-mapping.md b/docs/content/guides/sar/4-sar-template-to-oscal-mapping.md
new file mode 100644
index 000000000..65ec91148
--- /dev/null
+++ b/docs/content/guides/sar/4-sar-template-to-oscal-mapping.md
@@ -0,0 +1,1423 @@
+---
+title: SAR Template to OSCAL Mapping
+section: /sar/
+toc:
+ enabled: true
+weight: 103
+---
+
+The OSCAL Assessment Results Model is used to represent the FedRAMP SAR. This model includes:
+
+- Metadata and back-matter syntax, which is common to all OSCAL models;
+- Assessment scope, subject, assets, and activities syntax, which is common to both the SAP and SAR; and
+- Results syntax, which is common to the SAR and POA&M.
+
+{{}}
+This guide assumes tool developers are already familiar with the [Guide to OSCAL-based FedRAMP Content](/guides/general) and the [Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)](/guides/sap/).
+
+Instead of duplicating content from those guides, this document refers to them and only adds details that are unique to the SAR.
+{{ }}
+
+This section addresses the TCW, Scanner Tool Results, Risks Identified during Penetration Testing, and the Risk Exposure Table (RET) first. These are addressed first because much of the individual SAR tables are generated from OSCAL-based content.
+
+As described in *Section 2, FedRAMP Extensions and Allowed Values*
+
+NIST designed the core OSCAL syntax to model cybersecurity information that is common to most organization and compliance frameworks; however, NIST also recognized the need to provide flexibility or organizations with unique information needs.
+
+Instead of trying to provide a language that meets each organization\'s unique needs, NIST provided designed OSCAL with the ability to be extended.
+
+As a result, FedRAMP-compliant OSCAL files are a combination of the core OSCAL syntax and extensions defined by FedRAMP. The *Guide to
+OSCAL-Based FedRAMP Content* describes the concepts behind FedRAMP extensions and allowed values. The extensions related to the Security Assessment Plan (SAP) are cited in this document in context of their use.
+
+**FedRAMP extensions and allowed values 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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_
+- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_
+- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_
+{{ }}
+
+Working with OSCAL Files, the SAP communicates the *intended* scope, subject, assets, and activities, and the SAR communicates the actual circumstances of the assessment. The same OSCAL syntax is used for this content in the SAP and SAR.
+
+Assessment tools must enable assessors to duplicate the SAP content and modify it to reflect what actually happened during the assessment, including changes to the schedule, team, and tools used.
+
+Content that is common across OSCAL file types is described in the *[Guide to OSCAL-based FedRAMP Content](/guides/general/).*
+This includes the following:
+
+| Topic | Location |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Title Page** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#title-page)_, Section 4.1_ |
+| **Prepared By/For** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#prepared-by-third-party)_, Section 4.2 - 4.4_ |
+| **Record of Template Changes** | Not Applicable. Instead follow [_Guide to OSCAL-based FedRAMP Content_](/guides/general/2-working-with-oscal-files/#oscal-syntax-version)_, Section 2.3.2, OSCAL Syntax Version_ |
+| **Revision History** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-revision-history)_, Section 4.5_ |
+| **How to Contact Us** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#how-to-contact-us)_, Section 4.6_ |
+| **Document Approvers** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-approvals)_, Section 4.7_ |
+| **Acronyms and Glossary** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#fedramp-standard-attachments-acronyms-lawsregulations)_, Section 4.8_ |
+| **Laws, Regulations, Standards and Guidance** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#additional-laws-regulations-standards-or-guidance)_, Section 4.9_ |
+| **Attachments and Citations** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#attachments-and-embedded-content)_, Section 4.10_
+
+It is not necessary to represent the following sections of the SAR template in OSCAL; however, tools should present users with this content where it is appropriate:
+
+- Any blue-text instructions found in the SSP template, where the instructions are related to the content itself.
+- Table of Contents
+- Introductory and instructive content in each section
+- SAR Section 4.3, Consideration of Threats
+- SAR Section 4.4, Document Results
+
+The Annual SAR was used, which includes all information typically found in the Initial SAR, plus a scope section that is unique to annual assessments. OSCAL always requires a scope. For initial assessments, the scope is all controls. For annual assessments, it is the controls required by FedRAMP.
+
+**The following pages are intended to be printed landscape on tabloid (11\" x 17\") paper.**
+
+---
+## 4.1. One Result Assembly for the Entire Assessment
+
+All results from the current assessment, such as observations, findings, and risks, must be in a single result assembly. Additional result assemblies are used for past assessment results. One result assembly for each past assessment results. This is covered in more detail in *Section 3.2.4, Previous Assessment Results*.
+
+Tool developers must use the start field for each result assembly to determine the most recent set of results present in the SAR.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ 2022 Annual Assessment
+ Brief assessment description.
2022-03-01T00:00:00Z
+ 2022-03-12T00:00:00Z
+
+
+
+
+
+
+ 2021 Annual Assessment
+ Brief assessment description.
2021-02-01T00:00:00Z
+ 2021-02-12T00:00:00Z
+
+
+
+
+ 2020 Initial Assessment
+ Brief assessment description.
2020-01-01T00:00:00Z
+ 2020-01-12T00:00:00Z
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) Quantity of assessment cycles present in file:
+ count(/*/result)
+(SAR) Start date/time of first assessment cycle results in file:
+ /*/result/start[1]
+
+{{}}
+
+**NOTES:** The start and end fields are [dateTime-with-timezone](https://pages.nist.gov/OSCAL/documentation/schema/datatypes/#datetime-with-timezone). For FedRAMP initial and annual assessments, the time portion of this field may be all zeros as shown in the
+representation above.
+
+---
+## 4.2. Test Case Workbook: Assessment Objectives and Methods
+
+There should be one finding assembly for each row in the Excel-based FedRAMP TCW. Tools must identify the appropriate FedRAMP baseline as described in Section 2.1 of the Guide to OSCAL-based FedRAMP Content.
+
+Within the OSCAL-based FedRAMP baselines, control statements and control objectives are tagged with a response-point FedRAMP Extension. For each **in-scope** control, every control objective designated as a response-point in the baseline must have a finding assembly in the result assembly of the SAR.
+
+When using a **FedRAMP Resolved Profile Catalog**, the following query will identify the response points for a given control.
+
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(Baseline) Response Points for AC-1:
+ //control[@id='ac-1']/part[@name='objective']//prop[@name='response-point'] [@ns='https://fedramp.gov/ns/oscal']/../@id
+
+(Baseline) Response Points for AC Family:
+ //group[@id='ac']/control/part[@name='objective']//prop[@name='response-point'] [@ns='https://fedramp.gov/ns/oscal']/../@id
+(Baseline) Response Points for entire baseline:
+ //control/part[@name='objective']//prop[@name='response-point'] [@ns='https://fedramp.gov/ns/oscal']/../@id
+
+{{}}
+
+{{}}
+**HELPFUL HINTS**
+
+Use the appropriate FedRAMP resolved profile catalog, instead of the profile. This has the catalog content pre-merged, saving your tool the extra work of stepping through the profile to the catalog.
+
+When processing an OSCAL-based FedRAMP baseline (profile or resolved-profile-catalog), each FedRAMP Test Case Workbook objective has a corresponding part named "assessment-objective" and part(s) named "assessment-method". The "assessment-method" parts have "method" properties specifying applicable assessment method (EXAMINE, INTERVIEW, TEST).
+{{ }}
+
+---
+## 4.3. Test Case Workbook: Findings and Objective Status
+
+There must be exactly one finding assembly for each required control objective as determined in the previous section. This is equivalent to having exactly one finding assembly for each in-scope row of the Excel-based FedRAMP TCW.
+
+The target assembly identifies which objective is being addressed by the assessor. It also holds the Implementation Status and Assessment Results fields.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=21-22 39-40" >}}
+
+
+
+
+
+
+
+
+
+
+
+ [EXAMPLE]TCW Objective AC-1(a)(1)[1] <em>(Examine)</em>
+ Statement about satisfaction of this objective.
+
+
+
+
+ satisfied
+
+
+
+
+ [EXAMPLE]TCW Objective AC-1(a)(1)[2] <em>(Examine)</em>
+ Statement about satisfaction of this objective.
+
+
+
+
+ satisfied
+
+
+
+
+
+{{}}
+
+
+{{}}
+**Accepted Values**
+- The implementation-status fields must have the @ns flag with a value of https://fedramp.gov
+- The implementation-status field may only have one of the following values, which match the SSP accepted values:
+ - implemented, partial, planned, alternative, not-applicable
+- The status field may only have one of the following values:
+ - satisfied, not-satisfied
+- The reason flag on the status field may only have one of the following values:
+ - pass, fail, other
+{{ }}
+
+The assessors who gathered the evidence are identified at the bottom of the finding assembly using the actor-uuid attribute of the origin actor fields. The assessment team is defined as a party in the SAP metadata. If the assessor was not listed in the SAP, add a party to the SAR metadata for the assessor. In either case, a tool should list the UUID here, and should search both the SAP and SAR for the UUID when using this data.
+
+**See the next page for XPath Queries.**
+
+
+
+
+
+The following assumes, the first result assembly contains the current assessment, as determined in *Section 4.1, One Result Assembly for the Entire Assessment*.
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+(SAR) Implementation Status:
+ /*/result[1]/finding/target[@type='objective-id'][@target-id='ac-1.a.1_obj.1'] /prop[@name='implementation-status'][@ns='https://fedramp.gov/ns/oscal']
+(SAR) Assessment Result:
+ /*/result[1]/finding/target[@type='objective-id'][@target-id='ac-1.a.1_obj.1'] /status
+(SAR) Quantity of Assessor POC's cited for this objective (integer):
+ count(/*/result[1]/finding[./target[@type='objective-id'][@target-id='ac-1.a.1_obj.1'] ]/origin/actor[@type='party'])
+(SAR) UUID of the First Assessor POC cited for this objective:
+ /*/result[1]/finding[./target[@type='objective-id'][@target-id='ac-1.a.1_obj.1'] ]/origin/actor[@type='party'][1]/@actor-uuid
+NOTE: Search the SAP and SAR metadata for the party referenced by the UUID.
+
+{{}}
+
+---
+## 4.4. Test Case Workbook: Observations and Evidence
+
+The historic TCW spreadsheet only provided the assessor one cell for each Assessment Procedure to capture all observations and evidence.
+
+
+
+
+
+OSCAL enables observations to be broken down into more granular detail, which further enables machine processing.
+
+While each assessment procedure must have exactly one finding assembly, within the finding assembly there must be one or more observation assemblies. There should be at least one observation for each assessment method. For example, if an assessment procedure has an EXAMINE method, there should be at least two observations, including at least one for TEST and at least one for EXAMINE. There may be more. Each observation should include the following:
+
+|**Goal**|**Field and Information**|
+| :-- | :-- |
+|**Action**: How was this assessed?|**method (=\"EXAMINE\", \"INTERVIEW\", \"TEST\")**|
+|**Categorize**|**type \[=\"control-objective\"\]**|
+|**Actor**: Who performed this action?|**assessor**|
+|**Subject**: Who was interviewed?|**subject \[type=\"party\"\]**|
+|**Subject**: What was tested/inspected?|**subject \[type=\"component\", \"inventory-item\", \"resource\" (Artifact)\]**|
+|**How**: What was used?|**reference \[type=\"tool\" or \"method\"\]**|
+|**Evidence**: What evidence supports this?|**relevant-evidence \[type=\'observation\'\]**|
+
+**The following pages contain specific examples of Observations and Evidence.**
+
+---
+### 4.4.1. TCW - Observations and Evidence: Examine
+
+In the example below, the Access Control Policy was examined and found to be fully compliant. The title is discretionary.
+
+The description describes the observation and may include opinions.
+
+The method is set to \"EXAMINE\" indicating this is in response to the EXAMINE activities prescribed for this objective.
+
+The type must be \"control-objective\" for all TCW Observations and Evidence content.
+
+The origin/actor field points to an individual identified as a party in the metadata assembly of either the SAP or SAR.
+
+The origin/related-task points to the task in the SAP schedule (or locally defined task), which describes the review of documentation.
+
+The subject cites the policy that was reviewed. While OSCAL would allow the UUID to point to the policy attached to the SSP, FedRAMP requires assessors directly attach the artifacts and evidence to the SAR. Therefore, this should typically point to a resource in the SAR.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=8" >}}
+
+
+
+ [EXAMPLE]Examine AC Policy
+
+ [EXAMPLE]The AC policy existed, and had all the required elements.
+
+ EXAMINE
+ control-objective
+
+
+
+ Reviewed Policy
+
+ If the policy is defined in the SSP as a component.
+
+
+ Reviewed Policy
If the policy is not an SSP component.
+ 2020-10-10T00:00:00Z
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+
+{{}}
+**Accepted Values**
+
+For TWC, Observations and Evidence, the type field must be set to:
+- control-objective
+
+The method field may be set to one of the following:
+- EXAMINE, INTERVIEW, or TEST
+
+The type flag of the subject field may be set to one of the following:
+- component, inventory-item, location, party, or user
+
+The type flag of the origin/actor field may be set to one of the following:
+- tool, party, assessment-platform
+
+{{ }}
+
+Finally, the relevant-evidence assembly is used to reference evidence. It has an optional href flag that is used to reference a backmatter resource. Alternatively, the relevant-evidence assembly has a child link field then can also be used to reference a backmatter resource. Either approach is acceptable, however if both relevant-evidence/@href and relevant-evidence/link/@href are specified, the link is assumed to be the definitive reference. The previous example demonstrates using link to point back to an examined policy document.
+
+---
+### 4.4.2. TCW - Observations and Evidence: Interview
+
+In the example below, the Access Control Policy was examined and found to be fully compliant. The title is discretionary.
+
+The description describes the observation, and may include opinions.
+
+The method is set to \"INTERVIEW\" indicating this is in response to the INTERVIEW activities prescribed for this objective.
+
+The type must be \"control-objective\" for all TCW Observations and Evidence content.
+
+The origin/actor field points to an individual identified as a party in the metadata assembly of either the SAP or SAR.
+
+The origin/related-task points to the task in the SAP schedule (or locally defined in the SAR), which describes the interviewing of staff.
+
+The subject points to the person interviewed, who may be listed in the SSP, SAP, or SAR.
+
+Finally, the relevant-evidence must be used to point to the attached interview notes as a URI fragment, and to provide detail as to where the relevant statements are in the notes. While OSCAL will allow a relative external link in the href flag, FedRAMP requires each piece of evidence to be listed as a resource in the SAR back matter.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=12" >}}
+
+
+
+
+
+
+
+ [EXAMPLE]AC Policy Interview
+
+ [EXAMPLE]The person interviewed knew about the policy and where to find it.
+
+ INTERVIEW
+ control-objective
+
+
+
+ Interviewed Person
+
+
+ describe the evidence.
+ 2020-10-10T00:00:00Z
+
+
+
+
+
+
+
+
+{{}}
+
+
+{{}}
+**Accepted Values**
+
+For TWC, Observations and Evidence, the type field must be set to:
+- control-objective
+
+The method field may be set to one of the following:
+- EXAMINE, INTERVIEW, or TEST
+
+The type flag of the subject field may be set to one of the following:
+- component, inventory-item, location, party, or user
+
+The type flag of the origin/actor field may be set to one of the following:
+- tool, party, assessment-platform
+
+{{ }}
+
+---
+### 4.4.3. TCW - Observations and Evidence: Evidence and Artifacts
+
+All artifacts reviewed and all evidence collected must be attached (by relative URI path or embedded Base64) as a resource in the back-matter. See *Section 2.6, Citations, Attachments, and Embedded Content in OSCAL Files *for more information.
+
+Evidence must have the \"type\" property with the value set to \"evidence\".
+
+Reviewed Artifacts must have the \"type\" property with the value set to \"artifact\".
+
+Additional type fields may also be added with values such as plan, policy, or image. This adds clarity and can ensure specific tables are generated properly.
+
+Artifacts and evidence may be cited from an observation as relative-evidence.
+
+A SAR tool could use either an rlink or base64 field here, and may use both. If both are present, FedRAMP tools will give preference to the base64 content. If an rlink is used, its href should have a relative path to ensure the path remains valid when the OSCAL content is delivered to FedRAMP.
+
+Tools may include multiple rlink fields within the same resource assembly. This may be useful if the assessor wanted to maintain an
+absolute link to the file\'s authoritative source location as well as a relative link suitable for delivery to FedRAMP.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=12" >}}
+
+
+
+ [EXAMPLE]Interview Notes
+ 00000000
+
+
+
+ [EXAMPLE]AC Policy
+ 00000000
+
+
+
+ [EXAMPLE]Screen Shot
+ 00000000
+
+
+
+{{}}
+
+---
+### 4.4.4. TCW - Observations and Evidence: Queries
+
+{width="7.812482502187226in"
+height="4.5633989501312335in"}The following assumes, the first result assembly contains the current assessment, as determined in *Section 4.1, One Result Assembly for the Entire Assessment*.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+(SAR) Quantity of observations for this objective (integer):
+ count(/*/result[1]/finding[./target[@type='objective-id'][@target-id='ac-1.a.1_obj.1']]/related-observation)
+(SAR) The second observation for this objective:
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/description/node()
+(SAR) SOURCE: Type of source cited (first finding, first, observation, first source):
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/origin/actor/@type
+(SAR) SOURCE: UUID of source cited (first finding, first, observation, first source):
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/origin/actor/@actor-uuid
+(SAR) SUBJECT: Type of subject cited, such as interviewed people or examined/tested system components:
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/subject/@type
+(SAR) SUBJECT: UUID of subject cited, such as interviewed people, examined/tested system components, or reviewed artifacts:
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/subject/@actor-uuid
+(SAR) EVIDENCE: Description of the first piece of evidence for the second observation:
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/relevant-evidence/description/node()
+(SAR) EVIDENCE: The URI pointing to the evidence. For FedRAMP, the value should always be a URI fragment (starting with a '#' pointing to a back-matter resource):
+ /*/result[1]/observation[@uuid=/*/result[1]/finding[./target[@type='objective-id'][@ target-id='ac-1.a.1_obj.1']]/related-observation[1]/@observation-uuid]/relevant-evidence/link/@href
+(SAR) EVIDENCE: The back-matter resource containing the evidence (strip leading '#'):
+ /*/back-matter/resource[@uuid='65fb91b1-f7dc-46bf-8b99-bd98f1a5293d']/rlink/@href
+(SAR) EVIDENCE: The back-matter resource containing the evidence (strip leading '#'):
+ /*/back-matter/resource[@uuid='65fb91b1-f7dc-46bf-8b99-bd98f1a5293d']/base64
+
+{{}}
+
+
+{{}}
+**UUID References**
+
+OSCAL is designed around traceability, which means information is often referenced in its original location rather than duplicated into another file. As a result, it may be necessary to search the SSP, SAP, and/or SAR for a referenced UUID. To optimize tool searches, be aware of where to search for information based on a provided UUID.
+
+For example, the subject-uuid value identified by subject may be found in the SSP, SAP, or SAR, but mostly likely the SSP. For this reason, it may make sense to always search the SSP first, SAP second, and SAR last.
+Conversely, everything cited by related-evidence must appear in the SAR, so only the SAR should
+be searched.
+
+Other UUID references, such as party-uuid, will sometimes only be found in the SAR, sometimes the
+SAP or SAR, and sometimes possibly all three depending on the context.
+{{ }}
+
+---
+
+### 4.4.5. Historic Test Case Workbook: Observations and Evidence
+
+When converting Historic Test Case Workbook content to OSCAL, many details broken down in a way that fits OSCAL. While refactoring legacy data to fit OSCAL is ideal and encouraged, it is not required for historic information.
+
+
+
+There must still be one finding assembly for each row of the Test Case Workbook.
+
+If no date or time is available for an individual row, use the result assembly\'s start field value.
+
+Provide a single observation assembly in each finding and put the entire TCW entry in the description field.
+
+Finally, set the observation/method to \"MIXED\" and the observation/type to \"historic\".
+
+The Implementation Status, Assessment Results, and Assessor POC are handled the same as described in sections 4.3 -- 4.4.4.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=7" >}}
+
+ Initial (2018) Assessment
+ 2022-03-01T00:00:00Z
+ 2022-03-12T00:00:00Z
+
+
+ Observations and Evidence
+
+ Contents of the Observations and Evidence cell in the TCW.
+
+ MIXED
+ historic
+
+
+ 2022-03-01T00:00:00Z
+
+
+
+
+ AC-1.1.1.3
+
+ satisfied
+
+
+
+
+
+
+{{}}
+
+---
+## 4.5. Test Case Workbook: SSP Implementation Statement Differential
+
+If an SSP Implementation Statement Differential is identified, add an additional observation with a type
+value of \"ssp-statement-issue\" and cite this observation from finding assembly. The finding assembly should also include the
+implementation-statement-uuid field with the UUID of the original statement in the SSP.
+
+If this was an issue where an inventory-item or component was not configured as described in the SSP, the related observation should
+include the relevant inventory-item or component should be cited as subjects.
+
+
+
+
+{{}}
+**Accepted Values**
+
+For TWC, SSP Implementation Statement Differential, the type field must be set to:
+- ssp-statement-issue
+
+The observation method field must be set to:
+- EXAMINE
+
+If the subject field is present, the type flag may be set to one of the following:
+- component, inventory-item, location, party, or user
+
+The type flag of the origin/actor field may be set to one of the following:
+- tool, part, or assessment-platform
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=6" >}}
+
+
+
+ Policy describes procedure, which could not be found.
EXAMINE
+ ssp-statement-issue
+
+
+ 2022-10-10T00:00:00Z
+
+
+
+ [EXAMPLE]Issue With AU-1 Statement
+ [EXAMPLE]There is an issue with an SSP Statement.
+
+ 7924db51-e44d-4215-ad7e-3a5dda44a631
+
+
+
+{{}}
+
+The following assumes, the first result assembly contains the current assessment, as determined in *Section 4.1, One Result Assembly for the Entire Assessment*.
+
+{{< highlight xml "linenos=table" >}}
+(SAR) Quantity of SSP implementation statement differential issues cited in current assessment (integer):
+ count(/*/result[1]/observation/type[.='ssp-statement-issue'] )
+(SAR) List of SSP implementation statement differential issues cited in current assessment (by SSP Statement UUID):
+ /*/result[1]/finding[./related-observation[@observation-uuid=/*/result[1]/observation[./type[.='ssp-statement-issue']]/@uuid]]/implementation-statement-uuid
+(SAR) The description of the first deficiency:
+ /*/result[1]/observation[./type[.='ssp-statement-issue']]/description/node()
+
+{{}}
+
+---
+## 4.6. Test Case Workbook: Identified Risks
+
+For any finding with a finding/target/status value of \"not-satisfied\", there must be at least one associated-risk field within the finding assembly, pointing to a risk assembly.
+
+Within the cited risk assembly, the \"Identified Risk\" is described in the description field. The Risk Statement is described in the risk-statement field.
+
+The Likelihood Level and Impact Level are each entered in a characterization/facet field. The FedRAMP Risk Exposure Level must be calculated by the SAR tool. If the \"state\" annotation is missing, it is assumed to be \"initial\".
+
+Initially, the status field should always be set to \"open\". If the risk is addressed by the CSP and verified by the assessor before assessment activities are complete, this may be set to \"closed\", and entry must be made in the risk-log.
+
+
+
+
+{{}}
+**Accepted Values**
+- The risk status field should always be set to "open" when a risk content is first created.
+- The facet likelihood and impact fields must each have one of the following values:
+ - low
+ - moderate
+ - high
+- The risk exposure rating is calculated, consistent with Annual SAR Table 3-6, Risk Exposure Rating
+
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=2-23" >}}
+
+
+ Risk Title
+
+ This is a general description of the identified risk.
+
+
+ This is a statement about the identified risk in the context of this system.
+
+ open
+
+
+
+
+
+
+
+
+
+
+
+
+ [EXAMPLE]TCW Objective AC-1(a)(1)[1] (Examine)
+ cut.
+ not-satisfied
+
+
+
+
+{{}}
+
+### 4.6.1. Test Case Workbook: Recommendation for Mitigation
+
+For the risk assembly, there must be a response assembly containing the assessors recommended mitigation.
+The lifecycle flag must be set to \"recommendation\".
+
+There may be more than one response assembly. For example, a tool may provide a recommended remediation, and the assessor may want to add their own recommendation. This would result in two response assemblies.
+
+Later, any SAR remediation recommendations may be transferred to the POA&M using this syntax, and the CSP will add yet another response assembly with their actual plan for remediation.
+
+If the risk is closed during testing, there must be an additional response-assembly with a lifecycle value of \"completed\".
+
+The assessor\'s recommendation should appear in the description field.
+
+The response origin field\'s type flag should be set to \"party\", and the actor-uuid should contain the UUID of either the assessment organization itself or the individual assessor making the recommendation.
+
+
+
+
+{{}}
+**Accepted Values**
+- The lifecycle flag on the response field must be set to:
+ - recommendation
+- The type flag on the response origin field:
+ - party
+ - tool
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=22-37" >}}
+
+
+ Risk Title
+
+ This is a description of the identified risk.
+
+
+ This is a statement about the identified risk.
+
+ open
+
+
+
+
+
+
+
+
+
+
+ Remediation Title
+
+ A description of the recommended remediation.
+ TCW: Assessor's recommended remediation
+ (lifecycle='recommendation').
+
+
+
+
+
+
+
+
+{{}}
+
+---
+## 4.7. Automated Tools
+
+Automated scanning tool output is simply another finding; however, the target is typically not present.
+
+FedRAMP requires exactly one finding assembly for each unique vulnerability identified by the scanning tool. Within this finding assembly, there must be exactly one observation assembly. The collected field must be set to the automation tool\'s discovery timestamp.
+
+Within the observation assembly, the observation method field must be set to \"TEST\", and the observation type field must be set to
+\"finding\".
+
+The actor-uuid flag of the origin field must identify the automated tool\'s UUID, and the type flag must be set to \"tool\". The scanning tool should have been previously defined in the SAP\'s assessment-assets assembly and copied to the SAR. If not, the
+scanning tool should be added to the SAR results local-definitions/assessment-assets assembly as described in the [*Guide to OSCAL-based Security Assessment Plans (SAP)*](/guides/sap/4-sap-template-to-oscal-mapping/#testing-performed-using-automated-tools), *Section 4.13, SAP Test Plan: Testing Performed Using Automated Tools*.
+
+The href flag in the relevant-evidence field must contain a URI fragment that points to the resource containing the raw tool output attached in the back-matter.
+
+At the end of the finding assembly, the UUID for the tool operator must be listed as the actor-uuid for the finding. There may be more than one.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=6" >}}
+
+
+
+ Undocumented devices found on network.
+
+ TEST
+ finding
+
+
+
+
+ Raw scanner tool output - discovery scan.
+
+
+ 2022-10-10T00:00:00Z
+
+ Undocumented hosts are entered into the SAR's local-definitions.
+
+
+
+ Discovery Scan Results
+ The results of the discovery scan.
+
+
+
+
+{{}}
+
+### 4.7.1. Automated Tools: Discovery Scans
+
+Any undocumented devices identified by the discovery scans must be added to the SAR\'s local-definitions assembly as either inventory-items or components, as described in the [*Guide to OSCAL-based Security Assessment Plans (SAP)*](/guides/sap/4-sap-template-to-oscal-mapping/#ip-addresses-slated-for-testing), *Section 4.5, SAP IP Addresses Slated for Testing*.
+
+This should include information such as IP address, host name, and OS, as well as any other details typically reported for an undocumented host. All component and inventory-item syntax from the SSP is available here. Each undocumented device should then be listed as an individual subject reference.
+
+If the assessor believes any of the undocumented devices represent a risk, the risk assembly may be added with the appropriate information; however, it is not automatically required for discovery scans.
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=14-16" >}}
+
+
+
+
+ Undocumented devices found on network.
+
+ TEST
+ finding
+
+
+
+
+ Raw scanner tool output - discovery scan.
+
+
+ 2022-10-10T00:00:00Z
+
+ Undocumented hosts are entered into the SAR's result/local-definitions section as inventory-items or components.
+ Undocumented hosts are listed in the observations assembly as subjects.
+ The origin must contain the UUID of the tool used to perform the scan.
+
+
+
+
+ Discovery Scan Results
+ The results of the discovery scan.
+
+
+{{}}
+
+#### 4.7.2. Automated Tools: Identified Vulnerabilities
+
+There must be one risk assembly for each unique vulnerability. All devices identified as having that unique vulnerability must be itemized with subject fields in the observation assemblies.
+
+The individual components and inventory-items on which the scans are performed should already be marked as to whether authenticated scanning is possible.
+
+All components and inventory-items found to have the vulnerability must be cited using their UUID in the subject field. One subject for each item.
+
+The uuid flag of the origin field must be set to the tool\'s UUID, and the type flag must be set to \"tool\".
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=14-16" >}}
+
+
+ Risk Title
+
+ This is a description of the identified risk.
+
+ Scans: Vulnerability Description.
+
+
+
+
+
+ This is a statement about the identified risk.
+
+ Scans: N/A.
+
+
+
+ open
+
+
+
+
+
+
+
+
+
+
+
+ Remediation Title
+
+ A description of the recommended remediation.
+
+ Scans: Tool's recommended remediation (type='recommendation')
+
+
+
+
+
+
+
+
+
+{{}}
+
+**See next page for risk assembly**
+
+The risk assembly uses facet fields to capture relevant tool output details. The facet field's system flag allows data from different tools and different security frameworks to co-exist in the same file.
+
+FedRAMP required risk-metric data, such as likelihood and impact are specified with facet fields with system flag value of \"https://fedramp.gov\". FedRAMP required risk metrics must also have the class flag set to either \"initial\" or \"residual\". There must
+always be an initial risk metric. If adjusted, there may be a residual risk metric as well.
+
+The uuid flag of the origin field must be set to the tool\'s UUID, and the type flag must be set to \"tool\".
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Vulnerability Title
+
+ This is a description of the vulnerability provided by the tool.
+
+
+ This is a statement about the identified risk as provided by the tool.
+
+ open
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+For information about the remediation assembly, see *Section 4.6.1, Test Case Workbook: Recommendation for Mitigation*.
+
+---
+## 4.8. Penetration Testing: Findings
+
+FedRAMP requires exactly one finding assembly for each risk identified through penetration testing. Required reporting, such as spear phishing tests, each must have their own finding assembly as well. Each finding has a related-observation referencing observation (where additional details are recorded) via the uuid flag. At the end of the finding assembly, the UUID for the penetration test lead or team member must be listed as the actor-uuid for the finding. Note that there may be more than one penetration test member listed.
+
+The observation assembly contains the method field which must be set to \"TEST\", and the type field which must be set to \"finding\". The observation assembly also contains the collected field which must be set to the automation tool\'s discovery timestamp, or the date and time observed. The assessors who gathered the evidence are identified at the bottom of the finding assembly using actor-uuid fields.
+
+The href flag in the relevant-evidence field must contain a URI fragment that points to the resource containing the penetration testing report. Section 4.4.3 describes how to reference evidence resources. The back-matter resource containing the penetration test must also have a prop with a name of \"type\" and with a value of \" report\".
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Penetration Testing
TEST
+ finding
+
+
+
+
+ 2022-10-10T00:00:00Z
+
+
+
+ [EXAMPLE]Penetration Test Result
+ A finding from penetration testing activities.
+
+
+ If a penetration test result is favorable, such as to say the SOC detected the activities appropriately, no risk is required.
+ If a penetration test result identifies a vulnerability or deficiency, the risk assembly is required.
+
+
+
+
+
+
+
+
+{{}}
+
+---
+## 4.9. Penetration Testing: Identified Risks
+
+Some penetration test results may be reportable even if they do not represent a risk. For example, the spear phishing test results must be reported regardless; however, those results only generate a risk if the click rate exceeds a certain threshold. Where a risk must be reported, the risk assembly is added beneath the observation.
+
+For penetration testing, there must be one finding assembly per observation or observation/risk pair.
+
+The risk assembly is populated as described in previous sections.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ Risk Title
+
+ This is a description of the issue found by the penetration testing team.
+
+
+ Statement about the risk identified by penetration testing.
+
+ open
+
+
+
+
+
+
+
+
+
+ Assessor's Recommendation
+
+ A description of the recommended remediation as provided by the assessor.
+
+
+
+
+ The assessor may add their recommendation.
+
+
+
+
+
+
+
+{{}}
+
+---
+## 4.10. Deviations
+
+After risks are identified during an assessment, their status may change. Some are identified as false positive
+(FP), operationally required (OR), or risk adjusted (RA). As deviations arise, the initial risk information is [not]{.underline} modified. Additional content is added to identify these changes. In each case, an additional observation is added to the finding assembly, and additional facet fields are added to the risk assembly. There may be both OR and an RA information in the same finding assembly.
+
+### 4.10.1. False Positive (FP)
+
+To document a false positive, add a prop to the risk assembly, and change the risk status to \"closed\". Set the prop name to
+\"false-positive\", the ns to \"https://fedramp.gov/ns/oscal\", and the value to \"pending\".
+
+Within the observation assembly, provide a description of the false positive. This must have a conformity tag with a value of \"false-positive\". Typically, the observation method is set to EXAMINE; however, another method may be identified if more
+appropriate.
+
+Finally, add a separate relevant-evidence assembly for each piece of evidence supporting the FP. Attached evidence, such as screen shots, must be defined as a resource in the back-matter, and cited using a URI fragment (hashtag, followed by the UUID of the
+resource.)
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ False Positive
+ False positive justification.
EXAMINE
+ false-positive
+
+
+
+ A screen shot showing the setting is correct
+
+
+
+
+ Vendor detail describing why this happens.
+
+
+
+
+
+ closed
+
+
+
+{{}}
+
+
+{{}}
+FedRAMP allowed values for false-positive prop:
+- investigating
+- pending
+- approved
+- withdrawn
+
+{{ }}
+
+### 4.10.2. Operationally Required (OR)
+
+To document an operationally required risk, add a prop to the risk assembly, and keep the risk status as \"open\". Set the prop name to \" operational-requirement \", the ns to \"https://fedramp.gov/ns/oscal\", and the value to \"pending\".
+
+Within the observation assembly, provide a justification for the operational requirement. This must have a conformity tag with a value of \"operational-requirement\". Typically, the observation method is set to EXAMINE; however, another method may be identified if more appropriate.
+
+Finally, add a separate relevant-evidence assembly for each piece of evidence supporting the FP. Attached evidence, such as screen shots, must be defined as a resource in the back-matter, and cited using a URI fragment (hashtag, followed by the UUID of the resource.)
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Operational Requirement
+ Justification for the OR.
EXAMINE
+ operational-requirement
+
+
+
+ Screen shot showing impact when patched.
+
+
+
+
+
+ Vendor detail describing why this happens.
+
+
+
+
+
+
+ open
+
+
+
+{{}}
+
+
+{{}}
+FedRAMP allowed values for operational-requirement prop:
+- investigating
+- pending
+- approved
+- withdrawn
+
+{{ }}
+
+### 4.10.3. Risk Adjustment (RA)
+
+To document an operationally required risk, add a prop to the risk assembly and keep the risk status as \"open\". Set the prop name to
+\"risk-adjustment\", the ns to \"https://fedramp.gov/ns/oscal\", and the value to \"pending\".
+
+Within the observation assembly, provide a justification for the risk adjustment. This must have a conformity tag with a value of
+\"risk-adjustment\". Typically, the observation method is set to EXAMINE; however, another method may be identified if more appropriate.
+
+Use facet fields to adjust risk by lowering either likelihood, impact, or both. Within the facet fields, set a prop with the name "state" to indicate whether this is an "initial" or "adjusted" risk metric.
+
+Finally, mitigating-factor assemblies. One describing each mitigating factor. If an SSP implementation statement describes the mitigating factor, link to it using the implementation-uuid flag.
+
+{{}}
+**Using the Common Vulnerability Scoring System (CVSS)**
+
+When using CVSS scoring to justify a risk adjustment, the CVSS metrics are added as additional risk-metric fields. There must be one risk-metric field for each CVSS metric.
+
+``` network ```
+
+See Appendix A, CVSS Scoring for more information.
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ Risk Adjustment
+ Justify the risk.
EXAMINE
+ risk-adjustment
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ open
+
+
+
+{{}}
+
+
+{{}}
+FedRAMP allowed values for risk-adjustment prop:
+- investigating
+- pending
+- approved
+- withdrawn
+
+{{ }}
+
+---
+## 4.11. Risk Closure
+
+Once identified, risks must remain in the SAR; however, if the CSP closes the risk before testing is complete, it may be marked as closed in the SAR. To represent a risk closure, change the risk status to \"closed\", then add an entry field and risk-log assembly, with a status-change value of \"closed \".
+
+In the risk-log , describe the action(s) taken by the CSP to close the risk.
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Vulnerability Title
+ cut
cut
closed
+
+
+ Tool's Recommendation
+
+ A description of the recommended remediation as provided by the tool.
+
+
+
+
+
+ Assessor's Recommendation
+
+ A description of the recommended remediation as provided by the assessor.
+
+
+
+
+
+
+
+ Closed
+
+ Describe what action(s) the CSP took to close the risk.
+ Applied patch. Vulnerability no longer found in subsequent scan.
+
+ 2022-07-07T00:00:00Z
+ closed
+
+
+
+
+
+{{}}
+
+---
+## 4.12. Continued Authorization Recommendation
+
+There must be a prop field with a value indicating whether the assessor recommends the system for authorization or reauthorization. This must be a FedRAMP extension with the name \"recommend-authorization\". If the recommendation is \"no\" or \"provisionally\", the first paragraph of the Continued Authorization Recommendation should be generated by a SAR tool, as follows:
+
+{{}}
+*A total of \[# of risks\] system risks were identified for \[system > name\], including \[#high\] High risks, \[#moderate\] Moderate risks, \[#low\] Low risks, and \[#operationally-required\] of operationally required risks.*
+{{ }}
+
+The \"other information as may be required\" may be added as a part assembly in the assets section.
+
+Each risk may have a priority value assigned to it. This is another FedRAMP extension prop with the name flag set to \"priority\". A
+priority value of \"1\" represents the most important risk. \"2\" represents the second most important risk. Each number should be unique. Do not assign a priority value to a risk that will not be mitigated, such as an operationally required risk.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ [3PAO] attests to the accuracy of the information provided in this FedRAMP Security Assessment Report for the annual assessment
+ of [Information System Name]
+
+
+ This [Information System Name] SAR provides a complete assessment of the applicable FedRAMP controls defined in the SAP.
+ Evidence to validate the successful implementation of the security controls has been collected and validated, and will be made
+ available upon request.
+
+
+ Based on the remaining risk noted in the [Information System Abbreviation] Risk Exposure Table, and the continuous improvement
+ of security related processes and controls, [3PAO Name] [recommends |does not recommend | provisionally recommends]
+ continued authorization be granted for [Information System Name].
+
+
+
+
+
+ Vulnerability Title
+
+ This is a description of the vulnerability provided by the tool.
+
+
+ This is a statement about the identified risk as provided by the tool.
+
+
+
+
+{{}}
diff --git a/docs/content/guides/sar/5-generated-content.md b/docs/content/guides/sar/5-generated-content.md
new file mode 100644
index 000000000..edb81e7e1
--- /dev/null
+++ b/docs/content/guides/sar/5-generated-content.md
@@ -0,0 +1,78 @@
+---
+title: Generated Content
+section: /sar/
+toc:
+ enabled: true
+weight: 104
+---
+
+The following artifacts are historically generated by hand to summarize
+content found in other portions of the FedRAMP SAR. When using OSCAL,
+these artifacts may be generated from content found elsewhere in this
+document. This includes the:
+
+- Executive Summary
+- Purpose
+- Laws, Regulations, Standards, and Guidance
+- Scope
+- Controls to be Assessed
+- System Overview
+- Assessment Methodology
+- Performed Tests
+- Assessment Deviations
+- Risk Exposure Table
+- Risks Corrected During Testing
+- Risks Known for Interconnected Systems
+- Scan Results (Infrastructure, Database, Web Application, Container, Other, and Unauthenticated)
+ - Inventory of Items Scanned
+ - False Positive Report
+- Document Results
+- Manual Test Results
+- Test Case Workbook\'s System Tab
+- Test Case Workbook\'s Control Summary Tab
+
+If delivering SAR content in OSCAL, CSPs are no longer required to manually generate and maintain these artifacts, provided the content in their OSCAL-based FedRAMP SAR remains accurate.
+
+**Tool developers are encouraged to develop their own solutions to generating this content.**
+
+There are many ways a tool developer can generate these artifacts. FedRAMP is developing Extensible Stylesheet Language Transformation
+(XSLT) files to generate these artifacts. When ready, FedRAMP will make this freely available to the public here:
+
+[https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/resources](https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/resources)
+
+###### 
+
+Common Vulnerability Scoring System (CVSS) metrics may be added to any risk assembly using facet fields.
+
+Tools should accept either the upper-case abbreviation or the lower-case name on a field-by-field basis. For example, it should be acceptable to use \"AV\" for access vector, and \"privileges-required\" for privileges required, provided both have a system value of \"http://www.first.org/cvss/v3.1\".
+
+All CVSS metrics must be in the same CVSS version, as identified by the system flag, for successful computation. Tool developers should ensure the tool performs CVSS calculations as defined by the Forum of Incident Response and Security Teams (FIRST) at [https://www.first.org/cvss/](https://www.first.org/cvss/).
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+
+
+{{}}
diff --git a/docs/content/guides/sar/_index.md b/docs/content/guides/sar/_index.md
new file mode 100644
index 000000000..d482dbbba
--- /dev/null
+++ b/docs/content/guides/sar/_index.md
@@ -0,0 +1,31 @@
+---
+title: FedRAMP OSCAL SAR Guide
+heading: FedRAMP OSCAL SAR Guide
+menu:
+ primary:
+ name: SAR
+ parent: Documentation
+ weight: 300
+toc:
+ enabled: true
+---
+
+## 2. FedRAMP Extensions and Allowed Values
+
+NIST designed the core OSCAL syntax to model cybersecurity information
+that is common to most organization and compliance frameworks; however,
+NIST also recognized\ the need to provide flexibility or organizations with unique information
+needs.
+
+Instead of trying to provide a language that meets each\
+organization\'s unique needs, NIST provided designed OSCAL\
+with the ability to be extended.
+
+As a result, FedRAMP-compliant OSCAL files are a combination of the core
+OSCAL syntax and extensions defined by FedRAMP. The [_Guide to OSCAL-Based FedRAMP Content_](/guides/general/)
+describes the concepts behind FedRAMP extensions and allowed values. The
+extensions related to the Security Assessment Plan (SAP) are cited in
+this document in context\
+of their use.
+
+**FedRAMP extensions and allowed values are cited in relevant portions of this document and summarized in the FedRAMP OSCAL Registry.**
diff --git a/docs/content/guides/ssp/3-working-with-oscal-files.md b/docs/content/guides/ssp/3-working-with-oscal-files.md
new file mode 100644
index 000000000..7f1c85c4b
--- /dev/null
+++ b/docs/content/guides/ssp/3-working-with-oscal-files.md
@@ -0,0 +1,164 @@
+---
+title: Working with OSCAL Files
+section: /ssp/
+toc:
+ enabled: true
+weight: 101
+---
+
+This section provides a summary of several important concepts and details that apply to OSCAL-based FedRAMP SSP files.
+
+The [*Guide to OSCAL-based FedRAMP Content*](/guides/general/) provides important concepts necessary for working with any OSCAL-based FedRAMP file. Familiarization with those concepts is important to understanding this guide.
+
+## 3.1. XML and JSON Formats
+
+The examples provided here are in XML; however, FedRAMP accepts XML or JSON formatted OSCAL-based SSP files. NIST offers a utility that provides lossless conversion of OSCAL-compliant files between XML and JSON in either direction.
+
+You may submit your SSP to FedRAMP using either format. If necessary, FedRAMP tools will convert the files for processing.
+
+## 3.2. SSP File Concepts
+
+Unlike the traditional MS Word-based SSP, SAP, and Security Assessment Report (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.
+
+ \
+*Each OSCAL file imports information from the one to the left*
+
+For example, the NIST control definitions and FedRAMP baseline content that normally appears in the SSP are defined in the FedRAMP profile and simply referenced by the SSP.
+
+ \
+*Baseline Information is referenced instead of duplicated.*
+
+For this reason, an OSCAL-based SSP points to the appropriate
+OSCAL-based FedRAMP baseline as determined by the system\'s FIPS-199 impact level. Instead of duplicating control details, the OSCAL-based SSP simply points to the baseline content for information such as control definition statements, FedRAMP-added guidance, parameters, and FedRAMP-required parameter constraints.
+
+### 3.2.1. Resolved Profile Catalogs
+
+The resolved profile catalog for each FedRAMP baseline is a pre-processing of 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.
+
+ \
+*The Resolved Profile Catalog for each FedRAMP Baseline reduces tool processing.*
+
+For more information about resolved profile catalogs, see the [*Guide to OSCAL-based FedRAMP Content*](/guides/general/5-appendices/#profile-resolution) *Appendix, Profile Resolution*.
+
+## 3.3. OSCAL-based FedRAMP SSP Template
+
+FedRAMP offers an OSCAL-based SSP shell file in both XML and JSON formats. This shell contains many of the FedRAMP required standards to help get you started. This document is intended to work in concert with that shell file. The OSCAL-based FedRAMP SSP Template is available in XML and JSON formats here:
+
+- OSCAL-based FedRAMP SSP Template (JSON Format):\
+ [https://github.com/GSA/fedramp-automation/raw/master/dist/rev5/content/rev5/templates/ssp/json/FedRAMP-SSP-OSCAL-Template.json](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/templates/ssp/json/FedRAMP-SSP-OSCAL-Template.json)
+
+- OSCAL-based FedRAMP SSP Template (XML Format):\
+
+
+## 3.4. OSCAL's Minimum File Requirements
+
+Every OSCAL-based FedRAMP SSP file must have a minimum set of required
+fields/assemblies and must follow the OSCAL SSP core syntax found here:
+
+[https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/ssp](https://pages.nist.gov/OSCAL/concepts/layer/implementation/ssp/)
+
+## 3.5. Importing the FedRAMP Baseline
+
+OSCAL is designed for traceability. Because of this, the SSP is designed
+to be linked to the FedRAMP baseline. Rather than duplicating content
+from the baseline, the SSP is intended to reference the baseline content
+itself.
+
+Use the import-profile field to specify an existing OSCAL-based SSP. The
+href flag may include any valid uniform resource identifier (URI),
+including a relative path, absolute path, or URI fragment.
+
+#### SSP Import Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ FedRAMP Moderate Baseline
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SSP) Referenced OSCAL-based FedRAMP Baseline XML:
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/xml']/@href
+ OR JSON:
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/json']/@href
+{{}}
+
+Note: Cloud Service Providers must import [FedRAMP profiles or resolved profile catalogs](https://github.com/GSA/fedramp-automation/tree/master/dist/content/rev5/baselines).
+
+## 3.6. Resolution Resource Prop
+
+FedRAMP will be implementing a separate set of automated SSP validation rules for the rev 5 OSCAL templates. To ensure FedRAMP initiates the appropriate validation rules when processing OSCAL SSPs, SSP authors should add a new prop called "resolution-resource" in the metadata section and include an associated back-matter resource as shown below:
+
+#### SSP Resolution Resource
+{{< highlight xml "linenos=table" >}}
+
+
+ FedRAMP System Security Plan (SSP)
+
+ fedramp2.0.0-oscal1.0.4
+ 1.0.4
+
+
+
+
+
+
+
+
+
+ Resolution Resource
+
+ This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SSP (rev 4 or rev 5) this OSCAL document is for.
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ (SSP) UUID of “resolution-resource”:
+ /*/metadata/prop[@name=”resolution-resource”]/@value
+ (SSP)Target baseline version:
+ /*/back-matter/resource[@uuid=”uuid-of-resolution-resource”]/prop[@name=”dataset” and @class=”version”]/@value
+{{}}
+
+If the "resolution-resource" prop is not specified in the metadata section of the SSP, FedRAMP will assume the SSP should be validated using the rev 5 validation rules. If the "resolution-resource" prop is present, FedRAMP will use the validation rules that correspond with the version specified in the back-matter resource.
diff --git a/docs/content/guides/ssp/4-ssp-template-to-oscal-mapping.md b/docs/content/guides/ssp/4-ssp-template-to-oscal-mapping.md
new file mode 100644
index 000000000..c951fabe8
--- /dev/null
+++ b/docs/content/guides/ssp/4-ssp-template-to-oscal-mapping.md
@@ -0,0 +1,1267 @@
+---
+title: SSP Template to OSCAL Mapping
+section: /ssp/
+toc:
+ enabled: true
+weight: 103
+---
+
+For SSP-specific content, each main section of the SSP is represented in this section, along with OSCAL code snippets for representing the information in OSCAL syntax. There is also XPath syntax for querying the code in an OSCAL-based FedRAMP SSP represented in XML format.
+
+Content that is common across OSCAL file types is described in the *[Guide to OSCAL-based FedRAMP Content](/guides/general/).* This includes the following:
+
+| Topic | Location |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Title Page** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#title-page)_, Section 4.1_ |
+| **Prepared By/For** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#prepared-by-third-party)_, Section 4.2 - 4.4_ |
+| **Record of Template Changes** | Not Applicable. Instead follow [_Guide to OSCAL-based FedRAMP Content_](/guides/general/2-working-with-oscal-files/#oscal-syntax-version)_, Section 2.3.2, OSCAL Syntax Version_ |
+| **Revision History** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-revision-history)_, Section 4.5_ |
+| **How to Contact Us** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#how-to-contact-us)_, Section 4.6_ |
+| **Document Approvers** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#document-approvals)_, Section 4.7_ |
+| **Acronyms and Glossary** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#fedramp-standard-attachments-acronyms-lawsregulations)_, Section 4.8_ |
+| **Laws, Regulations, Standards and Guidance** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#additional-laws-regulations-standards-or-guidance)_, Section 4.9_ |
+| **Attachments and Citations** | [_Guide to OSCAL-based FedRAMP Content_](/guides/general/4-expressing-common-fedramp-template-elements-in-oscal/#attachments-and-embedded-content)_, Section 4.10_ |
+
+It is not necessary to represent the following sections of the SSP template in OSCAL; however, tools should present users with this content where it is appropriate:
+
+- Any blue-text instructions found in the SSP template where the instructions are related to the content itself
+
+- Table of Contents
+
+- Introductory and instructive content in section 1, such as references to the NIST SP 800-60 Guide to Mapping Types and the definitions from FIPS Pub 199.
+
+- The control origination definitions are in appendix A of the SSP template; however, please note hybrid and shared are represented in OSCAL by specifying more than one control origination.
+
+The OSCAL syntax in this guide may be used to represent the High, Moderate, and Low FedRAMP SSP Templates. Simply ensure the correct FedRAMP baseline is referenced using the import-profile statement.
+
+**NOTE: The FedRAMP SSP template screenshots in the sections that follow vary slightly from the most current version of the FedRAMP rev 5 SSP template.**
+
+**The following pages are intended to be printed landscape on tabloid (11\" x 17\") paper.**
+
+
+---
+## 4.1. System Information
+
+### 4.1.1. Cloud Service Provider (CSP) Name
+
+The cloud service provider (CSP) must be provided as one of the party assemblies within the metadata.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=5" >}}
+
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+Cloud Service Provider (CSP) Name:
+ /*/metadata/party[@uuid='uuid-of-csp']/name
+{{}}
+
+---
+### 4.1.2. System Name, Abbreviation, and FedRAMP Unique Identifier
+
+The remainder of the system information is provided in the
+system-characteristics assembly.
+
+The FedRAMP-assigned application number is the unique ID for a FedRAMP system. OSCAL supports several system identifiers, which may be assigned by different organizations.
+
+For this reason, OSCAL requires the identifier-type flag be present and have a value that uniquely identifies the issuing organization. FedRAMP requires its value to be "https://fedramp.gov" for all FedRAMP-issued application numbers.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=9-13" >}}
+
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+
+{{}}
+
+
+{{}}
+
+**FedRAMP Allowed Value**
+
+Required Identifier Type:
+- identifier-type="https://fedramp.gov"
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Information System Name:
+ /*/system-characteristics/system-name
+ Information System Abbreviation:
+ /*/system-characteristics/system-name-short
+ FedRAMP Unique Identifier:
+ /*/system-characteristics/system-id[@identifier-type="https://fedramp.gov"]
+{{}}
+
+---
+### 4.1.3. Service Model
+
+The core-OSCAL system-characteristics assembly has a property for the cloud service model.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=14-19" >}}
+
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+ Remarks are required if service model is "other". Optional otherwise.
+
+
+
+
+
+
+
+{{}}
+
+
+{{}}
+
+**NIST Allowed Values**
+
+Valid Service Model values:
+- saas
+- paas
+- iaas
+- other
+
+{{ }}
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Service Model:
+ /*/system-characteristics/prop[@name="cloud-service-model"]/@value
+ Remarks on System's Service Model:
+ /*/system-characteristics/prop[@name="cloud-service-model"]/remarks/node()
+{{}}
+
+**NOTE:**
+
+- A cloud service provider may define two or more cloud service models for the cloud service offering defined in the system security plan if applicable for customer use (IaaS and PaaS; IaaS and PaaS and SaaS; PaaS and SaaS). Cloud service providers may use a "cloud-service-model" prop for each applicable cloud service model.
+- If the service model is "other", the remarks field is required. Otherwise, it is optional.
+
+---
+### 4.1.4. Deployment Model
+
+The core-OSCAL system-characteristics assembly has a property for the cloud deployment model.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=20-25" >}}
+
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+ Remarks are required if service model is "other". Optional otherwise.
+
+
+
+
+
+ Remarks are required if deployment model is "hybrid". Optional otherwise.
+
+
+
+
+
+
+{{}}
+
+
+{{}}
+
+**FedRAMP Accepted Values**
+- name="cloud-deployment-model"
+
+ Valid: public-cloud, private-cloud, government-only-cloud, hybrid-cloud, other
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Deployment Model:
+ /*/system-characteristics/prop[@name="cloud-deployment-model"]/@value
+ Remarks on System's Deployment Model:
+ /*/system-characteristics/prop[@name="cloud-deployment-model"]/remarks/node()
+{{}}
+
+**NOTE:**
+
+- A cloud service provider may define one and only one cloud deployment model in the system security plan for a cloud service offering.
+
+- OSCAL 1.0.0 permits a cloud-deployment-model of value community-cloud, but FedRAMP does not permit such a deployment model for cloud service offerings and is not permitted for a FedRAMP OSCAL-based system security plan.
+- If the deployment model is \"hybrid\", the remarks field is required. Otherwise, it is optional.
+
+---
+### 4.1.5. Digital Identity Level (DIL) Determination
+
+The digital identity level identified in Table 1.0 is the same as the level in Attachment 3. It is expressed through
+the following core OSCAL properties.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=14-17" >}}
+
+
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+
+
+
+
+{{}}
+
+
+{{}}
+
+**NIST Allowed Values**
+
+Valid IAL, AAL, and FAL values (as defined by NIST 800-63):
+- 1
+- 2
+- 3
+
+{{ }}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Identity Assurance Level:
+ /*/system-characteristics/prop[@name="identity-assurance-level"]/@value
+ Authenticator Assurance Level:
+ /*/system-characteristics/prop[@name="authenticator-assurance-level"]/@value
+ Federation Assurance Level:
+ /*/system-characteristics/prop[@name="federation-assurance-level"]/@value
+{{}}
+
+---
+### 4.1.6. System Sensitivity Level
+
+The privacy system designation in Table 1.0 is the same as in Attachment 4. It is expressed through the following core OSCAL property.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=15-16" >}}
+
+
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+
+
+ fips-199-moderate
+
+
+
+
+
+{{}}
+
+
+{{}}
+
+**OSCAL Allowed Values**
+
+Valid values for security-sensitivity-level:
+- fips-199-low
+- fips-199-moderate
+- fips-199-high
+
+{{ }}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ System Sensitivity Level:
+ /*/system-characteristics/security-sensitivity-level
+{{}}
+
+**NOTES:**
+
+- The identified System Sensitivity Level governs which FedRAMP baseline applies. See Appendix A for more information about importing the appropriate FedRAMP baseline.
+
+---
+### 4.1.7. System Status
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=24" >}}
+
+
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+
+
+ fips-199-moderate
+
+
+
+ Remarks are optional if status/state is "operational".
+ Remarks are required otherwise.
+
+
+
+
+
+{{}}
+
+
+{{}}
+
+**NIST Allowed Values**
+
+FedRAMP only accepts those in bold:
+- **operational**
+- under-development
+- **under-major-modification**
+- disposition
+- **other**
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ System's Operational Status:
+ /*/system-characteristics/status/@state
+ Remarks on System's Operational Status:
+ /*/system-characteristics/status/remarks/node()
+ Fully Operational As Of Date:
+ /*/system-characteristics/prop[@name="fully-operational-date"][@ns="https://fedramp.gov/ns/oscal"]/@value
+{{}}
+
+**NOTE:**
+
+- If the status is "other", the remarks field is required. Otherwise, it is optional.
+
+- While under-development, and disposition are valid OSCAL values, systems with either of these operational status values are not eligible for a FedRAMP Authorization.
+
+---
+### 4.1.8. System Functionality
+
+
+
+#### Representation
+{{< highlight xml "linenos=table, hl_lines=19-24" >}}
+
+
+
+
+
+
+ System's Full Name
+ System's Short Name or Acronym
+
+ F00000000
+
+
+
+
+
+ fips-199-moderate
+
+
+
+
+ Describe the purpose and functions of this system here.
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ System Function or Purpose: First paragraph in description
+ /*/system-characteristics/description/node()
+
+{{}}
+
+---
+## 4.2. Information System Owner
+
+A role with an ID value of \"system-owner\" is required. Use the responsible-party assembly to associate this role with the party assembly containing the System Owner\'s information.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ CSP HQ
+
+ 1234 Some Street
+ Haven
+ ME
+ 00000
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+ [SAMPLE]Person Name 1
+ name@example.com
+ 202-000-0000
+ uuid-of-hq-location
+ uuid-of-csp
+
+
+ uuid-of-person-1
+
+
+{{}}
+
+
+{{}}
+
+**NIST Allowed Values**
+
+Required role ID:
+- system-owner
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ System Owner's Name:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="system-owner"]/party-uuid]]/name
+ NOTE: Replace "name" with "email-address" or "telephone-number" above as needed.
+ System Owner’s Address:
+ /*/metadata/location[@uuid=/*/metadata/party[@uuid=[/*/metadata/responsible-party [@role-id="system-owner"]/party-uuid]]/location-uuid]/address/addr-line
+ NOTE: Replace "addr-line" with "city", "state", or "postal-code" above as needed.
+ System Owner's Title:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="system-owner"]/party-uuid]]/prop[@name='job-title']/@value
+ Company/Organization:
+ /*/metadata/party[@uuid=/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="system-owner"]/party-uuid]]/member-of-organization]/name
+{{}}
+
+**NOTE:**
+
+If no country is provided, FedRAMP tools will assume a US address.
+
+---
+## 4.3. Federal Authorizing Officials
+
+A role with an ID value of "authorizing-official" is required. Use the responsible-party assembly to associate this role with the party assembly containing the Authorizing Official\'s information.
+
+
+
+#### Federal Agency Authorization Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Authorizing Official
+
+
+ Agency Name
+
+
+ [SAMPLE]Person Name 6
+ name@example.com
+ 202-000-0000
+ uuid-of-agency
+
+
+ uuid-of-person-6
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ FedRAMP Authorization Type:
+ /*/system-characteristics/prop[@name="authorization-type"][@ns="https://fedramp.gov/ns/oscal"]/@value
+ Authorizing Official’s Name:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party [@role-id="authorizing-official"]/party-uuid]]/name
+ NOTE: Replace "name" with "email-address" or "telephone-number" above as needed.
+ Authorizing Official’s Title:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party [@role-id="authorizing-official"]/party-uuid]]/prop[@name='job-title']
+ Authorizing Official's Agency:
+ /*/metadata/party[@uuid=/*/metadata/party[@uuid=[/*/metadata/responsible-party [@role-id="authorizing-official"]/party-uuid]]/member-of-organization]/name
+{{}}
+
+**NOTE:**
+
+If the authorization-type field is "fedramp-jab", the responsible-party/party-uuid field must be the uuid value for the FedRAMP JAB.
+
+---
+#### Federal JAB P-ATO Authorization Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Authorizing Official
+ The government executive(s) who authorize this system.
+
+
+
+ FedRAMP: Joint Authorization Board
+ FedRAMP JAB
+
+
+
+ uuid-of-fedramp-jab
+
+
+
+
+
+ fedramp-jab
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Authorizing Official’s Name:
+ //metadata/party[@uuid=[//metadata/responsible-party[@role-id="authorizing-official"]/party-uuid]]/name
+{{}}
+
+
+{{}}
+
+**FedRAMP Extension:**
+
+prop (ns="https://fedramp.gov/ns/oscal")
+- name="authorization-type"
+
+**FedRAMP Allowed Values**
+- fedramp-jab
+- fedramp-agency
+- fedramp-li-saas
+
+**NIST Allowed Value**
+Required Role ID:
+- authorizing-official
+
+{{ }}
+
+
+---
+## 4.4. Assignment of Security Responsibilities
+
+A role with an ID value of information-system-security-officer" is
+required. Use the responsible-party assembly to associate this role with the party assembly containing the Information
+System Security Officer\'s information.
+
+
+
+
+{{}}
+**NOTES ON ADDRESSES**
+
+**Preferred Approach:** When multiple parties share the same address, such as multiple staff members at a company HQ, define the location 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 but 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.
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ System Information System Security Officer (or Equivalent)
+
+
+ CSP HQ
+
+ 1234 Some Street
+ Haven
+ ME
+ 00000
+
+
+
+ Cloud Service Provider (CSP) Name
+
+
+ [SAMPLE]Person Name 10
+ name@org.domain
+ 202-000-0000
+ uuid-of-hq-location
+ uuid-of-csp
+
+
+
+ uuid-of-person-7
+
+
+{{}}
+
+
+{{}}
+
+**NIST Allowed Value**
+Required Role ID:
+- information-system-security-officer
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ ISSO POC Name:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="information-system-security-officer"]/party-uuid]]/name
+ NOTE: Replace "name" with "email-address" or "telephone-number" above as needed.
+ ISSO POC’s Address:
+ /*/metadata/location[@uuid=/*/metadata/party[@uuid=[/*/metadata/responsible-party [@role-id="information-system-security-officer"]/party-uuid]]/location-uuid]/address/addr-line
+ NOTE: Replace "addr-line" with "city", "state", or "postal-code" above as needed.
+ ISSO POC's Title:
+ /*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="information-system-security-officer"]/party-uuid]]/prop[@name='job-title']
+ Company/Organization:
+ /*/metadata/party[@uuid=/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="information-system-security-officer"]/party-uuid]]/member-of-organization]/name
+{{}}
+
+---
+## 4.5. Leveraged FedRAMP-authorized Services
+
+If this system is leveraging the authorization of one or more systems, such as a SaaS running on an IaaS, each leveraged system must be represented within the system-implementation assembly. There must be one leveraged-authorization assembly and one matching component assembly for each leveraged authorization.
+
+The leveraged-authorization assembly includes the leveraged system\'s name, point of contact (POC), and authorization date. The component assembly must be linked to the leveraged-authorization assembly using a property (prop) field with the name leveraged-authorization-uuid and the
+UUID value of its associated leveraged-authorization assembly. The component assembly enables controls to reference it with the by-component responses described in *Section 6.4, Control Implementation Descriptions*. The implementation-point property value must be set to "external".
+
+If the leveraged system owner provides a UUID for their system, such as in an OSCAL-based Inheritance and Responsibility document (similar to a CRM), it should be provided as the inherited-uuid property value.
+
+
+
+
+{{}}
+
+**IMPORTANT FOR LEVERAGED SYSTEMS:**
+
+While a leveraged system has no need to represent content here, its SSP must include special inheritance and responsibility information in the individual controls. See Section 6.4.8, Response: Identifying Inheritable Controls and Customer Responsibilities for more information.
+
+{{ }}
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Example IaaS Provider
+ E.I.P.
+
+
+
+
+
+ Name of Underlying System
+
+ uuid-of-leveraged-system-poc
+ 2015-01-01
+
+
+
+ Name of Leveraged System
+
+ Briefly describe leveraged system.
+
+
+
+{{}}
+
+
+{{}}
+
+The title field must match an existing [FedRAMP authorized Cloud_Service_Provider_Package](https://raw.githubusercontent.com/18F/fedramp-data/master/data/data.json) property value.
+
+A leveraged-system-identifier property must be provided within each leveraged-authorization field. The value of this property must be from the same Cloud Service Provider as identified in the title field.
+
+
+{{ }}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Name of first leveraged system:
+ /*/system-implementation/leveraged-authorization[1]/title
+ Name of first leveraged system CSO service (component):
+ (//*/component/prop[@name="leveraged-authorization-uuid" and @value="uuid-of-leveraged-system"]/parent::component/title)[1]
+ Description of first leveraged system CSO service (component):
+ (//*/component/prop[@name="leveraged-authorization-uuid" and @value="uuid-of-leveraged-system"]/parent::component/description)[1]
+ Authorization type of first leveraged system:
+ /system-security-plan/system-implementation[1]/leveraged-authorization[1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="authorization-type"]/@value
+ FedRAMP package ID# of the first leveraged system:
+ /system-security-plan/system-implementation[1]/leveraged-authorization[1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="leveraged-system-identifier"]/@value
+ Nature of Agreement for first leveraged system:
+ (//*/component/prop[@name="leveraged-authorization-uuid" and @value="uuid-of-leveraged-system"]/parent::component/prop[@ns="https://fedramp.gov/ns/oscal" and @name="nature-of-agreement"]/@value)[1]
+ FedRAMP impact level of the first leveraged system:
+ /system-security-plan/system-implementation[1]/leveraged-authorization[1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="impact-level"]/@value
+ Data Types transmitted to, stored or processed by the first leveraged system CSO:
+ (//*/component/prop[@name="leveraged-authorization-uuid" and @value="uuid-of-leveraged-system"]/parent::component/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-data-type"]/@value)
+ Authorized Users of the first leveraged system CSO:
+ //system-security-plan/system-implementation/user[@uuid="uuid-of-user"]
+ Corresponding Access Level:
+ //system-security-plan/system-implementation/user[@uuid="uuid-of-user"]/prop[@name="privilege-level"]/@value
+ Corresponding Authentication method:
+ //system-security-plan/system-implementation/user[@uuid="uuid-of-user"]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="authentication-method"]/@value
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+## 4.6. External Systems and Services Not Having FedRAMP Authorization
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ [EXAMPLE]External System / Service Name
+
+ Briefly describe the interconnection details.
+
+
+
+
+
+
+
+
+
+
+ [SAMPLE]Interconnection Security Agreement Title
+
+
+
+{{}}
+
+## 4.7. External System and Services (Queries)
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Interconnection # for first external system:
+ /*/system-implementation/component[@type='interconnection'][1]/ prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-type"]/@value
+ System/Service/API/CLI Name:
+ /*/system-implementation/component[@type='interconnection']/title
+ Connection Details:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@name="direction"]/@value
+ Nature of Agreement for first external system:
+ /*/system-implementation/component[@type='interconnection'][1]/ prop[@ns="https://fedramp.gov/ns/oscal" and @name="nature-of-agreement"]/@value
+ Still Supported (Y/N):
+ /*/system-implementation/component[@type='interconnection'][1]/ prop[@ns="https://fedramp.gov/ns/oscal" and @name="still-supported"]/@value
+ Data Types:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-data-type"]/@value
+ Data Categorization:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-data-categorization"]/@value
+ Authorized Users:
+ //system-security-plan/system-implementation/user[@uuid="uuid-of-user"]
+ Corresponding Access Level:
+ //system-security-plan/system-implementation/user[@uuid="uuid-of-user"]/prop @name="privilege-level"]/@value
+ Other Compliance Programs:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-compliance"]/@value
+ Description:
+ /*/system-implementation/component[@type='interconnection'][1]/description
+ Hosting Environment:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-hosting-environment"]/@value
+ Risk/Impact/Mitigation:
+ /*/system-implementation/component[@type='interconnection'][1]/prop[@ns="https://fedramp.gov/ns/oscal" and @name="interconnection-risk"]/@value
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+## 4.8. Illustrated Architecture and Narratives
+
+### 4.8.1. Authorization Boundary
+
+The OSCAL approach to this type of diagram is to treat the image data as either a linked or base64-encoded resource in the back-matter section of the OSCAL file, then reference the diagram using the link field.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ A holistic, top-level explanation of the FedRAMP authorization boundary.
+
+
+
+ A diagram-specific explanation.
Authorization Boundary Diagram
+
+
+
+
+
+
+
+
+
+
+ The primary authorization boundary diagram.
00000000
+
+
+{{}}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Overall Description:
+ /*/system-characteristics/authorization-boundary/description/node()
+ Count the Number of Diagrams (There should be at least 1):
+ count(/*/system-characteristics/authorization-boundary/diagram)
+ Link to First Diagram:
+ /*/system-characteristics/authorization-boundary/diagram[1]/link/@href
+
+
+ If the diagram link points to a resource within the OSCAL file:
+ /*/back-matter/resource[@uuid="uuid-of-boundary-diagram"]/base64
+ OR:
+ /*/back-matter/resource[@uuid="uuid-of-boundary-diagram-1"]/rlink/@href
+ Diagram-specific Description:
+ /*/system-characteristics/authorization-boundary/diagram[1]/description/node()
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+### 4.8.2. Network Architecture
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ A holistic, top-level explanation of the system's network.
+
+
+
+ A diagram-specific explanation.
Network Diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The primary network architecture diagram.
+
+{{}}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Overall Description:
+ /*/system-characteristics/network-architecture/description/node()
+ Count the Number of Diagrams (There should be at least 1):
+ count(/*/system-characteristics/network-architecture/diagram)
+ Link to First Diagram:
+ /*/system-characteristics/network-architecture/diagram[1]/link/@href
+
+
+ If the diagram link points to a resource within the OSCAL file:
+ /*/back-matter/resource[@uuid="uuid-of-network-diagram-1"]/base64
+ OR:
+ /*/back-matter/resource[@uuid="uuid-of-network-diagram-1"]/rlink/@href
+ First Diagram Description:
+ /*/system-characteristics/network-architecture/diagram[1]/description/node()
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+### 4.8.3. Data Flow
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ A holistic, top-level explanation of the system's data flows.
+
+
+
+ A diagram-specific explanation.
Data Flow Diagram
+
+
+
+
+
+
+
+
+
+
+
+ The primary data flow diagram.
+ 00000000
+
+
+
+{{}}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Overall Description:
+ /*/system-characteristics/data-flow/description/node()
+ Count the Number of Diagrams (There should be at least 1):
+ count(/*/system-characteristics/data-flow/diagram)
+ Link to First Diagram:
+ /*/system-characteristics/data-flow/diagram[1]/link/@href
+
+ If the diagram link points to a resource within the OSCAL file:
+ /*/back-matter/resource[@uuid="uuid-of-dataflow-diagram-1"]/base64
+ OR:
+ /*/back-matter/resource[@uuid="uuid-of-dataflow-diagram-1"]/rlink/@href
+ First Diagram Description:
+ /*/system-characteristics/data-flow/diagram[1]/description/node()
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+## 4.9. Ports, Protocols and Services
+
+Entries in the ports, protocols, and services table are represented as component assemblies, with the component-type flag set to "service". Use a protocol assembly for each protocol associated with the service. For a single port, set the port-range start flag and end flag to the same value.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ [SAMPLE]Service Name
+ Describe the service
Describe the purpose the service is needed.
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Service (1st service):
+ /*/system-implementation/component[@type='service'][1]/title
+ Ports: Start (1st service, 1st protocol, 1st port range):
+ /*/system-implementation/component[@type='service'][1]/protocol[1]/port-range[1]/@start
+ Ports: End (1st service, 1st protocol, 1st port range):
+ /*/system-implementation/component[@type='service'][1]/protocol[1]/port-range[1]/@end
+ Ports: Transport (1st service, 1st protocol, 1st port range):
+ /*/system-implementation/component[@type='service'][1]/protocol[1]/port-range[1]/@transport
+ Protocol (1st service, 1st protocol):
+ /*/system-implementation/component[@type='service'][1]/protocol[1]/@name
+ Purpose (1st service):
+ /*/system-implementation/component[@type='service'][1]/purpose
+ Used By (1st service):
+ /*/system-implementation/component[@uuid='uuid-of-component-used-by']/title
+{{}}
+
+
+{{}}
+Replace XPath predicate "[1]" with "[2]", "[3]", etc.
+{{ }}
+
+---
+## 4.10. Cryptographic Modules Implemented for Data-in-Transit (DIT)
+
+NIST\'s component model treats independent validation of products and services as if that validation were a separate component. This means when using components with FIPS 140 validated cryptographic modules, there must be two component assemblies:
+
+- **The Validation Definition**: A component definition that provides details about the validation.
+
+- **The Product Definition**: A component definition that describes the hardware or software product.
+
+The validation definition is a component definition that provides details about the independent validation. Its type must have a value of "validation". In the case of FIPS 140 validation, this must include a link field with a rel value set to "validation-details". This link must point to the cryptographic module\'s entry in the NIST Computer Security
+Resource Center (CSRC) [Cryptographic Module Validation Program Database](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search).
+
+The product definition is a product with a cryptographic module. It must contain all of the typical component information suitable for reference by inventory-items and control statements. It must also include a link field with a rel value set to "validation" and an href value containing
+a URI fragment. The Fragment must start with a hashtag (#) and include the UUID value of the validation component. This links the two together.
+
+
+
+#### Component Representation: Example Product with FIPS 140-2 Validation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+ Module Name
+ FIPS 140-2 Validated Module
+
+
+
+ Product Name
+ A product with a cryptographic module.
+
+
+
+
+{{}}
+
+---
+## 4.11. Cryptographic Modules Implemented for Data-at-Rest (DAR)
+
+The approach is the same as in section 4.14 (cryptographic module data-in-transit).
+
+
+
+#### Component Representation: Example Product with FIPS 140-2 Validation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+ Module Name
+ FIPS 140-3 Validated Module
+
+
+
+ Product Name
+ A product with a cryptographic module.
+
+
+
+
+{{}}
diff --git a/docs/content/guides/ssp/5-attachments.md b/docs/content/guides/ssp/5-attachments.md
new file mode 100644
index 000000000..340524b12
--- /dev/null
+++ b/docs/content/guides/ssp/5-attachments.md
@@ -0,0 +1,279 @@
+---
+title: Attachments
+section: /ssp/
+toc:
+ enabled: true
+weight: 104
+---
+
+Classic FedRAMP attachments include a mix of items. Some lend well to
+machine-readable format, while others do not. Machine-readable content
+is typically addressed within the OSCAL-based FedRAMP SSP syntax, while
+policies, procedures, plans, guidance, and the rules of behavior
+documents are all treated as classic attachments, as described in the
+*Citations, Attachments, and Embedded Content in OSCAL Files* Section.
+The resource's title and description must be used to provide a
+human-readable indicator of what attachment is being referenced,
+however, OSCAL extensions must also be provided when applicable for
+machine readability. The following table describes how each attachment
+is handled:
+
+|**Appendix Name**|**Machine Readable**|**How to Handle in OSCAL**|
+| :-- | :-- | :-- |
+| **Appendix A: FedRAMP Security Controls** | Yes | This can be generated from the content in the Security Controls section and does not need to be maintained separately or attached. |
+| **Appendix B: Related Acronyms** | No | Attach using the back-matter, resource syntax.
For Acronyms, resource must include a prop with @ns="https://fedramp.gov/ns/oscal", @name="type", and @value="fedramp-acronyms". |
+| **Appendix C: Security Policies and Procedures** | No | Attach using the back-matter, resource syntax.
For Policies, resource must include a prop with @name=”type”, @value=”policy”, and @class=”control-family”.
For Procedures, resource must include a prop with @name=”type”, @value=”procedure”, and @class=”control-family”. |
+| **Appendix D: User Guide** | No | Attach using the back-matter, resource syntax.
For User Guides, resource must include a prop with @name=”type” and @value=”users-guide”. |
+| **Appendix E: Digital Identity Worksheet** | Yes | Incorporated above. See the Digital Identity Determination Section. |
+| **Appendix F: Rules of Behavior** | No | Attach using the back-matter, resource syntax.
For Rules of Behavior, resource must include a prop with @name=”type” and @value="rules-of-behavior". |
+| **Appendix G: Information System Contingency Plan (ISCP)** | No | Attach using the back-matter, resource syntax.
For ISCP, resource must include a prop with @name=”type”, @value="plan", and @class="information-system-contingency-plan". |
+| **Appendix H: Configuration Management Plan (CMP)** | No | Attach using the back-matter, resource syntax.
For CMP, resource must include a prop with @name=”type”, @value="plan", and @class="configuration-management-plan". |
+| **Appendix I: Incident Response Plan (IRP)** | No | Attach using the back-matter, resource syntax.
For IRP, resource must include a prop with @name=”type”, @value="plan", and @class="incident-response-plan". |
+| **Appendix J: CIS and CRM Workbook** | Yes | This can be generated from the content in the Security Controls section and does not need to be maintained separately or attached. |
+| **Appendix K: FIPS 199 Worksheet** | Yes | Incorporated above. See the Security Objectives Categorization (FIPS-199) Section. |
+| **Appendix L: CSO-Specific Required Laws and Regulations** | No | Attach using the back-matter, resource syntax.
For User Guides, resource must include a prop with @name=”type” and @value=”law”. |
+| **Appendix M: Integrated Inventory Workbook** | Yes | See the System Inventory Section. |
+| **Appendix N: Continuous Monitoring Plan** | No | Attach using the back-matter, resource syntax.
For ConMon, resource must include a prop with @name=”type”, @value="plan", and @class="incident-response-plan". |
+| **Appendix O: POA&M** | Yes | This is maintained separately in an OSCAL POA&M but can be attached using the back-matter, resource syntax.
For POA&M, resource must include a prop with @name=”type”, @value="plan", and @class="poam". |
+| **Appendix P: Supply Chain Risk Management Plan (SCRMP)** | No | Attach using the back-matter, resource syntax.
For SCRMP, resource must include a prop with @name=”type”, @value="plan", and @class="scrmp". |
+| **Appendix Q: Cryptographic Module Table** | Yes | See the Cryptographic Modules Section dealing with components. |
+
+---
+## 5.1. Attachments
+Classic FedRAMP attachments include a mix of items. Some lend well to
+machine-readable format, while others do not. Machine-readable content
+is typically addressed within the OSCAL-based FedRAMP SSP syntax, while
+policies, procedures, plans, guidance, and the rules of behavior documents are all treated as classic attachments, as described in the *Citations, Attachments, and Embedded Content in OSCAL Files* Section. The following table describes how each attachment is handled:
+
+#### Attachment Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Document Title
+ Policy document
+ 00000000
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ The Number of Policies Attached:
+ count(/*/back-matter/resource/prop[@name="type"][@ns="https://fedramp.gov/ns/oscal"][string(./@value)="policy"])
+ Attachment (Embedded Base64 encoded):
+ /*/back-matter/resource[@id="att-policy-1"]/base64
+ OR (Relative Link):
+ /*/back-matter/resource[@id="att-policy-1"]/rlink/@href
+ Title of First Policy Document:
+ /*/back-matter/resource/prop[@name="type"][@ns="https://fedramp.gov/ns/oscal"][string(.)="policy"][1]/../prop[@name="title"][@ns="https://fedramp.gov/ns/oscal"]
+{{}}
+
+---
+## 5.2. System Inventory Approach
+
+
+
+OSCAL makes two approaches available for depicting the system inventory:
+
+- **Flat-File Approach**: Similar to today\'s FedRAMP Integrated inventory workbook where all of the information on a spreadsheet row is captured in a single assembly.
+
+- **Component-Based Approach**: A component is defined once with as much known detail as possible, and inventory-items point to components for common information.
+
+FedRAMP prefers the component-based approach but accepts the flat-file approach to aid CSPs who are converting their existing MS-Excel based FedRAMP Integrated Inventory Workbook to OSCAL. **FedRAMP SSP tools must support both approaches.**
+
+
+
+With the **flat-file approach**, all content on a spreadsheet row appears in a single OSCAL inventory-item assembly. This results in a great deal of redundant information but is a simple transition from the current spreadsheet approach.
+
+
+
+With the **component-based approach**, common information is captured once in a component assembly. Each instance of that component has its own inventory-item assembly, which cites the relevant component and only includes information unique to that instance.
+
+For example, if the same Linux operating system is used as the platform for all database and web servers, most of the details about the Linux operating system can be captured once as a component. This includes information such as vendor name, version number, and patch level. If four Linux instances are used, each instance is an inventory item with a unique IP address and MAC address. Only those unique pieces are captured at the inventory level. All four inventory-items point back to the component for vendor name, version number, and patch level.
+
+---
+### 5.2.1. Flat File Approach
+
+#### Flat-File Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ Flat-File Example (No implemented-component).
+ If no, explain why. If yes, omit remarks field.
+
+ person-7
+
+
+ it-dept
+
+ COMMENTS: Additional information about this item.
+
+
+
+
+{{}}
+
+**Notes:**
+
+The value of asset-type determines whether the identified
+asset-administrator is managing a system or an application. Currently, any FedRAMP-defined asset-type implies the management of a system, and therefore, is to be scanned as infrastructure.
+
+---
+### 5.2.2. Component-based Approach
+
+#### Component-based Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ If no, explain why. If yes, omit remarks field.
+
+ Optional, longer, formatted description.
+
+
+ person-7
+
+
+ it-dept
+
+
+
+
+
+ If needed, describe this instance.
COMMENTS: Additional information about this item.
+
+
+
+
+{{}}
+
+**Notes:**
+
+- If component-sample is an image of a Linux virtual machine (VM), and 10 instances of that VM are in use, there would be one (1) component assembly and ten (10) inventory-item assemblies, all referencing the same component.
+
+---
+### 5.2.3. Inventory Data Locations and XPath Queries
+
+The following queries are intended to show where to find each piece of information within the system inventory template.
+
+
+*All Inventory*
+
+
+*OS Infrastructure Inventory*
+
+
+*Software and Database Inventory*
+
+
+*Any Inventory*
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Number of Inventory Items:
+ count(/*/system-implementation/system-inventory/inventory-item)
+ Number of Hardware Components:
+ count(/*/system-implementation/component[@type="hardware"])
+ Number of Software Components:
+ count(/*/system-implementation/component[@type="software"])
+ In Latest Scan?:
+ /*/system-implementation/system-inventory/inventory-item[1]/prop[@name="is-scanned"]/@value
+
+ List Inventory Items Not Scanned:
+ /*/system-implementation/system-inventory/inventory-item/prop[@name="is-scanned"][@value='no']/../prop[@name='ipv4-address']
+ List of Reasons Inventory Items Were Not Scanned:
+ /*/system-implementation/system-inventory/inventory-item/prop[@name="is-scanned"][@value='no']/remarks/node()
+{{}}
+
+Unlike most XPath 2.0 queries in this
+document, the following queries cannot be easily converted to XPath 1.0.
+If working with XPath 1.0, it may be necessary to perform each search
+with two separate queries. These queries will list all the IPv4
+addresses for each scan type (infrastructure, web, and database),
+whether using the flat-file inventory approach or the component-based
+approach.
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ IPv4 Address of All Inventory Items Identified for Infrastructure Scanning:
+ distinct-values( (let $key:=/*/system-implementation/component[prop [@name='scan-type'] [@ns='https://fedramp.gov/ns/oscal']='infrastructure']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/ prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='https://fedramp.gov/ns/oscal'] [string(.)='infrastructure']]) )
+ IPv4 Address of All Inventory Items Identified for Web Scanning:
+ distinct-values( (let $key:=/*/system-implementation/component[prop[@name='scan-type'][@ns='https://fedramp.gov/ns/oscal']='web']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='https://fedramp.gov/ns/oscal'][string(.)='web']]))
+ IPv4 Address of All Inventory Items Identified for Database Scanning:
+ distinct-values( (let $key:=/*/system-implementation/component[prop [@name='scan-type'] [@ns='https://fedramp.gov/ns/oscal']='database']/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) | (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name='scan-type'][@ns='https://fedramp.gov/ns/oscal'][string(.)='database']]))
+ IPv4 Address of All Items Where an Authenticated Scan is Possible:
+ distinct-values( (/*/system-implementation/system-inventory/inventory-item/prop [@name='ipv4-address'][../prop[@name="allows-authenticated-scan"][@value='yes']] ) | (let $key:=/*/system-implementation/component[prop [@name='allows-authenticated-scan'][@value='yes']]/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']))
+ IPv4 Address of All Items Where an Authenticated Scan is Not Possible:
+ distinct-values( (/*/system-implementation/system-inventory/inventory-item/prop[@name='ipv4-address'][../prop[@name="allows-authenticated-scan"][@value='no']] ) | ( let $key:=/*/system-implementation/component[prop [@name='allows-authenticated-scan'][@value='no']]/@uuid return /*/system-implementation/system-inventory/inventory-item [implemented-component/@component-uuid=$key]/prop[@name='ipv4-address']) )
+ Authenticated Scan Justification (if Authenticate Scan is "no"):
+ /*/system-implementation/system-inventory/inventory-item/prop[@name="allows-authenticated-scan"][@value="no"]/remarks/node()
+ OR
+ /*/system-implementation/component/prop[@name="allows-authenticated-scan"] [@value="no"]/remarks/node()
+{{}}
diff --git a/docs/content/guides/ssp/6-security-controls.md b/docs/content/guides/ssp/6-security-controls.md
new file mode 100644
index 000000000..7fd09cc27
--- /dev/null
+++ b/docs/content/guides/ssp/6-security-controls.md
@@ -0,0 +1,793 @@
+---
+title: Security controls
+section: /ssp/
+toc:
+ enabled: true
+weight: 105
+---
+
+
+
+This section describes the modeling of security control information in
+an OSCAL-based FedRAMP SSP. To ensure consistent processing, FedRAMP
+imposes specific requirements on the use of OSCAL for control implementation information.
+
+The modeling of controls is addressed in the following sections as
+follows:
+
+- **Section 6.1, Control Definitions**
+
+- **Section 6.2, Responsible Roles Responsible Roles** and Parameter
+ Assignments
+
+- **Section 6.3, Implementation Status**
+
+- **Section 6.3.1.1, Control Origination**
+
+- **Section 6.4, Control Implementation Descriptions**
+
+ - **Organization**
+
+ - **Policy and Procedure Statements**
+
+ - **Multi-Part Statements**
+
+ - **Single Statements**
+
+ - **Response**
+
+ - **Overview**
+
+ - **Example**
+
+ - **"This System"**
+
+ - **Inheriting from a Leveraged Authorization**
+
+ - **Identifying Customer Responsibilities**
+
+ - **Providing Inheritance**
+
+---
+## 6.1. Control Definitions
+
+
+
+All control definition information is imported from the appropriate
+FedRAMP baseline (OSCAL profile). This includes the original NIST control definition and parameter labels as well as any FedRAMP control
+guidance and parameter constraints.
+
+Interpreting and presenting profile content is beyond the scope of this
+document. Please refer to the NIST OSCAL Profile and Catalog schema references for more information:
+
+- [Profile Model](https://pages.nist.gov/OSCAL/concepts/layer/control/profile/)
+
+- [Catalog Reference](https://pages.nist.gov/OSCAL/concepts/layer/control/catalog/)
+
+Only the control implementation information is present within an
+OSCAL-based SSP. Each control in the FedRAMP baseline must have a
+corresponding implemented-requirement assembly in the
+control-implementation assembly.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ This field required by OSCAL, but may be left blank.
+ FedRAMP requires no specific content here.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ URI to Profile:
+ /*/import-profile/@href
+ CSP's Control Implementation Information
+ /*/control-implementation/implemented-requirement[@control-id="ac-1"]
+
+{{}}
+
+**NOTE:** FedRAMP tools check to ensure there is one
+implemented-requirement assembly for each control identified in the
+applicable FedRAMP baseline.
+
+---
+## 6.2. Responsible Roles and Parameter Assignments
+
+Every applicable control must have at least one responsible-role
+defined. There must be a separate responsible-role assembly for each
+responsible role. OSCAL requires the specified role-id to be valid in
+the defined list of roles in the metadata. Controls with a FedRAMP
+implementation-status property value of non-applicable (see section 6.3)
+do not require a responsible-role. FedRAMP further requires the
+specified role-id must also have been referenced in the system-implementation user assembly. This equates to the FedRAMP requirement of all responsible roles appearing in the Personnel Roles and Privileges table.
+
+
+
+With the implemented-requirement assembly, there must be one set-parameter statement for each of the control\'s parameters, as specified in the FedRAMP baseline and illustrated in the example representation below. The only exception to this is with nested parameters. Some select parameters contain an assignment parameter within a selection parameter, such as appears in AC-7 (b). In these instances, only the final selected value must be provided. The nested assignment parameter may be ignored.
+
+OSCAL also supports parameter setting at the component level, within a
+by-component assembly.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ Unix Administrator
+
+
+
+
+
+ admin-unix
+
+
+
+
+
+
+
+ System Manager, System Architect, ISSO
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Number of specified Responsible Roles:
+ count(/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role)
+ Responsible Role:
+ /*/metadata/role[@id=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role[1]/@role-id]/title
+ Check for existence in Personnel Roles and Privileges (Should return a number > 0)
+ count(/*/system-implementation/user/role-id[string(.)=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/responsible-role/@role-id])
+ Parameter Value:
+ /*/control-implementation/implemented-requirement[@control-id="ac-2"]/set-parameter [@param-id="ac-2_prm_1"]/value
+
+{{}}
+
+---
+## 6.3. Implementation Status
+
+FedRAMP only accepts only one of five values for implementation-status:
+implemented, partial, planned, alternative, and not-applicable. A
+control may be marked "partial" and "planned" (using two separate
+implementation-status fields). All other choices are mutually exclusive.
+
+**If the implementation-status is partial,** the gap must be explained
+in the remarks field.
+
+**If the implementation-status is planned,** a brief description of the
+plan to address the gap, including major milestones must be explained in
+the remarks field. There must also be a prop
+(name=\"planned-completion-date\" ns=\"https://fedramp.gov/ns/oscal\")
+field containing the intended completion date. With XML, prop fields
+must appear before prop fields, even though that sequence is
+counter-intuitive in this situation.
+
+**If the implementation-status is alternative,** the alternative
+implementation must be summarized in the remarks field.
+
+**If the implementation-status is not-applicable,** the N/A
+justification must be provided in the remarks field.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Implementation Status (may return more than 1 result for a given control) :
+ /*/control-implementation/implemented-requirement[@control-id="ac-1"] /prop[@name="implementation-status"]/@value
+ Gap Description (If implementation-status="partial"):
+ /*/control-implementation/implemented-requirement/prop[@name='implementation-status'][@value="partial"][@ns="https://fedramp.gov/ns/oscal"]/remarks/node()
+ Planned Completion Date (If implementation-status="planned"):
+ /*/control-implementation/implemented-requirement[@control-id="ac-1"]/prop[@name="planned-completion-date"][@ns="https://fedramp.gov/ns/oscal"]/@value
+ Plan for Completion (If implementation-status="planned"):
+ /*/control-implementation/implemented-requirement/prop[@name='implementation-status'][@value="planned"][@ns="https://fedramp.gov/ns/oscal"]/remarks/node()
+ Not Applicable (N/A) Justification (If implementation-status="na"):
+ /*/control-implementation/implemented-requirement/prop[@name='implementation-status'][@value="not-applicable"][@ns="https://fedramp.gov/ns/oscal"]/remarks/node()
+
+{{}}
+
+The FedRAMP implementation-status property at the control's
+implemented-requirement level is a summary of all statement and/or
+component level core OSCAL implementation-status designations. It must
+be set to the appropriately based on the least value of child statement
+or component level implementation-status designations. When a statement
+and/or component level implementation-status designation is not
+specified, the FedRAMP implementation-status value is assumed.
+Individual statements and/or components may override
+implementation-status locally.
+
+### 6.3.1. Control Origination
+
+FedRAMP accepts only one of five values for control-origination:
+sp-corporate, sp-system, customer-configured, customer-provided, and
+inherited. Hybrid choices are now expressed by identifying more than one
+control-origination, each in a separate prop field.\
+For controls with a control-id ending in \"-1\", FedRAMP only accepts
+sp-corporate, and sp-system.
+
+**If the control origination is inherited,** there must also be a
+FedRAMP extension (prop name=\"leveraged-authorization-uuid\"
+ns=\"https://fedramp.gov/ns/oscal\") field containing the UUID of the
+leveraged authorization as it appears in the
+/\*/system-implementation/leveraged-authorization assembly.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+#### XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Number of Control Originations:
+ count(/*/control-implementation/implemented-requirement[@control-id="ac-2"]/prop[@name="control-origination"][@ns="https://fedramp.gov/ns/oscal"])
+ Control Origination(could return more than 1 result):
+ /*/control-implementation/implemented-requirement[@control-id="ac-2"]/prop[@name="control-origination"][@ns="https://fedramp.gov/ns/oscal"][1]/@value
+ Inherited From: System Name (If control-origination="inherited"):
+ /*/system-implementation/leveraged-authorization[@uuid=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/prop[@name="leveraged-authorization-uuid"]]/title
+ Inherited From: Authorization Date (If control-origination="inherited"):
+ /*/system-implementation/leveraged-authorization[@uuid=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/prop[@name="leveraged-authorization-uuid"]]/date-authorized
+
+{{}}
+
+---
+## 6.4. Control Implementation Descriptions
+
+
+
+Within the OSCAL-based FedRAMP baselines, control statements and control
+objectives are tagged with a response-point FedRAMP Extension. Every
+control statement designated as a response-point in the baseline must
+have a statement with the control\'s implemented-requirement assembly.
+Please note control objective response points are used for the SAP and
+SAR.
+
+When using a **FedRAMP Resolved Profile Catalog**, the following query
+will identify the response points for a given control.
+
+#### XPath Query
+{{< highlight xml "linenos=table" >}}
+ Response Points for AC-1:
+ //control[@id='ac-1']/part[@name='statement']//prop[@name='response-point'][@ns='https://fedramp.gov/ns/oscal']/../@id
+
+{{}}
+
+---
+### 6.4.1. Organization: Policy and Procedure Statements
+
+For each of the -1 controls, such as AC-1, there must be exactly four
+statement assemblies: Part (a)(1), Part (a)(2), Part (b)(1), and Part
+(b)(2).
+
+#### Policy and Procedure Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+{{}}
+
+---
+### 6.4.2. Organization: Multi-Part Statements
+
+There must be one statement assembly for each lettered part, such as
+with AC-2, parts a, b, c, etc.
+
+#### Multi-Part Statement Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+{{}}
+
+---
+### 6.4.3. Organization: Single Statement
+
+If there are no lettered parts in the control definition, such as with
+AC-2 (1), there must be exactly one statement assembly.
+
+#### Single-Statement Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+{{}}
+
+---
+### 6.4.4. Response: Overview
+
+Within each statement assembly, all responses must be provided within
+one or more by-component assemblies. There must always be a component
+defined in the system-implementation representing the system as a whole
+(**"THIS SYSTEM"**), even if individual components are defined that
+comprise the system. **See *7.3,* *Working with Components* for more information.**
+
+An OSCAL-based FedRAMP SSP should define individual components of the
+system. Components are not just hardware and software. Policies,
+processes, FIPS 140 validation information, interconnections, services,
+and underlying systems (leveraged authorizations) are all components.
+
+With OSCAL, the content in the cell next to *Part a* must be broken down
+into its individual components and responded to separately.
+
+
+
+- For **Part a**
+ - Component - This System
+ - Describes how *part a* is satisfied holistically, or where the description does not fit with a defined component.
+ - Component - Platform
+ - Describes how *part a* is satisfied by the platform.
+ - Component - Web-Server
+ - Describes how *part a* is satisfied by the web server.
+ - Component - Process
+ - Describes how *part a* is satisfied by an identified process within this organization.
+ - Component - Inherited
+ - Describes what is inherited from the underlying Infrastructure as a Service (IaaS) provider to satisfy *part a*.
+- For **Part b**
+ - Component - This System
+ - Describes how *part b* is satisfied holistically, or where the description does not fit with a defined component.
+ - Component - Platform
+ - Describes how *part b* is satisfied by the platform.
+ - Component - Web-Server
+ - Describes how *part b* is satisfied by the web server.
+ - Component - Process
+ - Describes how *part b* is satisfied by an identified process within this organization.
+ - Component - Inherited
+ - Describes what is inherited from the underlying Infrastructure as a Service (IaaS) provider to satisfy *part b*.
+
+
+**The following pages provide examples.**
+
+---
+### 6.4.5. Response: Example
+
+Within each of the statement assemblies, all responses appear in one or
+more by-component assemblies. Each by-component assembly references a component defined in the system-implementation assembly.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Component Title
+
+ Description of the component.
+
+
+
+
+ Process Title
+
+ Description of the component.
+
+
+ 3360e343-9860-4bda-9dfc-ff427c3dfab6
+
+
+
+
+
+
+
+
+
+
+
+ Describe how is the software component satisfying the control.
+
+
+
+
+ Describe how is the process satisfies the control.
+
+
+
+
+
+
+
+
+
+
+{{}}
+
+**NOTES:**
+
+- All statement-id values must be cited as they appear in the NIST SP
+ 800-53, Revision 4 or Revision 5 OSCAL catalogs:\
+
+
+---
+### 6.4.6. Response: "This System" Component
+
+There must always be a **"This System"** component in the SSP. This is used in several ways:
+
+- **Holistic Overview**: If the SSP author wishes to provide a more
+ holistic overview of how several components work together, even if
+ details are provided individually in other by-component assemblies.
+
+- **Catch-all**: Any control response that does not cleanly align with
+ another system component may be described in the **"This System"**
+ component.
+
+- **Legacy SSP Conversion**: When converting a legacy SSP to OSCAL,
+ the legacy control response statements may initially be associated
+ with the **"This System"** component until the SSP author is able\
+ to provide responses for individual components.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+ This System
+
+ Description of the component.
+
+
+
+
+
+
+
+
+
+
+
+ Describe how individual components are working together.
+ Describe how the system - as a whole - is satisfying this statement.
+ This can include policy, procedures, hardware, software, etc.
+
+
+
+
+
+
+
+
+
+{{}}
+
+**NOTES:**
+
+- Although the name of the component is **"This System"**,
+ non-technical solutions may also be discussed here, such as policies
+ and procedures.
+
+---
+### 6.4.7. Linking to Artifacts
+
+Any time policies, procedures, plans, and similar documentation are
+cited in a control response, they must be linked.
+
+For the legacy approach, when responding within the by-component
+assembly for **"this system"**, the link must be within the same by-component assembly where the artifact is cited.
+
+
+
+#### Representation: Legacy Approach Example - No Policy Component
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+ Describe how Part a is satisfied within the system.
+
+
+
+
+
+
+
+
+{{}}
+
+For the component approach, use the component representing the policy.
+The link should be in the component, but may be added directly to the
+by-component as well.
+
+#### Representation: Component Approach Example
+{{< highlight xml "linenos=table" >}}
+
+
+
+ Access Control and Identity Management Policy
+
+ An example component representing a policy.
+
+
+
+
+
+
+
+
+
+ Describe how this policy satisfies Part a.
+
+
+
+
+
+
+
+{{}}
+
+For either example above, the policy must be present as a resource in back-matter.
+
+#### In Back Matter
+{{< highlight xml "linenos=table" >}}
+
+
+ Access Control and Identity Management Policy
+ 00000000
+
+
+
+{{}}
+
+---
+### 6.4.8. Response: Identifying Inheritable Controls and Customer Responsibilities
+
+For systems that may be leveraged, OSCAL enables a robust mechanism for
+providing both inheritance details as well as customer responsibilities
+(referred to as consumer responsibilities by NIST). OSCAL is designed to
+enable leveraged and leveraging system SSP details to be linked by tools
+for validation.
+
+Within the appropriate by-component assembly, include an export
+assembly. Use provided to identify a capability that may be inherited by a leveraging system. Use responsibility to identify a customer responsibility. If a responsibility must be satisfied to achieve inheritance, add the
+provided-uuid flag to the responsibility field.
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+ Describe how the system - as a whole - is satisfying this statement.
+
+
+
+
+ Leveraging system's responsibilities in satisfaction of AC-2.
+ Not linked to inheritance, so this is always required.
+
+
+
+
+
+
+ Describe how the software is satisfying this statement.
+
+
+
+
+ Customer appropriate description of what may be inherited.
+
+
+
+
+
+ Customer responsibilities if inheriting this capability.
+
+
+
+
+
+
+
+
+{{}}
+
+**See Section 6.4.10, XPath Queries for Control Implementation Descriptions**
+
+**See the [NIST OSCAL Leveraged Authorization Presentation](https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf) for more information.**
+
+---
+### 6.4.9. Leveraged Authorization Response: Inheriting Controls, Satisfying Responsibilities
+
+When the current system is inheriting a control from or meeting customer
+responsibilities defined by an underlying authorization, the leveraged
+system must first be defined as described in *Section **Error! Reference
+source not found.**, **Error! Reference source not found.*** before it
+may be referenced in a control response. The by-component assembly
+references these components.
+
+IMPORTANT: The leveraged system may provide a single component
+representing the entire leveraged system\
+or may provide individual system components as well. In either case, the
+inherited-uuid property in the component when defined in the leveraging
+system\'s SSP.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+
+
+ <b>LEVERAGED SYSTEM as a whole (IaaS)</b>
+
+
+ Service Provided by Leveraged System
+
+
+
+
+
+
+ Describe what is satisfied by this system.
+
+
+
+ Describe what is inherited from the leveraged system in satisfaction
+ of this control statement.
+
+
+
+
+ Optional: Information provided by leveraged system.
+
+
+
+
+
+ Description of how the responsibility was satisfied.
+
+
+
+
+
+
+
+
+
+{{}}
+
+**See Section 6.4.10, XPath Queries for Control Implementation Descriptions**
+
+**See the [NIST OSCAL Leveraged Authorization Presentation](https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf) for more information.**
+
+---
+### 6.4.10. XPath Queries for Control Implementation Descriptions
+
+Use the following XPath queries to retrieve basic control response
+information. For any given control response part, tools should list the
+name of each component cited by a by-component assembly, as well as the
+description.
+
+
+
+#### Representation
+{{< highlight xml "linenos=table" >}}
+ Number of cited components for AC-2, part a (Integer):
+ count(/*/control-implementation/implemented-requirement[@control-id="ac-2"]/statement[@statement-id="ac-2_smt.a"]/by-component)
+ Name of first component related to AC-2, part a:
+ /*/system-implementation/component[@uuid=/*/control-implementation/implemented-requirement[@control-id="ac-2"]/statement[@statement-id="ac-2_smt.a"]/by-component[1]/@component-uuid]/title
+ "What is the solution and how is it implemented?" for AC-2, Part (a), first component:
+ /*/control-implementation/implemented-requirement[@control-id="ac-2"]/statement[@statement-id="ac-2_smt.a"]/by-component[1]/description/node()
+ Is there a customer responsibility for the first component in AC-2, part a? (true/false):
+ boolean(/*/control-implementation/implemented-requirement[@control-id="ac-2"]/statement[@statement-id="ac-2_smt.a"]/by-component[1] /prop[@name='responsibility'][@value='customer'])
+ Customer responsibility statement for the first component in AC-2, part a:
+ /*/control-implementation/implemented-requirement[@control-id="ac-2"]/statement[@statement-id="ac-2_smt.a"]/by-component[1]/prop[@name='responsibility'][@value='customer']/remarks/node()
+
+{{}}
+
+
+**NOTES:**
+
+- Replace "ac-2" with target control-id.
+- Replace "ac-2_smt.a" with target control statement-id.
+- Replace "\[1\]" with "\[2\]", "\[3\]", etc. as needed to reference
+ is by-component statement.
diff --git a/docs/content/guides/ssp/7-generated-content.md b/docs/content/guides/ssp/7-generated-content.md
new file mode 100644
index 000000000..dd7d689be
--- /dev/null
+++ b/docs/content/guides/ssp/7-generated-content.md
@@ -0,0 +1,181 @@
+---
+title: Generated Content
+section: /ssp/
+toc:
+ enabled: true
+weight: 106
+---
+
+The following artifacts are historically generated by hand to summarize content found in other portions of the FedRAMP SSP. When using OSCAL, these artifacts can be generated from content found elsewhere in this document. This includes the:
+
+- **Control Information Summary (CIS)**
+- **Customer Responsibility Matrix (CRM)**
+
+If delivering SSP content in OSCAL, CSPs are no longer required to manually generate and maintain these artifacts, provided the content in their OSCAL-based FedRAMP SSP remains accurate.
+
+**Tool developers are encouraged to develop their own solutions to generating this content.**
+
+## 7.1. Generating the Control Information Summary (CIS)
+
+There are many ways a tool developer can generate the CIS. FedRAMP is developing an Extensible Stylesheet Language Transformation (XSLT) file to generate the FedRAMP CIS. When ready, FedRAMP will make this freely available to the public here:
+
+
+
+## 7.2. Generating the Customer Responsibility Matrix (CRM)
+
+There are many ways a tool developer can generate the CRM. FedRAMP is
+developing\
+an XSLT file to generate the FedRAMP CRM. When ready, FedRAMP will make
+this freely available to the public here:
+
+[https://github.com/GSA/fedramp-automation/tree/master/dist/content/resources](https://github.com/GSA/fedramp-automation/tree/master/dist/content/resources)
+
+#### Useful CRM XPath Queries
+{{< highlight xml "linenos=table" >}}
+ Flat-File CRM Query:
+ //control-implementation/implemented-requirement/prop[@name="control-origination"][@ns="https://fedramp.gov/ns/oscal"][@value="customer-configured" or @value="customer-provided"]/remarks/node()
+ Component-based CRM Query:
+ //control-implementation/implemented-requirement/statement/by-component[@component-id="customer"]/description
+
+{{}}
+
+
+## 7.3. Working with Components
+
+NIST designed OSCAL such that a system architect can express all aspects
+of the system as components. A component is anything that can satisfy a control requirement. This includes hardware, software, services, and underlying service providers, as well as policies, plans, and procedures. There are several ways to use components in an OSCAL-based SSP. The following defines FedRAMP\'s minimum initial use.
+
+This section will likely be updated as NIST continues to evolve its approach to components in OSCAL, and as FedRAMP receives feedback from stakeholders.
+
+**FedRAMP-defined component identifiers are cited in relevant portions of this document and summarized in the FedRAMP OSCAL Registry.**
+
+### 7.3.1. Minimum Required Components
+
+There must be a component that represents the entire system itself. It should be the only component with the component-type set to "system".
+
+The following is an example of defined components.
+
+#### Minimum Required Component Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+ This System
+
+ The entire system as depicted in the system authorization boundary.
+
+
+
+
+{{}}
+
+### 7.3.2. Common Additional Components
+
+For each FIPS 140 validated module, there must be a component that represents the validation certificate itself. For more information about this, see the *FIPS 140 Validated Components* Section.
+
+#### Common Additional Component Representation
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+
+
+
+ [SAMPLE]Service Name
+ Describe the service
Describe the purpose the service is needed.
+
+
+
+
+
+
+
+
+
+ Module Name
+ FIPS 140 Validated Module
+
+
+
+
+
+{{}}
+
+### 7.3.3. Components as a Basis for System Inventory
+
+NIST\'s approach to component-based system modeling is to reduce redundancy of information and increase flexibility. NIST accomplishes this with separate component and inventory item modeling.
+
+This is a one-to-many relationship. One component to many inventory item instances.
+
+For example, if an open-source operating system (OS) is used in many places throughout the system, it is defined once as a component. All information about the product, vendor, and support are modeled within the component detail. If the OS is used four times within the system, each use is an inventory item, with details about that specific information, such as IP address.
+
+\
+*Relationship of Components and Inventory*
+
+FedRAMP requires a component assembly for each model of infrastructure device used, and each version of software and database used within the system. FedRAMP is not asking for more detail than provided in the legacy inventory workbook. Only that the information is organized differently.
+
+As NIST continues to evolve its component approach, FedRAMP will re-evaluate its approach to system inventory representation.
+
+## 7.4. Converting a Legacy SSP to OSCAL
+
+NIST designed OSCAL such that a system architect can express all aspects of the system as components. A component is anything that can satisfy a control
+requirement. This includes hardware, software, services, and underlying service providers, as well as policies, plans, and procedures.
+
+OSCAL is also designed to support legacy conversion of SSPs without individual components defined and enables an SSP author to migrate to the component approach gradually over time. In this instance, only a single component is initially required, representing the system as a whole and designated with the special component type, "this-system". The following provides an example of FedRAMP\'s minimum required component approach:
+
+#### Example control for legacy SSP conversion
+{{< highlight xml "linenos=table" >}}
+
+
+
+
+ System Name
+
+ Component representing the entire system.
+
+
+
+
+ FedRAMP SSP Template Section 13
+
+
+
+ Describe how Part a is satisfied within the system.
+
+
+
+
+
+
+ Describe how Part b 1 is satisfied within the system.
+
+
+
+
+
+
+ Describe how Part b 2 is satisfied within the system.
+
+
+
+
+
+
+{{}}
diff --git a/docs/content/guides/ssp/_index.md b/docs/content/guides/ssp/_index.md
new file mode 100644
index 000000000..eb83298ae
--- /dev/null
+++ b/docs/content/guides/ssp/_index.md
@@ -0,0 +1,23 @@
+---
+title: FedRAMP OSCAL SSP Guide
+heading: FedRAMP OSCAL SSP Guide
+menu:
+ primary:
+ name: SSP
+ parent: Documentation
+ weight: 50
+toc:
+ enabled: true
+suppresstopiclist: true
+---
+
+## 2. FedRAMP Extensions and Allowed Values
+
+NIST designed the core OSCAL syntax to model cybersecurity information that is common to most organization and compliance frameworks; however, NIST also recognized the need to provide flexibility or organizations with unique information needs.
+
+Instead of trying to provide a language that meets each organization\'s unique needs, NIST designed OSCAL with
+the ability to be extended.
+
+As a result, FedRAMP-compliant OSCAL files are a combination of the core OSCAL syntax and extensions defined by FedRAMP. The [*Guide to OSCAL-Based FedRAMP Content*](/guides/general/) describes the concepts behind FedRAMP extensions and allowed values. The extensions related to the System Security Plan (SSP) are cited in this document in context of their use.
+
+**FedRAMP extensions and allowed** **values are cited in relevant portions of this document and summarized in the** **FedRAMP OSCAL Registry.**
diff --git a/docs/content/resources/_index.md b/docs/content/resources/_index.md
new file mode 100644
index 000000000..56fc464dd
--- /dev/null
+++ b/docs/content/resources/_index.md
@@ -0,0 +1,12 @@
+---
+title: Resources
+heading: FedRAMP OSCAL Resources
+menu:
+ primary:
+ name: Resources
+ weight: 100
+toc:
+ enabled: true
+---
+
+Todo: give overview here...
\ No newline at end of file
diff --git a/docs/content/resources/fedramp.md b/docs/content/resources/fedramp.md
new file mode 100644
index 000000000..41f03a712
--- /dev/null
+++ b/docs/content/resources/fedramp.md
@@ -0,0 +1,13 @@
+---
+title: FedRAMP Resource Links
+heading: FedRAMP OSCAL Resources
+menu:
+ primary:
+ name: FedRAMP Resource Links
+ parent: Resources
+ weight: 103
+toc:
+ enabled: true
+---
+
+Todo: give overview here...
\ No newline at end of file
diff --git a/docs/content/resources/nist.md b/docs/content/resources/nist.md
new file mode 100644
index 000000000..e0c29bccc
--- /dev/null
+++ b/docs/content/resources/nist.md
@@ -0,0 +1,13 @@
+---
+title: NIST Resource Links
+heading: OSCAL Resources
+menu:
+ primary:
+ name: NIST Resource Links
+ parent: Resources
+ weight: 104
+toc:
+ enabled: true
+---
+
+Todo: give overview here...
\ No newline at end of file
diff --git a/docs/content/resources/templates.md b/docs/content/resources/templates.md
new file mode 100644
index 000000000..cf2f7fd7d
--- /dev/null
+++ b/docs/content/resources/templates.md
@@ -0,0 +1,13 @@
+---
+title: Templates
+heading: FedRAMP OSCAL Tools
+menu:
+ primary:
+ name: Templates
+ parent: Resources
+ weight: 101
+toc:
+ enabled: true
+---
+
+Todo: give overview here...
\ No newline at end of file
diff --git a/docs/content/resources/tools.md b/docs/content/resources/tools.md
new file mode 100644
index 000000000..dd9bae8e3
--- /dev/null
+++ b/docs/content/resources/tools.md
@@ -0,0 +1,13 @@
+---
+title: Tools
+heading: FedRAMP OSCAL Tools
+menu:
+ primary:
+ name: Tools
+ parent: Resources
+ weight: 103
+toc:
+ enabled: true
+---
+
+Todo: give overview here...
\ No newline at end of file
diff --git a/docs/content/start/_index.md b/docs/content/start/_index.md
new file mode 100644
index 000000000..de37eaccd
--- /dev/null
+++ b/docs/content/start/_index.md
@@ -0,0 +1,39 @@
+---
+title: Getting Started
+heading: Creating OSCAL-Based Content
+menu:
+ primary:
+ name: Getting Started
+ weight: 10
+toc:
+ enabled: true
+---
+
+Coming Soon: Description of how to get started and how to get prerequisite understanding of OSCAL. Will reference helpful NIST documentation.
+
+# Process Description
+
+Coming Soon: Description of the process including
+
+- Learn OSCAL
+- Create Content
+- Validate Content
+- Submit Content
+
+
+
+# Developing FedRAMP OSCAL-Based Content
+
+Coming Soon: High-level description each of FedRAMP OSCAL content
+
+- SSP
+- SAP
+- SAR
+- POA&M
+
+# FedRAMP Extensions
+
+Coming Soon: How has FedRAMP customized OSCAL? This section will briefly describe FR customizations. For additional information, see:
+
+- [FedRAMP OSCAL Extenstions](https://github.com/GSA/fedramp-automation/blob/master/dist/content/resources/xml/FedRAMP_extensions.xml)
+- [FedRAMP OSCAL Values](https://github.com/GSA/fedramp-automation/blob/master/dist/content/resources/xml/fedramp_values.xml)
\ No newline at end of file
diff --git a/docs/content/start/creating.md b/docs/content/start/creating.md
new file mode 100644
index 000000000..e5ff0c993
--- /dev/null
+++ b/docs/content/start/creating.md
@@ -0,0 +1,106 @@
+---
+title: Creating OSCAL-Based Content
+heading: Creating OSCAL-Based Content
+menu:
+ primary:
+ name: Creating
+ parent: Getting Started
+ weight: 11
+toc:
+ enabled: true
+---
+
+The [*Guide to OSCAL-based FedRAMP Content*](/guides/general/) provides important concepts necessary for working with any OSCAL-based FedRAMP file. Familiarization with those concepts is important to understanding this guide.
+
+## **XML and JSON Formats**
+The examples provided here are in XML; however, FedRAMP accepts XML or JSON formatted OSCAL-based SSP files. NIST offers a utility that provides lossless conversion of OSCAL-compliant files between XML and JSON in either direction.
+
+You may submit your SSP to FedRAMP using either format. If necessary, FedRAMP tools will convert the files for processing.
+
+## **SSP File Concepts**
+
+Unlike the traditional MS Word-based SSP, SAP, and Security Assessment Report (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.
+
+
+
+For example, the NIST control definitions and FedRAMP baseline content that normally appears in Chapter 13 of the SSP are defined in the FedRAMP profile and simply referenced by the SSP.
+
+
+
+For this reason, an OSCAL-based SSP points to the appropriate OSCAL-based FedRAMP baseline as determined by the system's FIPS-199 impact level. Instead of duplicating control details, the OSCAL-based SSP simply points to the baseline content for information such as control definition statements, FedRAMP-added guidance, parameters, and FedRAMP-required parameter constraints.
+
+## **Resolved Profile Catalogs**
+
+The resolved profile catalog for each FedRAMP baseline is a pre-processing of 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.
+
+
+
+_The Resolved Profile Catalog for each FedRAMP Baseline reduces tool processing_
+
+
+For more information about resolved profile catalogs, see the [*Guide to OSCAL-based FedRAMP Content*](/guides/general/5-appendices/#appendix-c-profile-resolution) *Appendix C, Profile Resolution*.
+
+## **OSCAL-based FedRAMP SSP Template**
+FedRAMP offers an OSCAL-based SSP shell file in both XML and JSON formats. This shell contains many of the FedRAMP required standards to help get you started. This document is intended to work in concert with that shell file. The OSCAL-based FedRAMP SSP Template is available in XML and JSON formats here:
+
+- OSCAL-based FedRAMP SSP Template (JSON Format):
+
+- OSCAL-based FedRAMP SSP Template (XML Format):
+
+
+## **OSCAL’s Minimum File Requirements**
+Every OSCAL-based FedRAMP SSP file must have a minimum set of required fields/assemblies, and must follow the OSCAL SSP core syntax found here:
+
+[https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/ssp](https://pages.nist.gov/OSCAL/concepts/layer/implementation/ssp/)
+
+[https://pages.nist.gov/OSCAL/concepts/layer/implementation/ssp/](https://pages.nist.gov/OSCAL/concepts/layer/implementation/ssp/)
+
+## **Importing the FedRAMP Baseline**
+OSCAL is designed for traceability. Because of this, the SSP is designed to be linked to the FedRAMP baseline. Rather than duplicating content from the baseline, the SSP is intended to reference the baseline content itself.
+
+Use the import-profile field to specify an existing OSCAL-based SSP. The href flag may include any valid uniform resource identifier (URI), including a relative path, absolute path, or URI fragment.
+
+**SSP Import Representation**
+{{< highlight xml "linenos=table" >}}
+
+
+ FedRAMP Moderate Baseline
+
+
+
+
+{{< /highlight >}}
+
+**XPath Queries**
+{{< highlight xml "linenos=table" >}}
+
+
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/xml']/@href
+
+ /*/back-matter/resource[@uuid='96445439-6ce1-4e22-beae-aa72cfe173d0'] /rlink[@media-type='application/json']/@href
+{{< /highlight >}}
+
+
+
diff --git a/docs/content/start/submitting.md b/docs/content/start/submitting.md
new file mode 100644
index 000000000..a183eb20b
--- /dev/null
+++ b/docs/content/start/submitting.md
@@ -0,0 +1,31 @@
+---
+title: Submitting OSCAL-Based Content
+heading: Submitting OSCAL-Based Content
+menu:
+ primary:
+ name: Submitting
+ parent: Getting Started
+ weight: 15
+toc:
+ enabled: true
+---
+
+# Submitting FedRAMP OSCAL-Based Content
+
+Coming Soon: Description of the submission process (what files to include, how to package, where submit, etc.)
+
+## P-ATO Submissions
+
+Coming Soon: Description of the submission process (what files to include, how to package, where submit, etc.)
+
+## Annual Authorizations Submissions
+
+Coming Soon: Description of the submission process (what files to include, how to package, where submit, etc.)
+
+## Continuous Monitoring Submissions
+
+Coming Soon: Description of the submission process (what files to include, how to package, where submit, etc.)
+
+## Miscellaneous Submissions
+
+Coming Soon: Description of the submission process (what files to include, how to package, where submit, etc.)
\ No newline at end of file
diff --git a/docs/content/start/validating.md b/docs/content/start/validating.md
new file mode 100644
index 000000000..a79967757
--- /dev/null
+++ b/docs/content/start/validating.md
@@ -0,0 +1,15 @@
+---
+title: Validating OSCAL-Based Content
+heading: Validating OSCAL-Based Content
+menu:
+ primary:
+ name: Validating
+ parent: Getting Started
+ weight: 12
+toc:
+ enabled: true
+---
+
+# Validating FedRAMP OSCAL-Based Content
+
+Coming Soon: Description of how to validate OSCAL content locally before submitting to FedRAMP. Will include links to tools and any instructions on how to validate locally.
\ No newline at end of file
diff --git a/docs/static/img/content-figure-1.png b/docs/static/img/content-figure-1.png
new file mode 100644
index 000000000..6ab6a7ad5
Binary files /dev/null and b/docs/static/img/content-figure-1.png differ
diff --git a/docs/static/img/content-figure-10.png b/docs/static/img/content-figure-10.png
new file mode 100644
index 000000000..e73616b22
Binary files /dev/null and b/docs/static/img/content-figure-10.png differ
diff --git a/docs/static/img/content-figure-11.png b/docs/static/img/content-figure-11.png
new file mode 100644
index 000000000..9bb49c44a
Binary files /dev/null and b/docs/static/img/content-figure-11.png differ
diff --git a/docs/static/img/content-figure-12.png b/docs/static/img/content-figure-12.png
new file mode 100644
index 000000000..36531309c
Binary files /dev/null and b/docs/static/img/content-figure-12.png differ
diff --git a/docs/static/img/content-figure-13.png b/docs/static/img/content-figure-13.png
new file mode 100644
index 000000000..b1c431b15
Binary files /dev/null and b/docs/static/img/content-figure-13.png differ
diff --git a/docs/static/img/content-figure-14.png b/docs/static/img/content-figure-14.png
new file mode 100644
index 000000000..144034cd0
Binary files /dev/null and b/docs/static/img/content-figure-14.png differ
diff --git a/docs/static/img/content-figure-2.png b/docs/static/img/content-figure-2.png
new file mode 100644
index 000000000..fada0707b
Binary files /dev/null and b/docs/static/img/content-figure-2.png differ
diff --git a/docs/static/img/content-figure-3.png b/docs/static/img/content-figure-3.png
new file mode 100644
index 000000000..54a482860
Binary files /dev/null and b/docs/static/img/content-figure-3.png differ
diff --git a/docs/static/img/content-figure-4.png b/docs/static/img/content-figure-4.png
new file mode 100644
index 000000000..c3bdade73
Binary files /dev/null and b/docs/static/img/content-figure-4.png differ
diff --git a/docs/static/img/content-figure-5.png b/docs/static/img/content-figure-5.png
new file mode 100644
index 000000000..c5736cfa7
Binary files /dev/null and b/docs/static/img/content-figure-5.png differ
diff --git a/docs/static/img/content-figure-6.png b/docs/static/img/content-figure-6.png
new file mode 100644
index 000000000..85545dadb
Binary files /dev/null and b/docs/static/img/content-figure-6.png differ
diff --git a/docs/static/img/content-figure-7.png b/docs/static/img/content-figure-7.png
new file mode 100644
index 000000000..6e983c4a1
Binary files /dev/null and b/docs/static/img/content-figure-7.png differ
diff --git a/docs/static/img/content-figure-8.png b/docs/static/img/content-figure-8.png
new file mode 100644
index 000000000..b0b6a17a4
Binary files /dev/null and b/docs/static/img/content-figure-8.png differ
diff --git a/docs/static/img/content-figure-9.png b/docs/static/img/content-figure-9.png
new file mode 100644
index 000000000..94df93c8e
Binary files /dev/null and b/docs/static/img/content-figure-9.png differ
diff --git a/docs/static/img/homepage-banner-desktop.jpg b/docs/static/img/homepage-banner-desktop.jpg
new file mode 100644
index 000000000..411c121ff
Binary files /dev/null and b/docs/static/img/homepage-banner-desktop.jpg differ
diff --git a/docs/static/img/poam-figure-1.png b/docs/static/img/poam-figure-1.png
new file mode 100644
index 000000000..bd5201126
Binary files /dev/null and b/docs/static/img/poam-figure-1.png differ
diff --git a/docs/static/img/poam-figure-10.png b/docs/static/img/poam-figure-10.png
new file mode 100644
index 000000000..e44ec8cf2
Binary files /dev/null and b/docs/static/img/poam-figure-10.png differ
diff --git a/docs/static/img/poam-figure-11.png b/docs/static/img/poam-figure-11.png
new file mode 100644
index 000000000..35fd27431
Binary files /dev/null and b/docs/static/img/poam-figure-11.png differ
diff --git a/docs/static/img/poam-figure-12.png b/docs/static/img/poam-figure-12.png
new file mode 100644
index 000000000..12964043b
Binary files /dev/null and b/docs/static/img/poam-figure-12.png differ
diff --git a/docs/static/img/poam-figure-13.png b/docs/static/img/poam-figure-13.png
new file mode 100644
index 000000000..621c33d2c
Binary files /dev/null and b/docs/static/img/poam-figure-13.png differ
diff --git a/docs/static/img/poam-figure-14.png b/docs/static/img/poam-figure-14.png
new file mode 100644
index 000000000..eae8fe55b
Binary files /dev/null and b/docs/static/img/poam-figure-14.png differ
diff --git a/docs/static/img/poam-figure-15.png b/docs/static/img/poam-figure-15.png
new file mode 100644
index 000000000..4eb1aa512
Binary files /dev/null and b/docs/static/img/poam-figure-15.png differ
diff --git a/docs/static/img/poam-figure-16.png b/docs/static/img/poam-figure-16.png
new file mode 100644
index 000000000..19e4ae1be
Binary files /dev/null and b/docs/static/img/poam-figure-16.png differ
diff --git a/docs/static/img/poam-figure-17.png b/docs/static/img/poam-figure-17.png
new file mode 100644
index 000000000..9a6678e95
Binary files /dev/null and b/docs/static/img/poam-figure-17.png differ
diff --git a/docs/static/img/poam-figure-2.png b/docs/static/img/poam-figure-2.png
new file mode 100644
index 000000000..3bff0baf2
Binary files /dev/null and b/docs/static/img/poam-figure-2.png differ
diff --git a/docs/static/img/poam-figure-3.png b/docs/static/img/poam-figure-3.png
new file mode 100644
index 000000000..60ce19649
Binary files /dev/null and b/docs/static/img/poam-figure-3.png differ
diff --git a/docs/static/img/poam-figure-4.png b/docs/static/img/poam-figure-4.png
new file mode 100644
index 000000000..5c3840496
Binary files /dev/null and b/docs/static/img/poam-figure-4.png differ
diff --git a/docs/static/img/poam-figure-5.png b/docs/static/img/poam-figure-5.png
new file mode 100644
index 000000000..e0a5b4ff0
Binary files /dev/null and b/docs/static/img/poam-figure-5.png differ
diff --git a/docs/static/img/poam-figure-6.png b/docs/static/img/poam-figure-6.png
new file mode 100644
index 000000000..40dbb7c9d
Binary files /dev/null and b/docs/static/img/poam-figure-6.png differ
diff --git a/docs/static/img/poam-figure-7.png b/docs/static/img/poam-figure-7.png
new file mode 100644
index 000000000..4f2bbf5ff
Binary files /dev/null and b/docs/static/img/poam-figure-7.png differ
diff --git a/docs/static/img/poam-figure-8.png b/docs/static/img/poam-figure-8.png
new file mode 100644
index 000000000..cec24c508
Binary files /dev/null and b/docs/static/img/poam-figure-8.png differ
diff --git a/docs/static/img/poam-figure-9.png b/docs/static/img/poam-figure-9.png
new file mode 100644
index 000000000..55fd924bc
Binary files /dev/null and b/docs/static/img/poam-figure-9.png differ
diff --git a/docs/static/img/sap-figure-1.png b/docs/static/img/sap-figure-1.png
new file mode 100644
index 000000000..445ba2636
Binary files /dev/null and b/docs/static/img/sap-figure-1.png differ
diff --git a/docs/static/img/sap-figure-10.png b/docs/static/img/sap-figure-10.png
new file mode 100644
index 000000000..7f1edd1ec
Binary files /dev/null and b/docs/static/img/sap-figure-10.png differ
diff --git a/docs/static/img/sap-figure-11.png b/docs/static/img/sap-figure-11.png
new file mode 100644
index 000000000..c5d9376a4
Binary files /dev/null and b/docs/static/img/sap-figure-11.png differ
diff --git a/docs/static/img/sap-figure-12.png b/docs/static/img/sap-figure-12.png
new file mode 100644
index 000000000..40012d170
Binary files /dev/null and b/docs/static/img/sap-figure-12.png differ
diff --git a/docs/static/img/sap-figure-13.png b/docs/static/img/sap-figure-13.png
new file mode 100644
index 000000000..7b08f9a25
Binary files /dev/null and b/docs/static/img/sap-figure-13.png differ
diff --git a/docs/static/img/sap-figure-14.png b/docs/static/img/sap-figure-14.png
new file mode 100644
index 000000000..bbf1a759b
Binary files /dev/null and b/docs/static/img/sap-figure-14.png differ
diff --git a/docs/static/img/sap-figure-15.png b/docs/static/img/sap-figure-15.png
new file mode 100644
index 000000000..e5405b982
Binary files /dev/null and b/docs/static/img/sap-figure-15.png differ
diff --git a/docs/static/img/sap-figure-16.png b/docs/static/img/sap-figure-16.png
new file mode 100644
index 000000000..c46d258b5
Binary files /dev/null and b/docs/static/img/sap-figure-16.png differ
diff --git a/docs/static/img/sap-figure-17.png b/docs/static/img/sap-figure-17.png
new file mode 100644
index 000000000..6ec4bb711
Binary files /dev/null and b/docs/static/img/sap-figure-17.png differ
diff --git a/docs/static/img/sap-figure-18.png b/docs/static/img/sap-figure-18.png
new file mode 100644
index 000000000..6e1a4ebab
Binary files /dev/null and b/docs/static/img/sap-figure-18.png differ
diff --git a/docs/static/img/sap-figure-19.png b/docs/static/img/sap-figure-19.png
new file mode 100644
index 000000000..236eec4b5
Binary files /dev/null and b/docs/static/img/sap-figure-19.png differ
diff --git a/docs/static/img/sap-figure-2.png b/docs/static/img/sap-figure-2.png
new file mode 100644
index 000000000..1f9c7638d
Binary files /dev/null and b/docs/static/img/sap-figure-2.png differ
diff --git a/docs/static/img/sap-figure-20.png b/docs/static/img/sap-figure-20.png
new file mode 100644
index 000000000..620ab5a71
Binary files /dev/null and b/docs/static/img/sap-figure-20.png differ
diff --git a/docs/static/img/sap-figure-21.png b/docs/static/img/sap-figure-21.png
new file mode 100644
index 000000000..abde6ffe7
Binary files /dev/null and b/docs/static/img/sap-figure-21.png differ
diff --git a/docs/static/img/sap-figure-22.png b/docs/static/img/sap-figure-22.png
new file mode 100644
index 000000000..070d5497b
Binary files /dev/null and b/docs/static/img/sap-figure-22.png differ
diff --git a/docs/static/img/sap-figure-23.png b/docs/static/img/sap-figure-23.png
new file mode 100644
index 000000000..634329e70
Binary files /dev/null and b/docs/static/img/sap-figure-23.png differ
diff --git a/docs/static/img/sap-figure-24.png b/docs/static/img/sap-figure-24.png
new file mode 100644
index 000000000..d1cfdb880
Binary files /dev/null and b/docs/static/img/sap-figure-24.png differ
diff --git a/docs/static/img/sap-figure-3.png b/docs/static/img/sap-figure-3.png
new file mode 100644
index 000000000..0588c1618
Binary files /dev/null and b/docs/static/img/sap-figure-3.png differ
diff --git a/docs/static/img/sap-figure-4.png b/docs/static/img/sap-figure-4.png
new file mode 100644
index 000000000..f413cc850
Binary files /dev/null and b/docs/static/img/sap-figure-4.png differ
diff --git a/docs/static/img/sap-figure-5.png b/docs/static/img/sap-figure-5.png
new file mode 100644
index 000000000..09d866cf1
Binary files /dev/null and b/docs/static/img/sap-figure-5.png differ
diff --git a/docs/static/img/sap-figure-6.png b/docs/static/img/sap-figure-6.png
new file mode 100644
index 000000000..534c8ffeb
Binary files /dev/null and b/docs/static/img/sap-figure-6.png differ
diff --git a/docs/static/img/sap-figure-7.png b/docs/static/img/sap-figure-7.png
new file mode 100644
index 000000000..7f77d4f0b
Binary files /dev/null and b/docs/static/img/sap-figure-7.png differ
diff --git a/docs/static/img/sap-figure-8.png b/docs/static/img/sap-figure-8.png
new file mode 100644
index 000000000..9138831c5
Binary files /dev/null and b/docs/static/img/sap-figure-8.png differ
diff --git a/docs/static/img/sap-figure-9.png b/docs/static/img/sap-figure-9.png
new file mode 100644
index 000000000..30f556f73
Binary files /dev/null and b/docs/static/img/sap-figure-9.png differ
diff --git a/docs/static/img/sar-figure-1.png b/docs/static/img/sar-figure-1.png
new file mode 100644
index 000000000..348e37481
Binary files /dev/null and b/docs/static/img/sar-figure-1.png differ
diff --git a/docs/static/img/sar-figure-10.png b/docs/static/img/sar-figure-10.png
new file mode 100644
index 000000000..11566f40e
Binary files /dev/null and b/docs/static/img/sar-figure-10.png differ
diff --git a/docs/static/img/sar-figure-11.png b/docs/static/img/sar-figure-11.png
new file mode 100644
index 000000000..2071f85de
Binary files /dev/null and b/docs/static/img/sar-figure-11.png differ
diff --git a/docs/static/img/sar-figure-12.png b/docs/static/img/sar-figure-12.png
new file mode 100644
index 000000000..d226f7ec3
Binary files /dev/null and b/docs/static/img/sar-figure-12.png differ
diff --git a/docs/static/img/sar-figure-13.png b/docs/static/img/sar-figure-13.png
new file mode 100644
index 000000000..02d79d8f2
Binary files /dev/null and b/docs/static/img/sar-figure-13.png differ
diff --git a/docs/static/img/sar-figure-14.png b/docs/static/img/sar-figure-14.png
new file mode 100644
index 000000000..1ff46aa7a
Binary files /dev/null and b/docs/static/img/sar-figure-14.png differ
diff --git a/docs/static/img/sar-figure-15.png b/docs/static/img/sar-figure-15.png
new file mode 100644
index 000000000..6aa74517f
Binary files /dev/null and b/docs/static/img/sar-figure-15.png differ
diff --git a/docs/static/img/sar-figure-16.png b/docs/static/img/sar-figure-16.png
new file mode 100644
index 000000000..64936f737
Binary files /dev/null and b/docs/static/img/sar-figure-16.png differ
diff --git a/docs/static/img/sar-figure-17.png b/docs/static/img/sar-figure-17.png
new file mode 100644
index 000000000..c4de9d0d2
Binary files /dev/null and b/docs/static/img/sar-figure-17.png differ
diff --git a/docs/static/img/sar-figure-18.png b/docs/static/img/sar-figure-18.png
new file mode 100644
index 000000000..be16f03e1
Binary files /dev/null and b/docs/static/img/sar-figure-18.png differ
diff --git a/docs/static/img/sar-figure-2.png b/docs/static/img/sar-figure-2.png
new file mode 100644
index 000000000..3bff0baf2
Binary files /dev/null and b/docs/static/img/sar-figure-2.png differ
diff --git a/docs/static/img/sar-figure-3.png b/docs/static/img/sar-figure-3.png
new file mode 100644
index 000000000..e4e70dc6e
Binary files /dev/null and b/docs/static/img/sar-figure-3.png differ
diff --git a/docs/static/img/sar-figure-4.png b/docs/static/img/sar-figure-4.png
new file mode 100644
index 000000000..2ee4a0154
Binary files /dev/null and b/docs/static/img/sar-figure-4.png differ
diff --git a/docs/static/img/sar-figure-5.png b/docs/static/img/sar-figure-5.png
new file mode 100644
index 000000000..6ae789b3a
Binary files /dev/null and b/docs/static/img/sar-figure-5.png differ
diff --git a/docs/static/img/sar-figure-6.png b/docs/static/img/sar-figure-6.png
new file mode 100644
index 000000000..d4618cdcc
Binary files /dev/null and b/docs/static/img/sar-figure-6.png differ
diff --git a/docs/static/img/sar-figure-7.png b/docs/static/img/sar-figure-7.png
new file mode 100644
index 000000000..1f49aba3b
Binary files /dev/null and b/docs/static/img/sar-figure-7.png differ
diff --git a/docs/static/img/sar-figure-8.png b/docs/static/img/sar-figure-8.png
new file mode 100644
index 000000000..d45f13a63
Binary files /dev/null and b/docs/static/img/sar-figure-8.png differ
diff --git a/docs/static/img/sar-figure-9.png b/docs/static/img/sar-figure-9.png
new file mode 100644
index 000000000..a9fd6b266
Binary files /dev/null and b/docs/static/img/sar-figure-9.png differ
diff --git a/docs/static/img/sar-figure-cvss.png b/docs/static/img/sar-figure-cvss.png
new file mode 100644
index 000000000..c850ad37c
Binary files /dev/null and b/docs/static/img/sar-figure-cvss.png differ
diff --git a/docs/static/img/sar-figure-risk-exposure-rating.png b/docs/static/img/sar-figure-risk-exposure-rating.png
new file mode 100644
index 000000000..7cd69f577
Binary files /dev/null and b/docs/static/img/sar-figure-risk-exposure-rating.png differ
diff --git a/docs/static/img/ssp-figure-1.png b/docs/static/img/ssp-figure-1.png
new file mode 100644
index 000000000..348e37481
Binary files /dev/null and b/docs/static/img/ssp-figure-1.png differ
diff --git a/docs/static/img/ssp-figure-10.png b/docs/static/img/ssp-figure-10.png
new file mode 100644
index 000000000..ce0e87510
Binary files /dev/null and b/docs/static/img/ssp-figure-10.png differ
diff --git a/docs/static/img/ssp-figure-11.png b/docs/static/img/ssp-figure-11.png
new file mode 100644
index 000000000..7c48fd0cb
Binary files /dev/null and b/docs/static/img/ssp-figure-11.png differ
diff --git a/docs/static/img/ssp-figure-12.png b/docs/static/img/ssp-figure-12.png
new file mode 100644
index 000000000..87670dcd8
Binary files /dev/null and b/docs/static/img/ssp-figure-12.png differ
diff --git a/docs/static/img/ssp-figure-13.png b/docs/static/img/ssp-figure-13.png
new file mode 100644
index 000000000..d0851acdd
Binary files /dev/null and b/docs/static/img/ssp-figure-13.png differ
diff --git a/docs/static/img/ssp-figure-14.png b/docs/static/img/ssp-figure-14.png
new file mode 100644
index 000000000..73e7f39e0
Binary files /dev/null and b/docs/static/img/ssp-figure-14.png differ
diff --git a/docs/static/img/ssp-figure-15.png b/docs/static/img/ssp-figure-15.png
new file mode 100644
index 000000000..5e721fbee
Binary files /dev/null and b/docs/static/img/ssp-figure-15.png differ
diff --git a/docs/static/img/ssp-figure-16.png b/docs/static/img/ssp-figure-16.png
new file mode 100644
index 000000000..994c35eee
Binary files /dev/null and b/docs/static/img/ssp-figure-16.png differ
diff --git a/docs/static/img/ssp-figure-17.png b/docs/static/img/ssp-figure-17.png
new file mode 100644
index 000000000..e939a4d5f
Binary files /dev/null and b/docs/static/img/ssp-figure-17.png differ
diff --git a/docs/static/img/ssp-figure-18.png b/docs/static/img/ssp-figure-18.png
new file mode 100644
index 000000000..5f871ddeb
Binary files /dev/null and b/docs/static/img/ssp-figure-18.png differ
diff --git a/docs/static/img/ssp-figure-19.png b/docs/static/img/ssp-figure-19.png
new file mode 100644
index 000000000..d119b762d
Binary files /dev/null and b/docs/static/img/ssp-figure-19.png differ
diff --git a/docs/static/img/ssp-figure-2.png b/docs/static/img/ssp-figure-2.png
new file mode 100644
index 000000000..3bff0baf2
Binary files /dev/null and b/docs/static/img/ssp-figure-2.png differ
diff --git a/docs/static/img/ssp-figure-20.png b/docs/static/img/ssp-figure-20.png
new file mode 100644
index 000000000..01f7eb670
Binary files /dev/null and b/docs/static/img/ssp-figure-20.png differ
diff --git a/docs/static/img/ssp-figure-21.png b/docs/static/img/ssp-figure-21.png
new file mode 100644
index 000000000..4a1b2ec34
Binary files /dev/null and b/docs/static/img/ssp-figure-21.png differ
diff --git a/docs/static/img/ssp-figure-22.png b/docs/static/img/ssp-figure-22.png
new file mode 100644
index 000000000..92857ff78
Binary files /dev/null and b/docs/static/img/ssp-figure-22.png differ
diff --git a/docs/static/img/ssp-figure-23.png b/docs/static/img/ssp-figure-23.png
new file mode 100644
index 000000000..328afe8a8
Binary files /dev/null and b/docs/static/img/ssp-figure-23.png differ
diff --git a/docs/static/img/ssp-figure-24.png b/docs/static/img/ssp-figure-24.png
new file mode 100644
index 000000000..bf04e7141
Binary files /dev/null and b/docs/static/img/ssp-figure-24.png differ
diff --git a/docs/static/img/ssp-figure-25.png b/docs/static/img/ssp-figure-25.png
new file mode 100644
index 000000000..c1cae19a9
Binary files /dev/null and b/docs/static/img/ssp-figure-25.png differ
diff --git a/docs/static/img/ssp-figure-26.1.png b/docs/static/img/ssp-figure-26.1.png
new file mode 100644
index 000000000..15bd47351
Binary files /dev/null and b/docs/static/img/ssp-figure-26.1.png differ
diff --git a/docs/static/img/ssp-figure-26.2.png b/docs/static/img/ssp-figure-26.2.png
new file mode 100644
index 000000000..fa79e57e0
Binary files /dev/null and b/docs/static/img/ssp-figure-26.2.png differ
diff --git a/docs/static/img/ssp-figure-26.3.png b/docs/static/img/ssp-figure-26.3.png
new file mode 100644
index 000000000..bce12f915
Binary files /dev/null and b/docs/static/img/ssp-figure-26.3.png differ
diff --git a/docs/static/img/ssp-figure-26.4.png b/docs/static/img/ssp-figure-26.4.png
new file mode 100644
index 000000000..09ec7831c
Binary files /dev/null and b/docs/static/img/ssp-figure-26.4.png differ
diff --git a/docs/static/img/ssp-figure-26.png b/docs/static/img/ssp-figure-26.png
new file mode 100644
index 000000000..18476e93f
Binary files /dev/null and b/docs/static/img/ssp-figure-26.png differ
diff --git a/docs/static/img/ssp-figure-27.png b/docs/static/img/ssp-figure-27.png
new file mode 100644
index 000000000..bb8ebe91d
Binary files /dev/null and b/docs/static/img/ssp-figure-27.png differ
diff --git a/docs/static/img/ssp-figure-28.png b/docs/static/img/ssp-figure-28.png
new file mode 100644
index 000000000..ee0d6c7c6
Binary files /dev/null and b/docs/static/img/ssp-figure-28.png differ
diff --git a/docs/static/img/ssp-figure-29.png b/docs/static/img/ssp-figure-29.png
new file mode 100644
index 000000000..fd3a56805
Binary files /dev/null and b/docs/static/img/ssp-figure-29.png differ
diff --git a/docs/static/img/ssp-figure-3.png b/docs/static/img/ssp-figure-3.png
new file mode 100644
index 000000000..ae5395077
Binary files /dev/null and b/docs/static/img/ssp-figure-3.png differ
diff --git a/docs/static/img/ssp-figure-30.png b/docs/static/img/ssp-figure-30.png
new file mode 100644
index 000000000..6592154b2
Binary files /dev/null and b/docs/static/img/ssp-figure-30.png differ
diff --git a/docs/static/img/ssp-figure-31.png b/docs/static/img/ssp-figure-31.png
new file mode 100644
index 000000000..03694238b
Binary files /dev/null and b/docs/static/img/ssp-figure-31.png differ
diff --git a/docs/static/img/ssp-figure-32.png b/docs/static/img/ssp-figure-32.png
new file mode 100644
index 000000000..de7a9dd26
Binary files /dev/null and b/docs/static/img/ssp-figure-32.png differ
diff --git a/docs/static/img/ssp-figure-33.png b/docs/static/img/ssp-figure-33.png
new file mode 100644
index 000000000..739b3ff9b
Binary files /dev/null and b/docs/static/img/ssp-figure-33.png differ
diff --git a/docs/static/img/ssp-figure-34.png b/docs/static/img/ssp-figure-34.png
new file mode 100644
index 000000000..94950ece3
Binary files /dev/null and b/docs/static/img/ssp-figure-34.png differ
diff --git a/docs/static/img/ssp-figure-35.png b/docs/static/img/ssp-figure-35.png
new file mode 100644
index 000000000..d5f90b57f
Binary files /dev/null and b/docs/static/img/ssp-figure-35.png differ
diff --git a/docs/static/img/ssp-figure-36.png b/docs/static/img/ssp-figure-36.png
new file mode 100644
index 000000000..ca0b922e7
Binary files /dev/null and b/docs/static/img/ssp-figure-36.png differ
diff --git a/docs/static/img/ssp-figure-37.png b/docs/static/img/ssp-figure-37.png
new file mode 100644
index 000000000..0a7250964
Binary files /dev/null and b/docs/static/img/ssp-figure-37.png differ
diff --git a/docs/static/img/ssp-figure-38.png b/docs/static/img/ssp-figure-38.png
new file mode 100644
index 000000000..159cc8ad6
Binary files /dev/null and b/docs/static/img/ssp-figure-38.png differ
diff --git a/docs/static/img/ssp-figure-39.png b/docs/static/img/ssp-figure-39.png
new file mode 100644
index 000000000..8e167e0f0
Binary files /dev/null and b/docs/static/img/ssp-figure-39.png differ
diff --git a/docs/static/img/ssp-figure-4.png b/docs/static/img/ssp-figure-4.png
new file mode 100644
index 000000000..f9171f384
Binary files /dev/null and b/docs/static/img/ssp-figure-4.png differ
diff --git a/docs/static/img/ssp-figure-40.png b/docs/static/img/ssp-figure-40.png
new file mode 100644
index 000000000..343c7e4fe
Binary files /dev/null and b/docs/static/img/ssp-figure-40.png differ
diff --git a/docs/static/img/ssp-figure-41.png b/docs/static/img/ssp-figure-41.png
new file mode 100644
index 000000000..8090c3a22
Binary files /dev/null and b/docs/static/img/ssp-figure-41.png differ
diff --git a/docs/static/img/ssp-figure-42.png b/docs/static/img/ssp-figure-42.png
new file mode 100644
index 000000000..83275c83d
Binary files /dev/null and b/docs/static/img/ssp-figure-42.png differ
diff --git a/docs/static/img/ssp-figure-5.png b/docs/static/img/ssp-figure-5.png
new file mode 100644
index 000000000..4621daad5
Binary files /dev/null and b/docs/static/img/ssp-figure-5.png differ
diff --git a/docs/static/img/ssp-figure-6.png b/docs/static/img/ssp-figure-6.png
new file mode 100644
index 000000000..298909130
Binary files /dev/null and b/docs/static/img/ssp-figure-6.png differ
diff --git a/docs/static/img/ssp-figure-7.png b/docs/static/img/ssp-figure-7.png
new file mode 100644
index 000000000..4dbcceb11
Binary files /dev/null and b/docs/static/img/ssp-figure-7.png differ
diff --git a/docs/static/img/ssp-figure-8.png b/docs/static/img/ssp-figure-8.png
new file mode 100644
index 000000000..f001cd54d
Binary files /dev/null and b/docs/static/img/ssp-figure-8.png differ
diff --git a/docs/static/img/ssp-figure-9.png b/docs/static/img/ssp-figure-9.png
new file mode 100644
index 000000000..a5bd571aa
Binary files /dev/null and b/docs/static/img/ssp-figure-9.png differ
diff --git a/docs/themes/uswds b/docs/themes/uswds
new file mode 160000
index 000000000..631e1143c
--- /dev/null
+++ b/docs/themes/uswds
@@ -0,0 +1 @@
+Subproject commit 631e1143c32fbcfb8a6d7d5ed7d9e093f51a1c2b
diff --git a/src/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-baseline_profile.xml b/src/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-baseline_profile.xml
index e931d6845..441662d86 100644
--- a/src/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-baseline_profile.xml
+++ b/src/content/rev5/baselines/xml/FedRAMP_rev5_HIGH-baseline_profile.xml
@@ -1,12 +1,12 @@
-
-
+
+
FedRAMP Rev 5 High Baseline
2023-08-31T00:00:00Z
- 2023-08-31T00:00:00Z
- fedramp-2.0.0-oscal1.0.4
- 1.0.4
+ 2023-09-20T13:50:00Z
+ fedramp-2.0.0-oscal1.1.1
+ 1.1.1
Document creator
@@ -1787,7 +1787,7 @@
- personnel screening criteria – as required by specific information
+ personnel screening criteria - as required by specific information
@@ -2402,6 +2402,480 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2420,6 +2894,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2431,6 +2953,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2442,6 +3012,17 @@
+
+
+
+
+
+
@@ -2457,6 +3038,138 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2468,6 +3181,14 @@
+
+
+
+
@@ -2479,6 +3200,64 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2490,6 +3269,88 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2501,6 +3362,22 @@
+
+
+
+
+
+
+
+
@@ -2524,6 +3401,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2538,8 +3454,339 @@
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
AU-2 Additional FedRAMP Requirements and Guidance
@@ -2553,6 +3800,80 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2564,6 +3885,77 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2575,6 +3967,85 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2586,6 +4057,108 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2597,6 +4170,14 @@
+
+
+
+
@@ -2616,6 +4197,91 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2627,6 +4293,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2638,6 +4359,14 @@
+
+
+
+
@@ -2649,6 +4378,59 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2664,6 +4446,22 @@
+
+
+
+
+
+
+
+
@@ -2675,16 +4473,60 @@
-
-
-
-
- CA-7 Additional FedRAMP Requirements and Guidance
-
- Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually.
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CA-7 Additional FedRAMP Requirements and Guidance
+
+ Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually.
+
+
CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.
@@ -2694,6 +4536,113 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2705,6 +4654,24 @@
+
+
+
+
+
+
+
+
+
+
@@ -2717,6 +4684,165 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2728,6 +4854,68 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2743,6 +4931,262 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2758,11 +5202,70 @@
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+ Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2774,6 +5277,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2785,6 +5327,44 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2796,6 +5376,91 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2804,6 +5469,55 @@
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2815,6 +5529,40 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2826,6 +5574,13 @@
+
+
+
+
@@ -2834,6 +5589,111 @@
If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2849,6 +5709,163 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2860,6 +5877,48 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2875,6 +5934,140 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2886,6 +6079,39 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2897,6 +6123,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2908,6 +6178,81 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2931,6 +6276,90 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2942,6 +6371,110 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2961,10 +6494,28 @@
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+ "Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+
+
+
+
+
+
+
+
@@ -2984,6 +6535,16 @@
+
+
+
+
+
+
@@ -3003,6 +6564,28 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3018,6 +6601,25 @@
+
+
+
+
+
+
+
+
+
+
@@ -3029,6 +6631,87 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3044,18 +6727,98 @@
-
-
-
-
- IA-5 (1) Additional FedRAMP Requirements and Guidance
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ IA-5 (1) Additional FedRAMP Requirements and Guidance
Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+ For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
@@ -3064,6 +6827,98 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3075,6 +6930,13 @@
+
+
+
+
@@ -3086,6 +6948,14 @@
+
+
+
+
@@ -3097,6 +6967,14 @@
+
+
+
+
@@ -3115,6 +6993,15 @@
+
+
+
+
@@ -3126,6 +7013,31 @@
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3137,6 +7049,196 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3148,6 +7250,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3155,7 +7278,7 @@
IR-4 Additional FedRAMP Requirements and Guidance
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+ The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3174,6 +7430,69 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3189,198 +7508,3584 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- MP-3 Additional FedRAMP Requirements and Guidance
-
- Second parameter not-applicable
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- MP-4 Additional FedRAMP Requirements and Guidance
-
- The service provider defines controlled areas within facilities where the information and information system reside.
-
-
+
+
+
+
+
-
-
-
- MP-5 Additional FedRAMP Requirements and Guidance
-
- The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.
-
-
+
+
+
+
+
-
-
-
- MP-6 (1) Additional FedRAMP Requirements and Guidance
-
- Must comply with NIST SP 800-88
-
-
+
+
+
+
+
-
-
-
- MP-6 (2) Additional FedRAMP Requirements and Guidance
-
- Equipment and procedures may be tested or validated for effectiveness
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- MP-6 (3) Additional FedRAMP Requirements and Guidance
-
- Must comply with NIST SP 800-88
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MP-3 Additional FedRAMP Requirements and Guidance
+
+ Second parameter not-applicable
+
+
+
+
+
+
+
+
-
-
-
- PE-14 Additional FedRAMP Requirements and Guidance
-
+
+
+
+ MP-4 Additional FedRAMP Requirements and Guidance
+
The service provider measures temperature at server inlets and humidity levels by dew point.
+ The service provider defines controlled areas within facilities where the information and information system reside.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- PL-8 Additional FedRAMP Requirements and Guidance
-
- Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+
+
+
+ MP-5 Additional FedRAMP Requirements and Guidance
+
+ The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- PL-10 Additional FedRAMP Requirements and Guidance
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MP-6 (1) Additional FedRAMP Requirements and Guidance
+
Select the appropriate FedRAMP Baseline
+ Must comply with NIST SP 800-88
+
+
+
+
-
-
-
- RA-3 Additional FedRAMP Requirements and Guidance
-
+
+
+
+ MP-6 (2) Additional FedRAMP Requirements and Guidance
+
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-
-
- Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+ Equipment and procedures may be tested or validated for effectiveness
+
+
+
+
-
-
-
- RA-5 Additional FedRAMP Requirements and Guidance
-
- See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-
-
- an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-
-
- If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-
-
- to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-
-
- Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
- Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
- Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
+
+
+
+ MP-6 (3) Additional FedRAMP Requirements and Guidance
+
+ Must comply with NIST SP 800-88
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PE-14 Additional FedRAMP Requirements and Guidance
+
+ The service provider measures temperature at server inlets and humidity levels by dew point.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PL-8 Additional FedRAMP Requirements and Guidance
+
+ Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PL-10 Additional FedRAMP Requirements and Guidance
+
+ Select the appropriate FedRAMP Baseline
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-3 Additional FedRAMP Requirements and Guidance
+
+ Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+
+
+ Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-5 Additional FedRAMP Requirements and Guidance
+
+ See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+
+
+ an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+
+
+ If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+
+
+ to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+
+
+ Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+ Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+ Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-5(8) Additional FedRAMP Requirement
+
+ This enhancement is required for all high (or critical) vulnerability scan findings.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ SA-4 Additional FedRAMP Requirements and Guidance
+
+ The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
+
+
+ The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
+ See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ SA-10 Additional FedRAMP Requirements and Guidance
+
+ track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ SA-11(1) Additional FedRAMP Requirements
+
+ The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.
+ If Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- RA-5(8) Additional FedRAMP Requirement
-
- This enhancement is required for all high (or critical) vulnerability scan findings.
-
-
+
+
+
+
+
-
-
-
- SA-4 Additional FedRAMP Requirements and Guidance
-
- The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
-
-
- The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
- See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
-
-
+
+
+
+
+
-
-
-
- SA-10 Additional FedRAMP Requirements and Guidance
-
- track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.
-
-
+
+
+
+
+
-
-
-
- SA-11(1) Additional FedRAMP Requirements
-
- The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.
- If Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3393,6 +11098,212 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3404,6 +11315,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3412,7 +11363,7 @@
For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
-
+
For clarity, this control applies to all data in transit. Examples include the following data flows:
- Crossing the system boundary
@@ -3421,9 +11372,9 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance
- - Flows from management tools required for their work – e.g. log collection, scanning, etc.
+ - Flows from management tools required for their work - e.g. log collection, scanning, etc.
-
+
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
FedRAMP-Defined Assignment / Selection Parameters
SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
@@ -3432,21 +11383,33 @@
SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
-
+
Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
-
- Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
-
+
+ Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+
Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
-
+
CNSSI No.7003 can be accessed here:
https://www.dcsa.mil/Portals/91/documents/ctp/nao/CNSSI_7003_PDS_September_2015.pdf
-
+
DHS Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies can be accessed here:
https://us-cert.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_Defense_in_Depth_Strategies_S508C.pdf
+
+
+
+
+
+
@@ -3458,7 +11421,7 @@
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+ See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
@@ -3471,6 +11434,15 @@
+
+
+
+
@@ -3490,6 +11462,18 @@
+
+
+
+
+
+
@@ -3505,7 +11489,7 @@
- Generation of one time passwords (OTPs) for MFA
- Protocols such as TLS, SSH, and HTTPS
-
+
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
@@ -3535,6 +11519,26 @@
+
+
+
+
+
+
+
+
+
+
@@ -3546,6 +11550,23 @@
+
+
+
+
+
+
+
+
@@ -3573,6 +11594,30 @@
+
+
+
+
+
+
+
+
+
+
@@ -3604,58 +11649,326 @@
+
+
+
+
+
+
+
+
+
+
+ SC-28 Additional FedRAMP Requirements and Guidance
+
+ The organization supports the capability to use cryptographic mechanisms to protect information at rest.
+
+
+ When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
+
+
+ Note that this enhancement requires the use of cryptography in accordance with SC-13.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ SC-28 (1) Additional FedRAMP Requirements and Guidance
+
+ Organizations should select a mode of protection that is targeted towards the relevant threat scenarios.
+ Examples:
+ A. Organizations may apply full disk encryption (FDE) to a mobile device where the primary threat is loss of the device while storage is locked.
+ B. For a database application housing data for a single customer, encryption at the file system level would often provide more protection than FDE against the more likely threat of an intruder on the operating system accessing the storage.
+ C. For a database application housing data for multiple customers, encryption with unique keys for each customer at the database record level may be more appropriate.
+
+
+
+
+
+
+
+
+
+
+
+ SC-45(1) Additional FedRAMP Requirements and Guidance
+
+ The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server.
+
+
+ The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.
+
+
+ Synchronization of system clocks improves the accuracy of log analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
- SC-28 Additional FedRAMP Requirements and Guidance
-
- The organization supports the capability to use cryptographic mechanisms to protect information at rest.
-
-
- When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
-
-
- Note that this enhancement requires the use of cryptography in accordance with SC-13.
-
-
+
+
+
+
+
-
-
-
- SC-28 (1) Additional FedRAMP Requirements and Guidance
-
- Organizations should select a mode of protection that is targeted towards the relevant threat scenarios.
- Examples:
- A. Organizations may apply full disk encryption (FDE) to a mobile device where the primary threat is loss of the device while storage is locked.
- B. For a database application housing data for a single customer, encryption at the file system level would often provide more protection than FDE against the more likely threat of an intruder on the operating system accessing the storage.
- C. For a database application housing data for multiple customers, encryption with unique keys for each customer at the database record level may be more appropriate.
-
-
+
+
+
+
+
+
+
+
+
-
-
-
- SC-45(1) Additional FedRAMP Requirements and Guidance
-
- The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server.
-
-
- The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.
-
-
- Synchronization of system clocks improves the accuracy of log analysis.
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3668,6 +11981,243 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3679,6 +12229,15 @@
+
+
+
+
@@ -3690,6 +12249,17 @@
+
+
+
+
+
+
@@ -3699,6 +12269,164 @@
Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3715,6 +12443,22 @@
+
+
+
+
+
+
+
+
@@ -3726,6 +12470,198 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3737,6 +12673,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3748,6 +12724,14 @@
+
+
+
+
@@ -3759,6 +12743,14 @@
+
+
+
+
@@ -3770,6 +12762,24 @@
+
+
+
+
+
+
+
+
+
+
@@ -3781,14 +12791,38 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
diff --git a/src/content/rev5/baselines/xml/FedRAMP_rev5_LI-SaaS-baseline_profile.xml b/src/content/rev5/baselines/xml/FedRAMP_rev5_LI-SaaS-baseline_profile.xml
index e2841bd5e..2d03562a6 100644
--- a/src/content/rev5/baselines/xml/FedRAMP_rev5_LI-SaaS-baseline_profile.xml
+++ b/src/content/rev5/baselines/xml/FedRAMP_rev5_LI-SaaS-baseline_profile.xml
@@ -1,12 +1,12 @@
-
+
FedRAMP Rev 5 Tailored Low Impact Software as a Service (LI-SaaS) Baseline
2023-08-31T00:00:00Z
- 2023-08-31T00:00:00Z
- fedramp-2.0.0-oscal1.0.4
- 1.0.4
+ 2023-09-21T14:45:00Z
+ fedramp-2.0.0-oscal1.1.1
+ 1.1.1
Document creator
@@ -1316,7 +1316,7 @@
-
@@ -1336,28 +1336,28 @@
-
Determine if the organization defines information system account types to be identified and selected to support organizational missions/business functions.
-
Access control policy; procedures addressing account management; security plan; information system design documentation; information system configuration settings and associated documentation; list of active system accounts along with the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled information system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; information system monitoring records; information system audit records; other relevant documents or records.
-
Organizational personnel with account management responsibilities; system/network administrators; organizational personnel with information security responsibilities.
-
Organizational processes for account management on the information system; automated mechanisms for implementing account management.
@@ -1370,7 +1370,7 @@
-
@@ -1380,8 +1380,8 @@
-
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication.
@@ -1392,7 +1392,7 @@
-
FED - This is related to agency data and agency policy solution.
@@ -1403,7 +1403,7 @@
-
FED - This is related to agency data and agency policy solution.
@@ -1415,7 +1415,7 @@
-
@@ -1424,7 +1424,7 @@
-
NSO - All access to Cloud SaaS are via web services and/or API. The device accessed from or whether via wired or wireless connection is out of scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2[1]).
@@ -1436,7 +1436,7 @@
-
NSO - All access to Cloud SaaS are via web service and/or API. The device accessed from is out of the scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2 [1]).
@@ -1447,7 +1447,7 @@
-
@@ -1457,7 +1457,7 @@
-
@@ -1466,7 +1466,7 @@
-
@@ -1475,7 +1475,7 @@
-
@@ -1484,7 +1484,7 @@
-
@@ -1493,7 +1493,7 @@
-
@@ -1502,7 +1502,7 @@
-
@@ -1511,7 +1511,7 @@
-
@@ -1520,7 +1520,7 @@
-
@@ -1529,7 +1529,7 @@
-
@@ -1537,7 +1537,7 @@
-
NSO - Loss of availability of the audit data has been determined to have little or no impact to government business/mission needs.
@@ -1549,7 +1549,7 @@
-
@@ -1559,7 +1559,7 @@
-
@@ -1567,7 +1567,7 @@
-
@@ -1575,7 +1575,7 @@
-
@@ -1584,7 +1584,7 @@
-
NSO - Loss of availability of the audit data has been determined as little or no impact to government business/mission needs.
@@ -1595,7 +1595,7 @@
-
@@ -1604,7 +1604,7 @@
-
@@ -1614,7 +1614,7 @@
-
@@ -1622,7 +1622,7 @@
-
@@ -1632,8 +1632,8 @@
-
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
@@ -1645,7 +1645,7 @@
-
Attestation - for compliance with FedRAMP Tailored LI-SaaS Continuous Monitoring Requirements.
@@ -1657,7 +1657,7 @@
-
@@ -1667,7 +1667,7 @@
-
@@ -1677,7 +1677,7 @@
-
@@ -1687,7 +1687,7 @@
-
@@ -1697,8 +1697,8 @@
-
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
@@ -1710,7 +1710,7 @@
-
@@ -1718,7 +1718,7 @@
-
@@ -1727,7 +1727,7 @@
-
@@ -1737,7 +1737,7 @@
-
@@ -1747,7 +1747,7 @@
-
Required - Specifically include details of least functionality.
@@ -1773,7 +1773,7 @@
-
@@ -1783,7 +1783,7 @@
-
@@ -1791,7 +1791,7 @@
-
NSO- Not directly related to protection of the data.
@@ -1802,7 +1802,7 @@
-
NSO - Boundary is specific to SaaS environment; all access is via web services; users' machine or internal network are not contemplated. External services (SA-9), internal connection (CA-9), remote access (AC-17), and secure access (SC-12 and SC-13), and privileged authentication (IA-2[1]) are considerations.
@@ -1814,7 +1814,7 @@
-
@@ -1823,7 +1823,7 @@
-
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
@@ -1835,7 +1835,7 @@
-
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
@@ -1847,7 +1847,7 @@
-
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
@@ -1859,7 +1859,7 @@
-
@@ -1867,7 +1867,7 @@
-
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
@@ -1879,7 +1879,7 @@
-
@@ -1887,8 +1887,8 @@
-
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication - specifically include description of management of service accounts.
@@ -1900,7 +1900,7 @@
-
IA-2(1) Additional FedRAMP Requirements and Guidance
@@ -1913,9 +1913,12 @@
+
-
@@ -1925,7 +1928,7 @@
-
@@ -1934,13 +1937,13 @@
-
Determine if the information system:
- Accepts PIV credentials.
@@ -1955,7 +1958,7 @@
-
@@ -1964,7 +1967,7 @@
-
@@ -1973,7 +1976,7 @@
-
@@ -1982,15 +1985,18 @@
-
+
-
@@ -1998,7 +2004,7 @@
-
@@ -2007,8 +2013,8 @@
-
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
@@ -2020,8 +2026,8 @@
-
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
@@ -2032,7 +2038,7 @@
-
@@ -2041,7 +2047,7 @@
-
@@ -2050,7 +2056,7 @@
-
@@ -2059,7 +2065,7 @@
-
@@ -2068,7 +2074,7 @@
-
@@ -2076,7 +2082,7 @@
-
@@ -2086,7 +2092,7 @@
-
@@ -2094,7 +2100,7 @@
-
@@ -2103,7 +2109,7 @@
-
Attestation - Specifically attest to US-CERT compliance.
@@ -2115,7 +2121,7 @@
-
@@ -2124,8 +2130,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2137,7 +2143,7 @@
-
@@ -2146,8 +2152,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2159,7 +2165,7 @@
-
@@ -2168,8 +2174,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2181,8 +2187,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2194,8 +2200,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2207,7 +2213,7 @@
-
@@ -2217,8 +2223,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2231,8 +2237,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2245,8 +2251,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2259,8 +2265,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2272,8 +2278,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2285,8 +2291,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2298,8 +2304,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2320,8 +2326,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2333,8 +2339,8 @@
-
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
@@ -2346,7 +2352,7 @@
-
@@ -2356,7 +2362,7 @@
-
@@ -2364,7 +2370,7 @@
-
@@ -2373,7 +2379,7 @@
-
@@ -2383,7 +2389,7 @@
-
@@ -2392,7 +2398,7 @@
-
@@ -2401,7 +2407,7 @@
-
@@ -2410,7 +2416,7 @@
-
@@ -2418,7 +2424,7 @@
-
@@ -2427,7 +2433,7 @@
-
@@ -2436,7 +2442,7 @@
-
@@ -2445,7 +2451,7 @@
-
@@ -2454,7 +2460,7 @@
-
@@ -2463,7 +2469,7 @@
-
Attestation - Specifically stating that any third-party security personnel are treated as CSP employees.
@@ -2474,7 +2480,7 @@
-
@@ -2483,7 +2489,7 @@
-
@@ -2492,7 +2498,7 @@
-
@@ -2503,7 +2509,7 @@
-
@@ -2512,7 +2518,7 @@
-
@@ -2521,7 +2527,7 @@
-
@@ -2531,7 +2537,7 @@
-
@@ -2541,7 +2547,7 @@
-
@@ -2551,7 +2557,7 @@
-
@@ -2561,7 +2567,7 @@
-
@@ -2570,7 +2576,7 @@
-
@@ -2578,7 +2584,7 @@
-
@@ -2586,7 +2592,7 @@
-
@@ -2594,7 +2600,7 @@
-
@@ -2603,7 +2609,7 @@
-
@@ -2611,7 +2617,7 @@
-
@@ -2620,7 +2626,7 @@
-
@@ -2629,7 +2635,7 @@
-
@@ -2639,7 +2645,7 @@
-
@@ -2648,7 +2654,7 @@
-
@@ -2657,8 +2663,8 @@
-
Condition: If availability is a requirement, define protections in place as per control requirement.
@@ -2670,7 +2676,7 @@
-
@@ -2680,7 +2686,7 @@
-
@@ -2690,7 +2696,7 @@
-
@@ -2699,7 +2705,7 @@
-
@@ -2709,8 +2715,8 @@
-
Condition: If implementing need to detail how they meet it or don't meet it.
@@ -2721,7 +2727,7 @@
-
NSO - Not directly related to the security of the SaaS.
@@ -2732,7 +2738,7 @@
-
@@ -2740,7 +2746,7 @@
-
@@ -2748,7 +2754,7 @@
-
@@ -2758,7 +2764,7 @@
-
@@ -2768,7 +2774,7 @@
-
@@ -2776,7 +2782,7 @@
-
@@ -2785,7 +2791,7 @@
-
@@ -2795,7 +2801,7 @@
-
@@ -2805,7 +2811,7 @@
-
@@ -2815,7 +2821,7 @@
-
@@ -2823,7 +2829,7 @@
-
@@ -2831,7 +2837,7 @@
-
Attestation - Specifically related to US-CERT and FedRAMP communications procedures.
@@ -2843,7 +2849,7 @@
-
@@ -2852,7 +2858,7 @@
-
@@ -2861,7 +2867,7 @@
-
@@ -2870,7 +2876,7 @@
-
@@ -2879,7 +2885,7 @@
-
@@ -2888,7 +2894,7 @@
-
@@ -2897,7 +2903,7 @@
-
@@ -2906,7 +2912,7 @@
-
@@ -2915,7 +2921,7 @@
-
@@ -2924,7 +2930,7 @@
-
@@ -2933,7 +2939,7 @@
-
diff --git a/src/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline_profile.xml b/src/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline_profile.xml
index d75731d2b..fa0fffa43 100644
--- a/src/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline_profile.xml
+++ b/src/content/rev5/baselines/xml/FedRAMP_rev5_LOW-baseline_profile.xml
@@ -1,12 +1,12 @@
-
-
+
+
FedRAMP Rev 5 Low Baseline
2023-08-31T00:00:00Z
- 2023-08-31T00:00:00Z
- fedramp-2.0.0-oscal1.0.4
- 1.0.4
+ 2023-09-20T13:50:00Z
+ fedramp-2.0.0-oscal1.1.1
+ 1.1.1
Document creator
@@ -1310,8 +1310,303 @@
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1323,6 +1618,22 @@
+
+
+
+
+
+
+
+
@@ -1346,6 +1657,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1362,6 +1712,22 @@
+
+
+
+
+
+
+
+
@@ -1370,6 +1736,272 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1385,6 +2017,114 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1397,6 +2137,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1417,8 +2184,122 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1430,12 +2311,102 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
CA-5 Additional FedRAMP Requirements and Guidance
@@ -1448,6 +2419,22 @@
+
+
+
+
+
+
+
+
@@ -1459,6 +2446,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1479,8 +2510,105 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1491,9 +2619,165 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1504,8 +2788,56 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1521,11 +2853,45 @@
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+ Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1537,6 +2903,24 @@
+
+
+
+
+
+
+
+
+
+
@@ -1549,8 +2933,122 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1566,6 +3064,104 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1578,6 +3174,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1594,6 +3221,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1617,8 +3284,107 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1633,7 +3399,7 @@
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+ "Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+
+
+
+
+
+
+
+
@@ -1660,6 +3444,16 @@
+
+
+
+
+
+
@@ -1679,6 +3473,16 @@
+
+
+
+
+
+
@@ -1691,8 +3495,69 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1708,26 +3573,165 @@
-
-
-
-
- IA-5 (1) Additional FedRAMP Requirements and Guidance
-
- Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
-
-
- For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
- For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ IA-5 (1) Additional FedRAMP Requirements and Guidance
+
+ Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
+
+
+ For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+ For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
+
+
Note that (c) and (d) require the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1747,16 +3751,188 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
IR-4 Additional FedRAMP Requirements and Guidance
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+ The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1776,6 +4007,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1792,6 +4054,79 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1801,6 +4136,432 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1811,13 +4572,535 @@
+
+
+
+
+
+
+
+
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
PL-8 Additional FedRAMP Requirements and Guidance
@@ -1826,6 +5109,68 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1838,85 +5183,1210 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-3 Additional FedRAMP Requirements and Guidance
+
+ Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+
+
+ Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-5 Additional FedRAMP Requirements and Guidance
+
+ See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+
+
+ an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+
+
+ If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+
+
+ to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+
+
+ Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+ Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+ Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ SA-4 Additional FedRAMP Requirements and Guidance
+
+ The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
+
+
+ The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
+ See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
- RA-3 Additional FedRAMP Requirements and Guidance
-
- Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-
-
- Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
-
-
+
+
+
+
+
-
-
-
-
-
- RA-5 Additional FedRAMP Requirements and Guidance
-
- See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-
-
- an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-
-
- If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-
-
- to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-
-
- Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
- Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
- Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
-
-
+
+
+
+
+
-
-
-
-
-
-
-
- SA-4 Additional FedRAMP Requirements and Guidance
-
- The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
-
-
- The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
- See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
-
-
+
+
+
+
+
+
+
+
+
-
-
-
-
@@ -1927,6 +6397,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1944,7 +6458,7 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance
- - Flows from management tools required for their work – e.g. log collection, scanning, etc.
+ - Flows from management tools required for their work - e.g. log collection, scanning, etc.
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
@@ -1958,7 +6472,7 @@
Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
- Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+ Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
@@ -1970,6 +6484,18 @@
+
+
+
+
+
+
@@ -1981,7 +6507,7 @@
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+ See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
@@ -1994,6 +6520,15 @@
+
+
+
+
@@ -2013,6 +6548,18 @@
+
+
+
+
+
+
@@ -2059,6 +6606,26 @@
+
+
+
+
+
+
+
+
+
+
@@ -2070,6 +6637,23 @@
+
+
+
+
+
+
+
+
@@ -2093,6 +6677,30 @@
+
+
+
+
+
+
+
+
+
+
@@ -2126,6 +6734,18 @@
+
+
+
+
+
+
@@ -2145,6 +6765,18 @@
+
+
+
+
+
+
@@ -2160,10 +6792,180 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2175,6 +6977,77 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2184,10 +7057,216 @@
Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2199,8 +7278,48 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2212,6 +7331,14 @@
+
+
+
+
@@ -2225,17 +7352,38 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
diff --git a/src/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml b/src/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml
index f6caa4ce5..6782bf176 100644
--- a/src/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml
+++ b/src/content/rev5/baselines/xml/FedRAMP_rev5_MODERATE-baseline_profile.xml
@@ -1,12 +1,12 @@
-
-
+
+
FedRAMP Rev 5 Moderate Baseline
2023-08-31T00:00:00Z
- 2023-08-31T00:00:00Z
- fedramp-2.0.0-oscal1.0.4
- 1.0.4
+ 2023-09-20T13:50:00Z
+ fedramp-2.0.0-oscal1.1.1
+ 1.1.1
Document creator
@@ -1495,7 +1495,7 @@
- personnel screening criteria – as required by specific information
+ personnel screening criteria - as required by specific information
@@ -2070,6 +2070,432 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2089,6 +2515,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2101,6 +2575,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2112,6 +2634,17 @@
+
+
+
+
+
+
@@ -2128,8 +2661,140 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2140,6 +2805,64 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2151,8 +2874,60 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2164,6 +2939,22 @@
+
+
+
+
+
+
+
+
@@ -2187,6 +2978,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2206,6 +3036,22 @@
+
+
+
+
+
+
+
+
@@ -2214,32 +3060,427 @@
-
-
-
-
- AU-2 Additional FedRAMP Requirements and Guidance
-
- Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
-
-
- Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
-
-
+
+
+
-
-
-
-
- AU-3 (1) Additional FedRAMP Requirements and Guidance
-
- For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ AU-2 Additional FedRAMP Requirements and Guidance
+
+ Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
+
+
+ Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ AU-3 (1) Additional FedRAMP Requirements and Guidance
+
+ For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2252,6 +3493,33 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2275,8 +3543,187 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2288,6 +3735,61 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2299,10 +3801,53 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2318,6 +3863,22 @@
+
+
+
+
+
+
+
+
@@ -2329,6 +3890,50 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2349,8 +3954,115 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2362,6 +4074,24 @@
+
+
+
+
+
+
+
+
+
+
@@ -2374,9 +4104,168 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2388,6 +4277,68 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2404,9 +4355,155 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2422,11 +4519,57 @@
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+ Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2438,8 +4581,47 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2450,8 +4632,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2463,8 +4683,73 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2473,6 +4758,55 @@
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2485,6 +4819,40 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2497,9 +4865,102 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2515,6 +4976,134 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2527,6 +5116,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2543,19 +5163,155 @@
-
-
-
-
- CP-7 Additional FedRAMP Requirements and Guidance
-
- The service provider defines a time period consistent with the recovery time objectives and business impact analysis.
-
-
+
+
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ CP-7 Additional FedRAMP Requirements and Guidance
+
+ The service provider defines a time period consistent with the recovery time objectives and business impact analysis.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
CP-7 (1) Additional FedRAMP Requirements and Guidance
@@ -2565,6 +5321,39 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2576,6 +5365,45 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2599,8 +5427,54 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2612,8 +5486,102 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2632,10 +5600,28 @@
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+ "Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+
+
+
+
+
+
+
+
@@ -2655,6 +5641,16 @@
+
+
+
+
+
+
@@ -2674,6 +5670,28 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2689,6 +5707,25 @@
+
+
+
+
+
+
+
+
+
+
@@ -2700,8 +5737,89 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2717,6 +5835,86 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2728,7 +5926,7 @@
For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+ For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
@@ -2737,6 +5935,98 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2748,6 +6038,13 @@
+
+
+
+
@@ -2769,6 +6066,15 @@
+
+
+
+
@@ -2781,6 +6087,31 @@
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2796,9 +6127,180 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2810,6 +6312,27 @@
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2817,7 +6340,7 @@
IR-4 Additional FedRAMP Requirements and Guidance
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+ The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
IR-6 Additional FedRAMP Requirements and Guidance
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2855,10 +6509,418 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2869,8 +6931,122 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2881,6 +7057,20 @@
+
+
+
+
+
+
+
+
@@ -2892,6 +7082,42 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2903,6 +7129,43 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2912,52 +7175,1345 @@
-
-
-
- PE-14 Additional FedRAMP Requirements and Guidance
-
- The service provider measures temperature at server inlets and humidity levels by dew point.
-
-
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
- PL-8 Additional FedRAMP Requirements and Guidance
-
- Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-
-
+
+
+
+
+
+
+
+
+
-
-
-
-
- PL-10 Additional FedRAMP Requirements and Guidance
-
- Select the appropriate FedRAMP Baseline
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PE-14 Additional FedRAMP Requirements and Guidance
+
+ The service provider measures temperature at server inlets and humidity levels by dew point.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PL-8 Additional FedRAMP Requirements and Guidance
+
+ Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PL-10 Additional FedRAMP Requirements and Guidance
+
+ Select the appropriate FedRAMP Baseline
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -2972,45 +8528,631 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RA-5 Additional FedRAMP Requirements and Guidance
+
+ See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+
+
+ an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+
+
+ If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+
+
+ to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+
+
+ Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+ Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+ Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
- RA-5 Additional FedRAMP Requirements and Guidance
-
- See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-
-
- an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-
-
- If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-
-
- to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-
-
- Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
- Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
- Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
@@ -3026,6 +9168,93 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3038,6 +9267,47 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3050,10 +9320,486 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3064,8 +9810,167 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3076,6 +9981,46 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3084,7 +10029,7 @@
For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
-
+
For clarity, this control applies to all data in transit. Examples include the following data flows:
- Crossing the system boundary
@@ -3093,9 +10038,9 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance
- - Flows from management tools required for their work – e.g. log collection, scanning, etc.
+ - Flows from management tools required for their work - e.g. log collection, scanning, etc.
-
+
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
FedRAMP-Defined Assignment / Selection Parameters
SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
@@ -3104,21 +10049,33 @@
SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
-
+
Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
-
- Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
-
+
+ Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+
Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
-
+
CNSSI No.7003 can be accessed here:
https://www.dcsa.mil/Portals/91/documents/ctp/nao/CNSSI_7003_PDS_September_2015.pdf
-
+
DHS Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies can be accessed here:
https://us-cert.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_Defense_in_Depth_Strategies_S508C.pdf
+
+
+
+
+
+
@@ -3130,7 +10087,7 @@
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+ See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
@@ -3143,6 +10100,15 @@
+
+
+
+
@@ -3162,6 +10128,18 @@
+
+
+
+
+
+
@@ -3178,7 +10156,7 @@
- Generation of one time passwords (OTPs) for MFA
- Protocols such as TLS, SSH, and HTTPS
-
+
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
@@ -3208,6 +10186,26 @@
+
+
+
+
+
+
+
+
+
+
@@ -3219,6 +10217,23 @@
+
+
+
+
+
+
+
+
@@ -3242,6 +10257,30 @@
+
+
+
+
+
+
+
+
+
+
@@ -3275,6 +10314,18 @@
+
+
+
+
+
+
@@ -3294,6 +10345,18 @@
+
+
+
+
+
+
@@ -3309,6 +10372,15 @@
+
+
+
+
@@ -3329,11 +10401,246 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3345,8 +10652,167 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3357,6 +10823,15 @@
+
+
+
+
@@ -3369,10 +10844,126 @@
Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3388,6 +10979,22 @@
+
+
+
+
+
+
+
+
@@ -3400,10 +11007,202 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3415,8 +11214,48 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -3428,6 +11267,14 @@
+
+
+
+
@@ -3440,6 +11287,14 @@
+
+
+
+
@@ -3455,16 +11310,38 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
- , \
- Crossing the system boundary @@ -3421,9 +11372,9 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance -
- Flows from management tools required for their work – e.g. log collection, scanning, etc. +
- Flows from management tools required for their work - e.g. log collection, scanning, etc.
- Generation of one time passwords (OTPs) for MFA
- Protocols such as TLS, SSH, and HTTPS - +
- Accepts PIV credentials. @@ -1955,7 +1958,7 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance -
- Flows from management tools required for their work – e.g. log collection, scanning, etc. +
- Flows from management tools required for their work - e.g. log collection, scanning, etc.
- Crossing the system boundary @@ -3093,9 +10038,9 @@
- Replication between availability zones
- Transmission of backups to storage
- From a load balancer to a compute instance -
- Flows from management tools required for their work – e.g. log collection, scanning, etc. +
- Flows from management tools required for their work - e.g. log collection, scanning, etc.
- Generation of one time passwords (OTPs) for MFA
- Protocols such as TLS, SSH, and HTTPS - +
- , \
, or \
| Cell A1 | +Cell B1 | +
| Cell A2 | +Cell B2 | +
Big Header
+More detail
+Policy Document.
+[EXAMPLE]An example component representing a policy.
+Describe how statement a is satisfied by this policy.
+Policy Document.
+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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_ +- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_ +- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_ +{{
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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_ +- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_ +- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_ +{{
Description
FedRAMP Logo
+{{
Description
Peparer Logo
+{{
Description
CSP Logo
+{{
The CSP for FedRAMP SSP, SAP, SAR, and POA&M.
CSP Logo
+ +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. + +{{
Initial publication.
Updated for annual assessment.
+{{
+{{
+{{
+{{
+{{
The primary authorization boundary diagram.
+Set system-characteristics/authorization-boundary/diagram/link/@href = "#diag-boundary-1"
+{{
at least every six months
+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.
+The organization that prepared this SSP.
+The organization for which this SSP was prepared
++{{
This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAP (rev 4 or rev 5) this OSCAL document is for.
+The FedRAMP Extension, "POAM-ID" captures the traditional CSP-assigned unique POA&M identifier.
+Optional pointer to the raw scanner output that generated + this POA&M entry.
A virtual component.
+An instance of the above component.
This is the Weakness Description.
This is the tool-provided statement about the identified risk.
+If no risk statement from tool, set to 'No Risk Statement'.
+This is the Weakness Description.
This is the tool-provided statement about the identified risk.
+If no risk statement from tool, set to 'No Risk Statement'.
+Tool-provided recommendation.
Assessor-provided recommendation.
Describe the CSP's intended approach to remediating this risk.
+Describe required resources.
Describe the CSP's intended approach to remediating this risk.
+Describe required resources.
Optional description
Optional description
Description of the result of the vendor check-in.
+Describe what action(s) the CSP took to close the risk.
+[EXAMPLE]Applied patch. Vulnerability no longer found in subsequent + scan.
+Describe the false positive here.
A screen shot showing the setting is correct
Vendor detail describing why this happens.
Vulnerability description
Risk statement.
Provide the justification for the OR.
A screen shot showing impact when patch is applied.
+Vendor detail describing why this happens.
Vulnerability description
Risk statement.
+{{
Describe the risk adjustment evidence here.
+Explain why likelihood was adjusted.
+Explain why impact was adjusted.
+Describe mitigating factor
Describe the vendor dependency here.
A screen shot showing the setting is correct
Vendor detail describing why this happens.
Vulnerability description
Risk statement.
Describe the closure evidence here.
A screen shot showing the setting is correct
Vendor detail describing why this happens.
Describe what action(s) the CSP took to close the risk.
+[EXAMPLE]Applied patch. Vulnerability no longer found in subsequent scan.
+Briefly describe the system. This will appear in the SAR.
+This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAP (rev 4 or rev 5) this OSCAL document is for.
+Insert text from FedRAMP template
+Insert text from FedRAMP template
+Insert text from FedRAMP template
+This SAP has been developed by [IA Name] and is for [an initial assessment/an annual assessment/an annual assessment and significant change assessment/a significant change assessment] of the [CSP Name], [CSO Name]. The SAP provides the goals for the assessment and details how the assessment will be conducted.
+The FedRAMP-applicable laws, regulations, standards and guidance is included in the [CSO Name] SSP section – System Security Plan Approvals. Additionally, in Appendix L of the SSP, the [CSP Name] has included laws, regulations, standards, and guidance that apply specifically to this system.
+A description of the locations.
+Briefly describe the components at this location.
+Briefly describe the components at this location.
+A description of the included component.
Description of the included inventory.
Description of the included inventory.
A Windows laptop, not defined in the SSP inventory.
+A subnet not defined in the SSP inventory.
Description of the included inventory.
Describe this web application test.
A description of the included roles.
+A description of an excluded role.
+This SAP is based on
The
The
The
Security controls that ... on these security controls.
+[IA Name] will ...
+[IA Name] data gathering activities will ...
+The sampling methodology for evidence/artifact gathering, related to controls assessment, is described in Appendix B.
+[IA Name] [will/will not] ...
+The Penetration Test Plan and Methodology is attached in Appendix C.
+The sampling methodology for evidence/artifact gathering, related to controls assessment, is described in Appendix B.
+[IA Name] [will/will not] ...
+Include all controls in the baseline.
+Then exclude any specific controls if necessary.
+Provide rationale/justification for control exclusion here.
+Describe the purpose of the tool here.
+Describe the purpose of the tool here.
+Description of the manual test
+Describe test step #1
Describe test step #2
Describe test step #3
We will login as a customer ...cut... browser to various URLs
+| Test ID | +Test Name | +Description | +
|---|---|---|
| [Insert test ID] | +[Insert test name] | +[Insert test description text] | +
optional description here
+optional description here
+Cites assessment laptop.
Cites assessment laptop.
Cites Vulnerability Scanning Tool
Cites Database Scanning Tool
Any testing will be performed according to terms and conditions designed to minimize risk exposure that could occur during security testing.
+A disclosure statement
+The following activities are to be included as part of the FedRAMP assessment.
+Port scans and other network service interaction and queries
+Network sniffing, traffic monitoring, traffic analysis, and host discovery
+Attempted logins or other use of systems, with any account name/password
+Attempted structured query language (SQL) injection and other forms of input + parameter testing
+The following activities are explicitly excluded from the assessment.
+Changes to assigned user passwords
+Modification of user files or system files
+Telephone modem probes and scans (active and passive)
+Intentional viewing of [CSP Name] staff email, Internet caches, and/or personnel + cookie files
+Denial of service attacks
+Exploits that will introduce new weaknesses to the system
+Intentional introduction of malicious code (viruses, Trojans, worms, etc.)
+Signed SAP
Control Scope
Control Objective Scope
Embed or reference copies of the sampling methodology for security controls assessment and vulnerability scanning (if applicable).
+. . . /p> + +
| Include | +Mandatory Attack Vectors | +Include | +Threat Models | +Include | +Attack Models | +
|---|---|---|---|---|---|
| x | +External to Corporate | ++ | Internet based (untrusted) | ++ | Enterprise | +
| Role Name | +Test User ID | +Associated Functions | +
|---|---|---|
This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SAR (rev 4 or rev 5) this OSCAL document is for.
+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](https://github.com/GSA/fedramp-automation/raw/master/dist/content/rev5/resources/xml/FedRAMP_extensions.xml)_ +- _[JSON Version](https://raw.githubusercontent.com/GSA/fedramp-automation/master/dist/content/rev5/resources/json/FedRAMP_extensions.json)_ +- _[HTML Version](https://github.com/GSA/fedramp-automation/raw/master/documents/rev5/FedRAMP_extensions.html)_ +{{
Brief assessment description.
Brief assessment description.
Brief assessment description.
+{{
Statement about satisfaction of this objective.
+Statement about satisfaction of this objective.
++{{
[EXAMPLE]The AC policy existed, and had all the required elements.
+If the policy is defined in the SSP as a component.
Reviewed Policy
If the policy is not an SSP component.
+{{
[EXAMPLE]The person interviewed knew about the policy and where to find it.
+describe the evidence.
+{{
+{{
Contents of the Observations and Evidence cell in the TCW.
++{{
Policy describes procedure, which could not be found.
[EXAMPLE]There is an issue with an SSP Statement.
+{{
This is a general description of the identified risk.
+This is a statement about the identified risk in the context of this system.
+cut.
+{{
This is a description of the identified risk.
+This is a statement about the identified risk.
+A description of the recommended remediation.
+TCW: Assessor's recommended remediation + (lifecycle='recommendation').
+Undocumented devices found on network.
+Raw scanner tool output - discovery scan.
+Undocumented hosts are entered into the SAR's local-definitions.
+The results of the discovery scan.
Undocumented devices found on network.
+Raw scanner tool output - discovery scan.
+Undocumented hosts are entered into the SAR's result/local-definitions section as inventory-items or components.
+Undocumented hosts are listed in the observations assembly as subjects.
+The origin must contain the UUID of the tool used to perform the scan.
+The results of the discovery scan.
This is a description of the identified risk.
+ +Scans: Vulnerability Description.
+ + +This is a statement about the identified risk.
+ +Scans: N/A.
+ + +A description of the recommended remediation.
+ +Scans: Tool's recommended remediation (type='recommendation')
+ + + +This is a description of the vulnerability provided by the tool.
+This is a statement about the identified risk as provided by the tool.
+Penetration Testing
A finding from penetration testing activities.
If a penetration test result is favorable, such as to say the SOC detected the activities appropriately, no risk is required.
+If a penetration test result identifies a vulnerability or deficiency, the risk assembly is required.
+This is a description of the issue found by the penetration testing team.
+Statement about the risk identified by penetration testing.
+A description of the recommended remediation as provided by the assessor.
+The assessor may add their recommendation.
+False positive justification.
A screen shot showing the setting is correct
Vendor detail describing why this happens.
+{{
Justification for the OR.
Screen shot showing impact when patched.
+Vendor detail describing why this happens.
++{{
Justify the risk.
+{{
cut
cut
A description of the recommended remediation as provided by the tool.
+A description of the recommended remediation as provided by the assessor.
+Describe what action(s) the CSP took to close the risk.
+Applied patch. Vulnerability no longer found in subsequent scan.
+[3PAO] attests to the accuracy of the information provided in this FedRAMP Security Assessment Report for the annual assessment + of [Information System Name]
+This [Information System Name] SAR provides a complete assessment of the applicable FedRAMP controls defined in the SAP. + Evidence to validate the successful implementation of the security controls has been collected and validated, and will be made + available upon request.
+Based on the remaining risk noted in the [Information System Abbreviation] Risk Exposure Table, and the continuous improvement + of security related processes and controls, [3PAO Name] [recommends |does not recommend | provisionally recommends] + continued authorization be granted for [Information System Name].
+This is a description of the vulnerability provided by the tool.
+This is a statement about the identified risk as provided by the tool.
+This "resolution resource" is used by FedRAMP as a local, authoritative indicator of what version SSP (rev 4 or rev 5) this OSCAL document is for.
++{{
Remarks are required if service model is "other". Optional otherwise.
++{{
Remarks are required if service model is "other". Optional otherwise.
+Remarks are required if deployment model is "hybrid". Optional otherwise.
++{{
+{{
+{{
Remarks are optional if status/state is "operational".
+Remarks are required otherwise.
++{{
Describe the purpose and functions of this system here.
+ + ++{{
+{{
+{{
+{{
+{{
Briefly describe leveraged system.
++{{
+{{
Briefly describe the interconnection details.
++{{
A holistic, top-level explanation of the FedRAMP authorization boundary.
+A diagram-specific explanation.
The primary authorization boundary diagram.
+{{
A holistic, top-level explanation of the system's network.
+A diagram-specific explanation.
The primary network architecture diagram.
+{{
A holistic, top-level explanation of the system's data flows.
+A diagram-specific explanation.
The primary data flow diagram.
+{{
Describe the service
+{{
FIPS 140-2 Validated Module
A product with a cryptographic module.
FIPS 140-3 Validated Module
A product with a cryptographic module.
For Acronyms, resource must include a prop with @ns="https://fedramp.gov/ns/oscal", @name="type", and @value="fedramp-acronyms". | +| **Appendix C: Security Policies and Procedures** | No | Attach using the back-matter, resource syntax.
For Policies, resource must include a prop with @name=”type”, @value=”policy”, and @class=”control-family”.
For Procedures, resource must include a prop with @name=”type”, @value=”procedure”, and @class=”control-family”. | +| **Appendix D: User Guide** | No | Attach using the back-matter, resource syntax.
For User Guides, resource must include a prop with @name=”type” and @value=”users-guide”. | +| **Appendix E: Digital Identity Worksheet** | Yes | Incorporated above. See the Digital Identity Determination Section. | +| **Appendix F: Rules of Behavior** | No | Attach using the back-matter, resource syntax.
For Rules of Behavior, resource must include a prop with @name=”type” and @value="rules-of-behavior". | +| **Appendix G: Information System Contingency Plan (ISCP)** | No | Attach using the back-matter, resource syntax.
For ISCP, resource must include a prop with @name=”type”, @value="plan", and @class="information-system-contingency-plan". | +| **Appendix H: Configuration Management Plan (CMP)** | No | Attach using the back-matter, resource syntax.
For CMP, resource must include a prop with @name=”type”, @value="plan", and @class="configuration-management-plan". | +| **Appendix I: Incident Response Plan (IRP)** | No | Attach using the back-matter, resource syntax.
For IRP, resource must include a prop with @name=”type”, @value="plan", and @class="incident-response-plan". | +| **Appendix J: CIS and CRM Workbook** | Yes | This can be generated from the content in the Security Controls section and does not need to be maintained separately or attached. | +| **Appendix K: FIPS 199 Worksheet** | Yes | Incorporated above. See the Security Objectives Categorization (FIPS-199) Section. | +| **Appendix L: CSO-Specific Required Laws and Regulations** | No | Attach using the back-matter, resource syntax.
For User Guides, resource must include a prop with @name=”type” and @value=”law”. | +| **Appendix M: Integrated Inventory Workbook** | Yes | See the System Inventory Section. | +| **Appendix N: Continuous Monitoring Plan** | No | Attach using the back-matter, resource syntax.
For ConMon, resource must include a prop with @name=”type”, @value="plan", and @class="incident-response-plan". | +| **Appendix O: POA&M** | Yes | This is maintained separately in an OSCAL POA&M but can be attached using the back-matter, resource syntax.
For POA&M, resource must include a prop with @name=”type”, @value="plan", and @class="poam". | +| **Appendix P: Supply Chain Risk Management Plan (SCRMP)** | No | Attach using the back-matter, resource syntax.
For SCRMP, resource must include a prop with @name=”type”, @value="plan", and @class="scrmp". | +| **Appendix Q: Cryptographic Module Table** | Yes | See the Cryptographic Modules Section dealing with components. | + +--- +## 5.1. Attachments +Classic FedRAMP attachments include a mix of items. Some lend well to +machine-readable format, while others do not. Machine-readable content +is typically addressed within the OSCAL-based FedRAMP SSP syntax, while +policies, procedures, plans, guidance, and the rules of behavior documents are all treated as classic attachments, as described in the *Citations, Attachments, and Embedded Content in OSCAL Files* Section. The following table describes how each attachment is handled: + +#### Attachment Representation +{{< highlight xml "linenos=table" >}} + +
Flat-File Example (No implemented-component).
If no, explain why. If yes, omit remarks field.
COMMENTS: Additional information about this item.
If no, explain why. If yes, omit remarks field.
Optional, longer, formatted description.
If needed, describe this instance.
COMMENTS: Additional information about this item.
This field required by OSCAL, but may be left blank.
+FedRAMP requires no specific content here.
+Description of the component.
+Description of the component.
+Describe how is the software component satisfying the control.
+Describe how is the process satisfies the control.
+Description of the component.
+Describe how individual components are working together.
+Describe how the system - as a whole - is satisfying this statement.
+This can include policy, procedures, hardware, software, etc.
+Describe how Part a is satisfied within the system.
+An example component representing a policy.
+Describe how this policy satisfies Part a.
+Describe how the system - as a whole - is satisfying this statement.
+Leveraging system's responsibilities in satisfaction of AC-2.
+Not linked to inheritance, so this is always required.
+Describe how the software is satisfying this statement.
+Customer appropriate description of what may be inherited.
+Customer responsibilities if inheriting this capability.
+Describe what is satisfied by this system.
Describe what is inherited from the leveraged system in satisfaction + of this control statement.
+Optional: Information provided by leveraged system.
+Description of how the responsibility was satisfied.
++ The entire system as depicted in the system authorization boundary. +
Describe the service
FIPS 140 Validated Module
Component representing the entire system.
+FedRAMP SSP Template Section 13
Describe how Part a is satisfied within the system.
+Describe how Part b 1 is satisfied within the system.
+Describe how Part b 2 is satisfied within the system.
+personnel screening criteria – as required by specific information
+personnel screening criteria - as required by specific information
Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually.
-Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually.
+CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized.
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
Second parameter not-applicable
-The service provider defines controlled areas within facilities where the information and information system reside.
-The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.
-Must comply with NIST SP 800-88
-Equipment and procedures may be tested or validated for effectiveness
-Must comply with NIST SP 800-88
+Second parameter not-applicable
The service provider measures temperature at server inlets and humidity levels by dew point.
+The service provider defines controlled areas within facilities where the information and information system reside.
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+The service provider defines security measures to protect digital and non-digital media in transport. The security measures are approved and accepted by the JAB/AO.
Select the appropriate FedRAMP Baseline
+Must comply with NIST SP 800-88
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+Equipment and procedures may be tested or validated for effectiveness
See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
-Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
-Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
+Must comply with NIST SP 800-88
The service provider measures temperature at server inlets and humidity levels by dew point.
+Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+Select the appropriate FedRAMP Baseline
+Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+This enhancement is required for all high (or critical) vulnerability scan findings.
+The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
+The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
+See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
+track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.
+The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.
+If Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))
+This enhancement is required for all high (or critical) vulnerability scan findings.
-The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
-The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
-See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
-track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel, to include FedRAMP.
-The service provider must document its methodology for reviewing newly developed code for the Service in its Continuous Monitoring Plan.
-If Static code analysis cannot be performed (for example, when the source code is not available), then dynamic code analysis must be performed (see SA-11 (8))
-For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
- +For clarity, this control applies to all data in transit. Examples include the following data flows:
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
FedRAMP-Defined Assignment / Selection Parameters
SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
@@ -3432,21 +11383,33 @@SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
- +Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
- -Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
- + +Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
- +CNSSI No.7003 can be accessed here:
https://www.dcsa.mil/Portals/91/documents/ctp/nao/CNSSI_7003_PDS_September_2015.pdf
- +DHS Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies can be accessed here:
https://us-cert.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_Defense_in_Depth_Strategies_S508C.pdf
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
The organization supports the capability to use cryptographic mechanisms to protect information at rest.
+When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
+Note that this enhancement requires the use of cryptography in accordance with SC-13.
+Organizations should select a mode of protection that is targeted towards the relevant threat scenarios.
+Examples:
+A. Organizations may apply full disk encryption (FDE) to a mobile device where the primary threat is loss of the device while storage is locked.
+B. For a database application housing data for a single customer, encryption at the file system level would often provide more protection than FDE against the more likely threat of an intruder on the operating system accessing the storage.
+C. For a database application housing data for multiple customers, encryption with unique keys for each customer at the database record level may be more appropriate.
+The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server.
+The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.
+Synchronization of system clocks improves the accuracy of log analysis.
+The organization supports the capability to use cryptographic mechanisms to protect information at rest.
-When leveraging encryption from underlying IaaS/PaaS: While some IaaS/PaaS services provide encryption by default, many require encryption to be configured, and enabled by the customer. The CSP has the responsibility to verify encryption is properly configured.
-Note that this enhancement requires the use of cryptography in accordance with SC-13.
-Organizations should select a mode of protection that is targeted towards the relevant threat scenarios.
-Examples:
-A. Organizations may apply full disk encryption (FDE) to a mobile device where the primary threat is loss of the device while storage is locked.
-B. For a database application housing data for a single customer, encryption at the file system level would often provide more protection than FDE against the more likely threat of an intruder on the operating system accessing the storage.
-C. For a database application housing data for multiple customers, encryption with unique keys for each customer at the database record level may be more appropriate.
-The service provider selects primary and secondary time servers used by the NIST Internet time service. The secondary server is selected from a different geographic region than the primary server.
-The service provider synchronizes the system clocks of network computers that run operating systems other than Windows to the Windows Server Domain Controller emulator or to the same time source for that server.
-Synchronization of system clocks improves the accuracy of log analysis.
-Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.
Determine if the organization defines information system account types to be identified and selected to support organizational missions/business functions.
Access control policy; procedures addressing account management; security plan; information system design documentation; information system configuration settings and associated documentation; list of active system accounts along with the name of the individual associated with each account; list of conditions for group and role membership; notifications or records of recently transferred, separated, or terminated employees; list of recently disabled information system accounts along with the name of the individual associated with each account; access authorization records; account management compliance reviews; information system monitoring records; information system audit records; other relevant documents or records.
Organizational personnel with account management responsibilities; system/network administrators; organizational personnel with information security responsibilities.
Organizational processes for account management on the information system; automated mechanisms for implementing account management.
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication.
FED - This is related to agency data and agency policy solution.
FED - This is related to agency data and agency policy solution.
NSO - All access to Cloud SaaS are via web services and/or API. The device accessed from or whether via wired or wireless connection is out of scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2[1]).
NSO - All access to Cloud SaaS are via web service and/or API. The device accessed from is out of the scope. Regardless of device accessed from, must utilize approved remote access methods (AC-17), secure communication with strong encryption (SC-13), key management (SC-12), and multi-factor authentication for privileged access (IA-2 [1]).
NSO - Loss of availability of the audit data has been determined to have little or no impact to government business/mission needs.
NSO - Loss of availability of the audit data has been determined as little or no impact to government business/mission needs.
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
Attestation - for compliance with FedRAMP Tailored LI-SaaS Continuous Monitoring Requirements.
Condition: There are connection(s) to external systems. Connections (if any) shall be authorized and must: 1) Identify the interface/connection. 2) Detail what data is involved and its sensitivity. 3) Determine whether the connection is one-way or bi-directional. 4) Identify how the connection is secured.
Required - Specifically include details of least functionality.
NSO- Not directly related to protection of the data.
NSO - Boundary is specific to SaaS environment; all access is via web services; users' machine or internal network are not contemplated. External services (SA-9), internal connection (CA-9), remote access (AC-17), and secure access (SC-12 and SC-13), and privileged authentication (IA-2[1]) are considerations.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO - Loss of availability of the SaaS has been determined as little or no impact to government business/mission needs.
NSO for non-privileged users. Attestation for privileged users related to multi-factor identification and authentication - specifically include description of management of service accounts.
Determine if the information system:
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
Condition: Must document and assess for privileged users. May attest to this control for non-privileged users. FedRAMP requires a minimum of multi-factor authentication for all Federal privileged users, if acceptance of PIV credentials is not supported. The implementation status and details of how this control is implemented must be clearly defined by the CSP.
Attestation - Specifically attest to US-CERT compliance.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Condition: Control is not inherited from a FedRAMP-authorized PaaS or IaaS.
Attestation - Specifically stating that any third-party security personnel are treated as CSP employees.
Condition: If availability is a requirement, define protections in place as per control requirement.
Condition: If implementing need to detail how they meet it or don't meet it.
NSO - Not directly related to the security of the SaaS.
Attestation - Specifically related to US-CERT and FedRAMP communications procedures.
Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
-For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
-For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
-Password policies must be compliant with NIST SP 800-63B for all memorized, lookup, out-of-band, or One-Time-Passwords (OTP). Password policies shall not enforce special character or minimum password rotation requirements for memorized secrets of users.
+For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
+Note that (c) and (d) require the use of cryptography which must be compliant with Federal requirements and utilize FIPS validated or NSA approved cryptography (see SC-13).
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
+See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
+The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
+See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
+Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-Include all Authorizing Officials; for JAB authorizations to include FedRAMP.
-See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
-Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
-Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
-The service provider must comply with Federal Acquisition Regulation (FAR) Subpart 7.103, and Section 889 of the John S. McCain National Defense Authorization Act (NDAA) for Fiscal Year 2019 (Pub. L. 115-232), and FAR Subpart 4.21, which implements Section 889 (as well as any added updates related to FISMA to address security concerns in the system acquisitions process).
-The use of Common Criteria (ISO/IEC 15408) evaluated products is strongly preferred.
-See https://www.niap-ccevs.org/Product/index.cfm or https://www.commoncriteriaportal.org/products/.
-
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
@@ -1958,7 +6472,7 @@
Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
-
Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
@@ -1970,6 +6484,18 @@
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.
personnel screening criteria – as required by specific information
+personnel screening criteria - as required by specific information
Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
-Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
-For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
-Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.
+Annually or whenever changes in the threat environment are communicated to the service provider by the JAB/AO.
+For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.
+Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
+Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. CSPs and 3PAOs typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding SAR Risk Exposure Table (RET), which are then documented in the CSP's Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.
During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.
FedRAMP does not provide a template for the Configuration Management Plan. However, NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems, provides guidelines for the implementation of CM controls as well as a sample CMP outline in Appendix D of the Guide
The service provider defines a time period consistent with the recovery time objectives and business impact analysis.
-The service provider defines a time period consistent with the recovery time objectives and business impact analysis.
+"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
+"Phishing-resistant" authentication refers to authentication processes designed to detect and prevent disclosure of authentication secrets and outputs to a website or application masquerading as a legitimate system.
For cases where technology doesn’t allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
+For cases where technology doesn't allow multi-factor authentication, these rules should be enforced: must have a minimum length of 14 characters and must support all printable ASCII characters.
For emergency use accounts, these rules should be enforced: must have a minimum length of 14 characters, must support all printable ASCII characters, and passwords must be changed if used.
The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
+The FISMA definition of "incident" shall be used: "An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."
The service provider measures temperature at server inlets and humidity levels by dew point.
-Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
-Select the appropriate FedRAMP Baseline
-The service provider measures temperature at server inlets and humidity levels by dew point.
+Significant change is defined in NIST Special Publication 800-37 Revision 2, Appendix F.
+Select the appropriate FedRAMP Baseline
+See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
+an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
+If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
+to include all Authorizing Officials; for JAB authorizations to include FedRAMP
+Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
+Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
+Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a "warning" as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on "Tracking of Compliance Scans" in FAQs.
+See the FedRAMP Documents page> Vulnerability Scanning Requirements https://www.FedRAMP.gov/documents/
-an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
-If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
-to include all Authorizing Officials; for JAB authorizations to include FedRAMP
-Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
-Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, a deviation request will need to be submitted per the FedRAMP Vulnerability Deviation Request Form.
-Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
-For each instance of data in transit, confidentiality AND integrity should be through cryptography as specified in SC-8 (1), physical means as specified in SC-8 (5), or in combination.
- +For clarity, this control applies to all data in transit. Examples include the following data flows:
The following applies only when choosing SC-8 (5) in lieu of SC-8 (1).
FedRAMP-Defined Assignment / Selection Parameters
SC-8 (5)-1 [a hardened or alarmed carrier Protective Distribution System (PDS) when outside of Controlled Access Area (CAA)]
@@ -3104,21 +10049,33 @@SC-8 (5) applies when physical protection has been selected as the method to protect confidentiality and integrity. For physical protection, data in transit must be in either a Controlled Access Area (CAA), or a Hardened or alarmed PDS.
- +Hardened or alarmed PDS: Shall be as defined in SECTION X - CATEGORY 2 PDS INSTALLATION GUIDANCE of CNSSI No.7003, titled PROTECTED DISTRIBUTION SYSTEMS (PDS). Per the CNSSI No. 7003 Section VIII, PDS must originate and terminate in a Controlled Access Area (CAA).
- -Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS’s Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS’ recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
- + +Controlled Access Area (CAA): Data will be considered physically protected, and in a CAA if it meets Section 2.3 of the DHS's Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. CSPs can meet Section 2.3 of the DHS' recommended practice by satisfactory implementation of the following controls PE-2 (1), PE-2 (2), PE-2 (3), PE-3 (2), PE-3 (3), PE-6 (2), and PE-6 (3).
+Note: When selecting SC-8 (5), the above SC-8(5), and the above referenced PE controls must be added to the SSP.
- +CNSSI No.7003 can be accessed here:
https://www.dcsa.mil/Portals/91/documents/ctp/nao/CNSSI_7003_PDS_September_2015.pdf
- +DHS Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies can be accessed here:
https://us-cert.cisa.gov/sites/default/files/FactSheets/NCCIC%20ICS_FactSheet_Defense_in_Depth_Strategies_S508C.pdf
See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
+See M-22-09, including "Agencies encrypt all DNS requests and HTTP traffic within their environment"
SC-8 (1) applies when encryption has been selected as the method to protect confidentiality and integrity. Otherwise refer to SC-8 (5). SC-8 (1) is strongly encouraged.
The requirement for FIPS 140 validation, as well as timelines for acceptance of FIPS 140-2, and 140-3 can be found at the NIST Cryptographic Module Validation Program (CMVP).
https://csrc.nist.gov/projects/cryptographic-module-validation-program
@@ -3208,6 +10186,26 @@Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status.