FedRAMP System Security Plan (SSP)
Adopting OSCAL for SSP Representation
SSP Adoption Strategies
The best way to adopt OSCAL for your system depends on your circumstances. The OSCAL Foundation defines two adoption strategies:
Retrofit Adoption Path : Converting Legacy Documentation
Native Adoption Path : Creating New Documentation
Retrofit Adoption Path
If you need to convert legacy documentation to OSCAL, follow the Retrofit Adoption Path .
Migrate existing content to OSCAL with the minimum necessary refactoring, and normalize content over time.
Native Adoption Path
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentaiton to convert, follow the Native Adoption Path .
The FedRAMP PMO prefers new systems follow the FedRAMP 20x Authorization Path. We will prioritize 20x representation in OSCAL based on demand from CSPs and Agency Authorizing Officials (AO).
Retrofit Adoption Path
If you need to convert legacy documentation to OSCAL, follow this path.
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentation to convert, follow the Native Adoption Path .
Organizations with existing Word and Excel based authorization packages must first migrate their content to OSCAL with only the minimum necessary refactoring. The Retrofit Adoption Path starts with a minimum viable product (MVP) and evolves to more comprehensive use cases in phases.
This approach initially sacrifices data normalization in favor of a more rapid transition to OSCAL. It allows conversion of content as-is, then gradually eliminates redundancy and normalizes data in subsequent phases. This is possible because OSCAL is designed to meet you where you are, and it allows gradual progress toward its more normalized ideal representation.
SSP Retrofit Adoption Overview
The OSCAL Foundation recommends the following addoption path for migrating legacy FedRAMP SSP content to OSCAL.
To facilitate conversion of legacy Word content, OSCAL allows legacy control responses to be associated with the "this-system" component. CSPs can migrate slowly over time to the OSCAL's preferred per-component responses.
SSP Adoption Path
MINIMUM VIABLE PRODUCT (MVP)
Import Baselines as Resolved Profile Catalogs
Get started with Use pre-processed control baselines.
See Baselines for more information.
Minimum Required Fieldss and Basic CSP and System Details.
metadata includes:
title , published , last-modified , version , oscal-version
roles : cloud-service-provider , information-system-security-officer , others as cited in controls.
See Roles for more information on roles.
parties : the CSP, the ISSO.
See Parties and Locations for more information on defining parties.
responsible-parties : exactly one, linking the CSP party to the CSP role
See Roles for more information on associating parties with roles.
system-characteristics includes:
system-id , system-name , system-name-short , description , cloud-service-model prop and cloud-deployment-model prop
See 3. System Information for more information
security-sensitivity-level ( fips-199-high , fips-199-moderate , fips-199-low )
system-information : exactly one entry with Appendix K pasted into the description
status set to operational (required OSCAL fields)
See System Status for more information.
authorization-boundary , network-architecture and data-flow : description and links entry identifying the external attachment.
See 8. Illustratred Architecture and Narratives for more information.
system-implementation includes:
`components:
Exactly one, with type = this-system (Known as the "this-system" component, which represents the system as a whole.)
See Components for more information.
Flat Inventory Migration
Convert directly from spreadsheet.
Non-normalized. No corrisponding components.
system-implementation :
inventory-items : All inventory converted from Excel spreadsheet
Migrate Control Response
Minimum-necessary adjustments for OSCAL.
All response statements in the "this-system" component.
control-implementation
implemented-requirement (AC-1, AC-2, etc.)
set-parameters : set parameters as needed
statement (part a, part b, etc.
by-component ("this system")
description : Content directly from legacy Word SSP (part a, part b, etc.)
implementation-status
responsible-roles : One entry per role. Use role-id . Must match metadata/roles/id .
During transition, any portion of the Word SSP not yet converted to OSCAL should be attached to the OSCAL SSP content.
INTERMEDIATE
Required Attachments
Add direct links from the appropriate controls to identify relevant attachments
Required SSP Roles
metadata/roles The roles required by SSP (System owner, ISSO, AO, etc.)
metada/parties : the people, teams and organizations responsible for the above roles
metadata/responsible-parties : links the above roles and parties
Information Types
system-characteristics/system-information/information-types
a single entry for each row in appendix K.
Leveraged Authorizations
system-implementation/leveraged-authorizations :
one entry for leveraged authorization
corrisponding metadata/parties entry for each
corrisponding system-implementation/components for each.
Separation of Duties Matrix
system-implementation/users
one entry per row in Table 11.1
./authorized-privilege/functions-performed : SSP Table 11.1 Duty Description (just one entry in the array)
./authorized-privilege/title : Required by OSCAL, not by FedRAMP. Recommend duplicating the functions-performed content.
role-ids : links metadata/roles to functions-performed
Customer Responsibility and Inheritance :
Move customer responsibility statements to //by-components/export/responsibilities
ADAVANCED
Normalize Inventory : Transition flat inventory to component-based inventory.
Use components to the greatest degree practical
inventory-items become implemented instances of components
External Systems and Services
system-implementation/components entries for each
Transition to resources
Where practical, use URI fragments in links to reference resources instead of direct links. See [section citation and link] for more information.
Components for Required Documents
One for each required document (policies, procedures, plans, user guides, Rules of Behavior)
See [Section citation and link] for more information.
NORMALIZED
Import Baselines as Profiles
Eliminate reliance on resolved profile catalogs
Ensure your tools have the ability to process profiles by this phase.
Ensure consumers of your SSP are able to process profiles.
Services, Ports and Protocols
Migrate to component-based control responses
Add components entries as needed to support normalized inventory
Add by-components entries to implemented-requirements for each relevant component
Add/move component-specific control responses to their associated by-components response.
Migrate slowly over time.
Cryptographic Modules (App Q table)
Profile Imports
The decision to import a profile or resolved profile catalog is dependent on the profile processing capability of your tools and the tools of any receiving party.
Pre-processed resolved profile catalogs are a simplified way to get started; however, OSCAL tools must ultimately process profiles. Processing OSCAL profiles is the only way tools can handle control overlays and multiple frameworks.
If you elect to start with resolved profile catalogs , migrate to profiles as soon as yoru tools and your recipients tools can perform this processing.
Easy Migration
Within an OSCAL SSP, migration is performed simply by changing the import-profile statement to reference the appropriate profile instead of a resolved profile catalog .
---
Native Adoption Path
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentation to convert, follow this path.
If you need to convert legacy documentation to OSCAL, follow the Retrofit Adoption Path .
The FedRAMP PMO prefers new systems follow the FedRAMP 20x Authorization Path. We will prioritize 20x representation in OSCAL based on demand from CSPs and Agency Authorizing Officials (AO).
Organizations adopting OSCAL for initial SSP creation must be mindful of OSCAL's relational dependencies to ensure efficient content population. The Native Adoption Path starts with components and other core system details, then builds on those components in later phases to achieve highly normalized and complete SSP content.
This approach prioritzes data normalization from the start. It establishes foundational data elements on which later phases build. This ensures logical sequencing of activties and efficient progression of SSP detail.
SSP Native Adoption Overview
The OSCAL Foundation recommends the following addoption path when creating an OSCAL-based FedRAMP SSP from scratch.
CORE
Import Resolved Profile Catalogs
Get started with Use pre-processed control baselines.
See Baselines for more information.
Minimum Required Fields and Basic CSP and System Details
metadata includes:
title , last-modified , version , oscal-version (required OSCAL fields)
roles : cloud-service-provider
parties : the CSP
responsible-parties : exactly one, linking the CSP party to the CSP role.
system-characteristics includes:
system-id , system-name , system-name-short , description (required OSCAL fields)
cloud-service-model and cloud-deployment-model props
status set to operational (required OSCAL fields)
authorization-boundary/description : Only a brief description is required.
Information Types and System Categorization
system-characteristics includes:
system-information
security-sensitivity-level ( fips-199-high , fips-199-moderate , fips-199-low )
See Appendix K: FIPS-199 Worksheet for more information.
OSCAL Components for Required Documents and System Elements
system-implementation
components :
Exactly one "this system" component ( type = this-system ) (Represents the system as a whole.)
One for each technical element (hardware, software, virtual appliance, service) used in the system
One for each required document (policies, procedures, plans, user guides, Rules of Behavior)
See [Section citation and link] for more information.
DETAIL
SSP-Required Roles and Parties : See [Seciton citation and link]
Leveraged Authorizations : See [Seciton citation and link]
External Systems and Services : See [Seciton citation and link]
Ports and Protocols : See [Seciton citation and link]
Separation of Duties : See [Seciton citation and link]
Cryptographic Modules : See [Seciton citation and link]
Diagrams : See [Seciton citation and link] See [Seciton citation and link]
Boundary/Architecture Diagram and Narriative
Network Architecture Diagram and Narriative
Data Flow Diagram and Narriative
CONTROLS
Align Components to Controls : See [Seciton citation and link]
Respond to Controls per-Component : See [Seciton citation and link]
NORMALIZED
Import Baselines as Profiles
Eliminate reliance on resolved profile catalogs
Ensure your tools have the ability to process profiles by this phase.
Ensure consumers of your SSP are able to process profiles.
Component-Based Inventory Representation : See [Seciton citation and link]
Verify/Adjust Control Origin and Aggregated Status : See [Seciton citation and link]
Add Customer Responsibilities : See [Seciton citation and link]
OSCAL Requirements
All OSCAL Core Requirements must be met for all OSCAL artifacts.
This chapter contains information about OSCAL SSP requirements that are not explicit FedRAMP SSP requirements.
System Status
FedRAMP no longer includes System Status in the SSP template; however core OSCAL requires the system status to be identified.
The system statys is represented in system-characteristics .
A status entry that includes:
state field set to one of the allowed values.
A remarks field is optional if the state is operational . Otherwise, the remarks field must be present.
OSCAL Representation
system-security-plan:
system-characteristics:
status:
state: operational
remarks: 'Remarks are optional if status/state is "operational".
Remarks are required otherwise.'
OSCAL Allowed Values
Valid state values:
operational ( remarks optional)
under-major-modification ( remarks required)
other ( remarks required)
Although core OSCAL also allows under-development and disposition (retired), these values do not make sense in a FedRAMP authorization package.
Title Page, Prepared by/for, Approvers
Title Page
The SSP title page follows the Title Pages pattern.
Prepared By/For
Prepared By and Prepared For follow the Roles pattern, using the prepared-by and prepared-for roles.
For an SSP:
prepared-by may identify the cloud service provider or a thrid party advisory organization
prepared-for always identifes the cloud service provider
Defined Identifiers
Required Role IDs:
prepared-by
prepared-for
Prepared By - CSP or Self‑Prepared
When the SSP is preapred by the CSP the metadata must include:
a roles entry with an id of prepared-by
a parties entry that represents the CSP
a responsible-parties entry with:
a role-id of prepared-by
a parties-uuid array with one entry:
the uuid value of the CSP entry in the parties array above.
metadata:
roles:
- id: prepared-by
title: Prepared By
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: CSP Name
responsible-parties:
- role-id: prepared-by
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
Prepared By - Third Party
When the SSP is preapred by an advisory firm, the metadata must include:
a roles entry with an id of prepared-by
a parties entry that represents the third party firm
a responsible-parties entry with:
a role-id of prepared-by
a parties-uuid array with one entry:
the uuid value of the third party firm's entry in the parties array above.
metadata:
roles:
- id: prepared-by
title: Prepared By
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: Third Party Firm Name
responsible-parties:
- role-id: prepared-by
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
Prepared For
The SSP is always prepared for the CSP. The metadata must include:
a roles entry with an id of prepared-for
a parties entry that represents the CSP
a responsible-parties entry with:
a role-id of prepared-for
a parties-uuid array with one entry:
the uuid value of the CSP entry in the parties array above.
metadata:
roles:
- id: prepared-for
title: Prepared For
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: CSP Name
responsible-parties:
- role-id: prepared-for
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
To include location, log or other details for a Party, see Parties and Locations .
System Security Plan Approvals
SSP Approvals follow the Roles pattern, using the content-approver role.
Defined Identifiers
Required Role IDs:
content-approver
Sections 1 - 11
1. Introduction
This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.
2. Purpose
This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.
3. System Information
System Information
CSP Name
The cloud service provider (CSP) name and abbreviation are represented in the SSP metadata .
A roles extry must exist with id = cloud-service-provider
A parties entry must exist with the CSP's name and short-name .
A responsible-parties entry must exist to link the parties UUID value to the cloud-service-provider role.
OSCAL Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
metadata:
roles:
- id: cloud-service-provider
title: Cloud Service Provider
short-name: CSP
parties:
- uuid: 11111111-2222-4000-8000-004000000001
type: organization
name: Cloud Service Provider (CSP) Name
short-name: CSP Acronym/Short Name
responsible-parties:
- role-id: cloud-service-provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
CSO Name
The CSO name and abbreviation are represented in system-characteristics .
The system-name field contains the CSO Name
The system-name-short field contains the CSO abbreviation.
OSCAL Representation
system-security-plan:
system-characteristics:
system-name: System's Full Name
system-name-short: System's Short Name or Acronym
system-ids:
- identifier-type: http://fedramp.gov/ns/oscal
id: F00000000
FedRAMP Package ID
The FedRAMP Package ID is represented in system-characteristics .
A system-ids entry must exist that includes:
identifier-type set to http://fedramp.gov/ns/oscal
id set to the FedRAMP Package ID
OSCAL Representation
system-security-plan:
system-characteristics:
system-ids:
- identifier-type: http://fedramp.gov/ns/oscal
id: F00000000
FedRAMP Allowed Value
Required Identifier Type:
identifier-type="https://fedramp.gov"
Service Model
The Service Model is represented in system-characteristics .
A system-characteristics property ( prop ) entry must exist that includes:
A name set to cloud-service-model
A value set to one of the allowed service model values below.
If the value is set to other , remarks is used to explain.
If more than one service model type is applicable (IaaS and PaaS; IaaS and PaaS and SaaS; PaaS and SaaS), use one "cloud-service-model" prop for each applicable cloud service model.
OSCAL Representation
system-security-plan:
system-characteristics:
props:
- name: cloud-service-model
value: iaas
- name: cloud-service-model
value: paas
- name: cloud-service-model
value: other
remarks: Remarks are required if service model is "other". Optional otherwise.
OSCAL Allowed Values
Valid cloud-service-model property values:
saas
paas
iaas
other
Digital Identity Level (DIL) Determination
See Appendix E for appropriate OSCAL representation.
FIPS PUB 199 Level
See Appendix K for appropriate OSCAL representation.
Fully Operational as of
The fully operational date is represented in system-characteristics .
A system-characteristics property ( prop ) entry must exist that includes:
A name set to fully-operational-date
A ns set to http://fedramp.gov/ns/oscal
A value set to the operational date.
Although the value field is a string, the date should be treated as an OSCAL date-time-with-timezone data type.
OSCAL Representation
system-security-plan:
system-characteristics:
props:
- name: fully-operational-date
ns: http://fedramp.gov/ns/oscal
value: '2023-12-31T00:00:00Z'
Deployment Model
The Deployment Model is represented in system-characteristics .
A system-characteristics property ( prop ) entry must exist that includes:
A name set to deployment-model
A value set to one of the allowed deployment model values below.
If the value is set to other , remarks is used to explain.
Only one cloud-deployment-model property is permitted.
If the deployment model is hybrid or other , the remarks field is required. Otherwise, it is optional.
OSCAL Representation
system-security-plan:
system-characteristics:
props:
- name: cloud-deployment-model
value: hybrid-cloud
remarks: Remarks are required if deployment model is "hybrid-cloud" or "other". Optional otherwise.
FedRAMP Accepted Values
Valid cloud-deployment-model property values:
public-cloud
private-cloud
government-only-cloud
hybrid-cloud
other
Although core OSCAL also allows community-cloud , FedRAMP authorizations do not include community clouds.
Authorization Path
This is an obsolete concept and does not need to be represented in OSCAL.
General System Description
The General System Description is represented in system-characteristics .
The description field contains the general system description.
This is a markup-multiline field.
OSCAL Representation
system-security-plan:
system-characteristics:
description: '\[Insert CSO Name\] is delivered as \[a/an\] \[insert based on the Service Model above\] offering using a multi-tenant \[insert based on the Deployment Model above\] cloud computing environment. It is available to \[Insert scope of customers in accordance with instructions above (for example, the public, federal, state, local, and tribal governments, as well as research institutions, federal contractors, government contractors etc.)\].'
4. System Owner
System Owner follows the Roles pattern, using the system-owner role.
Defined Identifiers
Required Role ID:
system-owner
5. Assignment of Security Responsibility
Information System Security Officer (ISSO) follows the Roles pattern, using the information-system-security-officer role.
Defined Identifiers
Required Role ID:
information-system-security-officer
6. Leveraged FedRAMP-Authorized Services
The leveraged FedRAMP-Authorized services table is used to list both underlying leveraged authorizations, such as a SaaS running on an IaaS, and use of external cloud services with FedRAMP authorizations, such as a FedRAMP-authorized third party identity management service.
For each row in Table 6.1 there must be:
a parties entry
a leveraged-authorizations entry
a components entry
parties Entry
A parties entry to indicate the organizaiton that owns the leveraged system or external service
system-security-plan:
metadata:
parties:
- uuid: 22222222-2222-4000-8000-004000000001
type: organization
name: Leveraged System Provider's Name
short-name: LSPN
leveraged-authorizations Entry
The leveraged-authorizations entry must include:
a uuid
a title with the name of the system or service exactly as it appears in the FedRAMP Marketplace
a props entry with:
name set to package-id
ns set to http://fedramp.gov/ns/oscal
value set to the package ID exactly as it appears in the FedRAMP Marketplace
a props entry with:
name set to security-sensitivity-level
ns set to http://fedramp.gov/ns/oscal
value set to fips-199-low , fips-199-modarete or fips-199-high consistent with the FedRAMP Marketplace Information
a party-uuid with the UUID of the parties entry above
a date-authorized with the date listed in the FedRAMP Marketplace, expressed in OSCAL date format .
FedRAMP Extensions
FedRAMP Extensions are defined when there is no way to represent required information using core OSCAL. They are depicted as propterties ( props entries) with a namespace ( ns ) value set to http://fedramp.gov/ns/oscal . Without the namespace, these properties may be ignored or flagged as invalid.
system-security-plan:
system-implementation:
leveraged-authorization:
- uuid: 11111111-2222-4000-8000-019000000001
title: CSO Name
props:
- name: package-id
ns: http://fedramp.gov/ns/oscal
value: F9999999999
- name: security-sensitivity-level
ns: http://fedramp.gov/ns/oscal
value: fips-199-high
party-uuid: 22222222-2222-4000-8000-004000000001
date-authorized: '2015-01-01'
Allowed Values
The FedRAMP extension security-sensitivity-level :
fips-199-high
fips-199-moderate
fips-199-low
components Entry
The components entry must include:
a uuid
a type set to system
a title set to the name of the leveraged system
a description of the system. This is a core OSCAL requirement. FedRAMP has no specific requirement for the content of this field.
a props entry with:
name set to leveraged-authorization-uuid
value set to the UUID of the leveraged-authorization entry above
a props entry with:
name set to nature-of-agreement
ns set to http://fedramp.gov/ns/oscal
value set to sla , contract [needs more definition]
a props entry with:
name set to authentication-method
ns set to http://fedramp.gov/ns/oscal
value set to the package ID exactly as it appears in the FedRAMP Marketplace
One props entry for each "Data Type":
name set to information-type
ns set to http://fedramp.gov/ns/oscal
value set to the NIST SP 800-60 Volume 2 information ID
class set to incoming or outgoing
If the same information type is exchanged in both directions, there must be one props entry for incoming and a separate props entry for outgoing.
The status assembly with the state field set to operational
For FedRAMP the value must always be operational; however, this is a required OSCAL field and cannot be omitted.
One or more responsible-roles entries:
Identify the Provider (Required):
role-id set to provider (ensure metadata has a roles entry with id set to provider )
a party-uuids entry with the UUID of the parties entry defined above.
Authorized Users : One entry per authorized user type:
role-id
Use OSCAL-defined canonical values where appropriate.
If no canonoical value exists, create an appropriate value that conforms with the OSCAL token data type .
The value must also exist in the metadata / roles entries.
OSCAL Representation
system-security-plan:
system-implementation:
component:
- uuid: 11111111-2222-4000-8000-009000100001
type: system
title: Leveraged Authorized System
description: Briefly describe the leveraged system.
props:
- name: leveraged-authorization-uuid
value: 11111111-2222-4000-8000-019000000001
- name: nature-of-agreement
ns: http://fedramp.gov/ns/oscal
value: sla
- name: authentication-method
ns: http://fedramp.gov/ns/oscal
value: 'yes'
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.1
class: incoming
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.8
class: outgoing
status:
state: operational
responsible-roles:
- role-id: provider
party-uuids:
- 11111111-2222-4000-8000-c0040000000a
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-c0040000000a
FedRAMP Marketplace Information Matching
Information about Leveraged FedRAMP Authorized Services must match the content in the FedRAMP Marketplace. GSA updates a JSON file nightly that is used to render the FedRAMP Marketplace data.
OSCAL Field
GSA Field
CSP Name
/data/Providers/[#]/Cloud_Service_Provider_Name
CSO Name
/data/Providers/[#]/Cloud_Service_Provider_Package
Package ID
/data/Providers/[#]/Package_ID
Authorization Date
/data/Providers/[#]/Original_Authorization_Date
Impact Level
/data/Providers/[#]/Impact_Level
IMPORTANT FOR LEVERAGED SYSTEMS:
While a leveraged system has no need to represent content here, its SSP SHOULD include special inheritance and responsibility information in the individual controls. See the Response: Identifying Inheritable Controls and Customer Responsibilities section for more information.
7. External Systems and Services Not Having FedRAMP Authorization
FedRAMP authorized services should be used, whenever possible, since their risk is defined. However, there are instances where CSOs have external systems or services that are not FedRAMP authorized. In OSCAL, these external systems and services must be identified using component assemblies with additional FedRAMP namespace and class properties as shown in the OSCAL representation below.
OSCAL Representation
system-security-plan:
system-implementation:
component:
uuid: 11111111-2222-4000-8000-009000200001
type: interconnection
title: "[EXAMPLE]External System / Service Name"
description: "Briefly describe the interconnection details."
prop:
- ns: "https://fedramp.gov/ns/oscal"
name: service-processor
value: "[SAMPLE] Telco Name"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-type
value: "1"
- name: direction
value: incoming
- name: direction
value: outgoing
- ns: "https://fedramp.gov/ns/oscal"
name: nature-of-agreement
value: contract
- ns: "https://fedramp.gov/ns/oscal"
name: still-supported
value: yes
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-data-type
value: "C.3.5.1"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-data-type
value: "C.3.5.8"
- ns: "https://fedramp.gov/ns/oscal"
class: "C.3.5.1"
name: interconnection-data-categorization
value: low
- ns: "https://fedramp.gov/ns/oscal"
class: "C.3.5.8"
name: interconnection-data-categorization
value: moderate
- ns: "https://fedramp.gov/ns/oscal"
name: authorized-users
value: "SecOps engineers"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-compliance
value: "PCI SOC 2"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-compliance
value: "ISO/IEC 27001"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-hosting-environment
value: PaaS
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-risk
value: None
- name: isa-title
value: "system interconnection agreement"
- name: isa-date
value: "2023-01-01T00:00:00Z"
- name: ipv4-address
class: local
value: "10.1.1.1"
- name: ipv4-address
class: remote
value: "10.2.2.2"
- name: ipv6-address
value: "::ffff:10.2.2.2"
- ns: "https://fedramp.gov/ns/oscal"
name: information
value: "Describe the information being transmitted."
- ns: "https://fedramp.gov/ns/oscal"
name: port
class: remote
value: "80"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-security
value: ipsec
link:
- href: "#uuid-of-ICA-resource-in-back-matter"
rel: isa-agreement
back-matter:
resource:
uuid: "11111111-2222-4000-8000-001000000050"
title: "[SAMPLE]Interconnection Security Agreement Title"
props:
- name: published
value: '2023-01-01T00:00:00Z'
- name: version
value: Document Version
- name: type
value: agreement
class: interconnection-security-agreement
rlinks:
- href: ./attachments/ISAs/ISA-1.docx
External System and Services
To map the legacy FedRAMP SSP table for External Systems and Services into a machine-readable OSCAL format, the data is primarily stored within the system-implementation section, specifically under component definitions where the type is set to interconnection .
The following data points are captured using various OSCAL fields and FedRAMP-specific properties ( prop ):
Identity & Nature: The system, service, or API name is defined by the component title , while the specific interconnection-type (e.g., dedicated line, VPN) and the nature-of-agreement (e.g., MOU, ISA) are captured as properties.
Operational Details: Connection characteristics are recorded via properties for direction (inbound/outbound), whether the service is still-supported (Y/N), and a general description of the interface.
Data Characteristics: The data-type and its associated data-categorization (Security Impact Level) are explicitly defined to track what information is leaving or entering the boundary.
User Access: Information regarding authorized-users and their specific privilege-level is linked back to the user definitions within the system implementation.
Compliance & Risk: Any other-compliance-programs (like SOC2 or ISO), the specific hosting-environment , and a summary of the risk-impact-mitigation strategies are all stored as specific metadata properties attached to the interconnection component.
When documenting multiple external services, each service is treated as a separate instance of an interconnection component within the OSCAL file.
8. Illustratred Architecture and Narratives
The Architecture, Network and Data Flow Diagramss are each represented using the same OSCAL patterns, with only the top level assemby name changing.
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. The narrative describing the system architecture must be provided in the description field of the authorization-boundary assembly.
OSCAL Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
authorization-boundary:
description: A holistic, top-level explanation of the FedRAMP authorization boundary.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000001
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000054'
rel: diagram
caption: Authorization Boundary Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000054
title: Boundary Diagram
description: The primary authorization boundary diagram.
props:
- name: type
value: image
class: authorization-boundary
rlinks:
- href: ./attachments/diagrams/boundary.png
To represent the Authorization Boundary from the legacy SSP in an OSCAL-based System Security Plan, the data is centered within the system-characteristics section under the authorization-boundary element.
The following elements and structures are used to capture the boundary definition:
Boundary Narrative: An overall-description is used to provide a high-level technical and functional summary of the system's limits.
Visual Documentation: The model tracks the total number of boundary diagrams present to ensure compliance with the minimum requirement of at least one visual representation.
Diagram Linking: Each diagram is referenced via a link containing a unique identifier or path. This link either points to an external URI or a local reference within the OSCAL document.
Resource Storage: The actual image data or file location for a diagram is stored in the back-matter section. This is handled as a resource which can either contain the raw base64 encoded image data or a remote link ( rlink ) to the hosted file.
Contextual Details: Individual diagrams can also include their own specific description to clarify the components, data flows, or sub-networks depicted in that particular view.
When multiple diagrams are required to show different perspectives of the boundary, each is listed as a sequential entry within the authorization boundary array.
Network Architecture
The network architecture diagram follows the same patter as the Authorization Boundary diagram, except the content is placed under network-architecture instead of authorization-boundary .
OSCAL Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
network-architecture:
description: A holistic, top-level explanation of the network architecture.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000002
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000055'
rel: diagram
caption: Network Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000055
title: Network Diagram
description: The primary network diagram.
props:
- name: type
value: image
class: network-architecture
rlinks:
- href: ./attachments/diagrams/network.png
Data Flow
The data flow diagram follows the same pattern as the Authorization Boundary diagram, except the content is placed under data-flow instead of authorization-boundary .
OSCAL Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
data-flow:
description: A holistic, top-level explanation of the system's data flows.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000003
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000056'
rel: diagram
caption: Data Flow Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000056
title: Data Flow Diagram
description: The primary data flow diagram.
props:
- name: type
value: image
class: data-flow
rlinks:
- href: ./attachments/diagrams/dataflow.png
9. Services, Ports and Protocols
Entries in the services, ports, and protocols 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.
OSCAL Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000500004
type: service
title: API Service
description: 'A service offered by this system to external systems, such as
an API. As a result, communication crosses the boundary.
Describe the service and what it is used for.'
props:
- name: implementation-point
value: internal
- name: public
value: 'yes'
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.1
class: incoming
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.8
class: outgoing
- name: connection-security
ns: http://fedramp.gov/ns/oscal
value: tls-1.3
- name: authentication-method
ns: http://fedramp.gov/ns/oscal
value: 'yes'
- name: nature-of-agreement
ns: http://fedramp.gov/ns/oscal
value: other
- name: allows-authenticated-scan
value: 'no'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
links:
- href: '#11111111-2222-4000-8000-009000100003'
rel: used-by
- href: '#11111111-2222-4000-8000-009000100004'
rel: used-by
- href: '#11111111-2222-4000-8000-001000000048'
rel: poam-item
resource-fragment: 11111111-3333-4000-8000-000000000004
- href: https://api.example.com/v1
rel: api
status:
state: operational
responsible-roles:
- role-id: administrator
props:
- name: privilege-uuid
ns: http://fedramp.gov/ns/oscal
value: 11111111-2222-4000-8000-008000000004
party-uuids:
- 11111111-2222-4000-8000-004000000010
- 11111111-2222-4000-8000-004000000011
- 11111111-2222-4000-8000-004000000012
- role-id: provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
protocols:
- uuid: 11111111-2222-4000-8000-010000000002
name: tls
title: API Service
port-ranges:
- start: '443'
end: '443'
transport: TCP
To represent Network Services and Ports within an OSCAL System Security Plan, the data is organized under the system-implementation section, specifically categorized by components where the type is defined as service , hardware or software .
The mapping for each service entry includes the following technical details:
Service Identity: Each entry starts with a title that identifies the specific service or application name (e.g., "HTTPS" or "SSH").
Protocol Configuration: The specific network protocol name (such as TCP or UDP) is identified to define how the service communicates.
Port Management: Detailed port information is captured within a port-range , specifying the exact start and end values. This also includes the transport layer designation to ensure the specific communication path is fully defined.
Functional Justification: A dedicated purpose field provides the business or technical rationale for why the service is required within the system boundary.
Component Relationships: The model tracks which internal system elements are utilizing the service by linking to the title of other defined components via their unique identifiers (UUIDs).
For systems with multiple services, each is documented as an individual service component, with the ability to define multiple protocols and port ranges within each entry to maintain a complete and granular inventory.
10. Cryptographic Modules Implemented for DAR and DIT
This is address in Appendix Q: Cryptographic Modules .
11. Seperation of Duties Matrix
The metadata / roles array must have one entry for each column
an id with a token (use pre-defined ID values whenever possible)
a title with a human-readable role name
The system-implementation / users array must have one entry for each row:
a uuid (required)
a props array with the following entry:
a name with separation-of-duties-matrix
a ns with http://fedramp.gov/ns/oscal
a value with yes
a role-ids array with each entry:
the role ID token defined in metadata / roles
Only for roles where an "X" would appear in the table
an authorized-privileges array with one or more entries:
a title with the text from the "Duty Description" column
a functions-performed array with at least one string entry describing the function. (This is an OSCAL required field that is not required by FedRAMP.)
system-security-plan:
metadata:
roles:
- id: asset-administrator
title: Asset Administrator
- id: admin-client
title: Customer-Designated Administrator
- id: admin-unix
title: Unix Administrator
system-implementation:
users:
- uuid: 11111111-2222-4000-8000-008000000002
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
authorized-privileges:
- title: Add/Remove Admins
functions-performed:
- This can add and remove admins.
- uuid: 11111111-2222-4000-8000-008000000003
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
- admin-client
authorized-privileges:
- title: Add/Remove Users
functions-performed:
- add/remove non-privliged users
- uuid: 11111111-2222-4000-8000-008000000004
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
authorized-privileges:
- title: Cloud-Native Service Deployment
functions-performed:
- Manage services and components within the virtual cloud environment.
- uuid: 11111111-2222-4000-8000-008000000005
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- admin-client
authorized-privileges:
- title: Application User Admin
functions-performed:
- Add and remove users from the virtual cloud environment.
The props entry is required in each users entry. It identifies which users array entries are intended to represent the Separation of Duties Matrix. Tools processing OSCAL SSPs only for FedRAMP should ignore any users entry that does not include this props entry.
Appendices A - Q
Appendicies Overview
Most attachments required by FedRAMP are called out in the NIST SP 800-53 controls appearning in FedRAMP baselines.
Where a legacy FedRAMP attachment is handled as machine-readable content, you have the option of attaching the legacy attachment or representing the content as machine-readable content.
See the Document Attachments section for general attachment patterns as OSCAL resources .
The following table describes how each attachment is handled:
Appendix Name
Machine Readable
How to Handle in OSCAL
Appendix A: FedRAMP Security Controls
Yes
See the FedRAMP Security Controls section.
Appendix B: Related Acronyms
No
Attach using the back-matter , resource syntax. For Acronyms, resource must include a prop with @ns="http://fedramp.gov/ns/oscal" , @name="type" , and @value="fedramp-acronyms" .
Appendix C: Security Policies and Procedures
No
From each -1 control (i.e. AC-1, IA-1) use links to identify the related policy and procedure attachments.
Appendix D: User Guide
No
From SA-5 ( id = sa-5 ) use links to identify this attachment.
Appendix E: Digital Identity Worksheet
Yes
See the Digital Identity Determination section.
Appendix F: Rules of Behavior
No
From PL-4 ( id = pl-4 ) use links to identify this attachment.
Appendix G: Information System Contingency Plan (ISCP)
No
From CP-2 ( id = cp-2 ) use links to identify this attachment.
Appendix H: Configuration Management Plan (CMP)
No
From CM-9 ( id = cm-9 ) use links to identify this attachment.
Appendix I: Incident Response Plan (IRP)
No
From IR-8 ( id = ir-8 ) use links to identify this attachment.
Appendix J: CIS and CRM Workbook
Yes
This is generated from the content in the Security Controls section and does not need to be maintained separately nor attached.
Appendix K: FIPS 199 Worksheet
Yes
See the Appendix K: FIPS-199 Worksheet section.
Appendix L: CSO-Specific Required Laws and Regulations
No
Attach using the back-matter , resource syntax. For CSO-Specific Required Laws and Regulations, resource must include a prop with @name=”type” and @value=”law” .
Appendix M: Integrated Inventory Workbook
Yes
See the Inventory Approaches section.
Appendix N: Continuous Monitoring Plan
No
From CA-7 ( id = ca-7 ) use links to identify this attachment.
Appendix O: POA&M
Yes
From CA-5 ( id = ca-5 ) use links to identify this attachment.
Appendix P: Supply Chain Risk Management Plan (SCRMP)
No
From SR-2 ( id = sr-2 ) use links to identify this attachment.
Appendix Q: Cryptographic Module Table
Yes
See the Appendix Q: Cryptographic Modules section.
Appendix A: FedRAMP Security Controls
See the FedRAMP Security Controls chapter.
Appendix B: Related Acronyms
There is no OSCAL construct for representing an acronyms list.
Attach a document (e.g., Word, Excel, PDF) with acronyms using a back-matter , resources entry.
See Attachments for details.
Appendix C: Security Policies and Procedures
See Control Response: Policies and Procedures .
Appendix D: User Guide
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The SA-5 ( id = sa-5 control should have links entries to the user guide
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the user guide as a back-matter/ resources entry
create a component for the user guide
From the componet, add a links entry that references the resource (#uuid-value)
The SA-5 control has by-components entrys that cite the user guide component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix E: Digital Identity Level (DIL) Determination
The Digital Identity Level (DIL) is represented on the page below.
Within system-characteristics there must be three entries to the props array as follows:
name set to identity-assurance-level and a value set to 1 , 2 or 3 .
name set to authenticator-assurance-level and a value set to 1 , 2 or 3 .
name set to federation-assurance-level and a value set to 1 , 2 or 3 .
The value of all three should match each other and align with the FIPS-199 impact level of the system.
OSCAL Representation
system-security-plan:
system-characteristics:
props:
- name: identity-assurance-level
value: '2'
- name: authenticator-assurance-level
value: '2'
- name: federation-assurance-level
value: '2'
OSCAL Allowed Values
Valid IAL, AAL, and FAL values (as defined by NIST SP 800-63):
1
2
3
Appendix F: Rules of Behavior (RoB)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The PL-4 ( id = pl-4 control should have links entries to the RoB
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the RoB as a back-matter/ resources entry
create a component for the RoB
From the componet, add a links entry that references the resource (#uuid-value)
The PL-4 control has by-components entrys that cite the RoB component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix G: Information System Contingency Plan (ISCP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The CP-2 ( id = cp-2 control should have links entries to the RoB
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the ISCP as a back-matter/ resources entry
create a component for the ISCP
From the componet, add a links entry that references the resource (#uuid-value)
The CP-2 control has by-components entrys that cite the ISCP component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix H: Configuration Management Plan (CMP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The CM-9 ( id = cm-9 control should have links entries to the RoB
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the CMP as a back-matter/ resources entry
create a component for the CMP
From the componet, add a links entry that references the resource (#uuid-value)
The CM-9 control has by-components entrys that cite the CMP component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix I: Incident Response Plan (IRP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The IR-8 ( id = ir-8 control should have links entries to the RoB
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the IRP as a back-matter/ resources entry
create a component for the IRP
From the componet, add a links entry that references the resource (#uuid-value)
The IR-8 control has by-components entrys that cite the IRP component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix J: CIS and CRM Workbook
The FedRAMP Control Information Summary (CIS) and Customer Responsibility Matrix (CRM) are derived directly from the OSCAL control responses.
There is no need to maintain a separate CIS/CRM artifact; however, this information must be properly represented in the control responses. Tools can then summarize control information into the CIS and produce a list of customer responsibilities consistent with the CRM.
Needs Work
It needs an App J page image
It needs to reference and link to the customer respopnsibility topic in controls
Appendix K: FIPS-199 Worksheet
The system's overall FIPS-199 impact level is determined primarily by the sensitivity of the information it processes.
The overall FIPS-199 impact level is represented under system-characteristics :
security-sensitivity-level
The value must be one of fips-199-low , fips-199-moderate or fips-199-high
The FIPS-199 Categorization worksheet is an inventory of information types in the system, based on NIST SP 800-60 Volume 2 .
Create one entry under information-types for each information type.
For each information type:
Assign a uuid
Assign the NIST SP 800-63 information type name to the title
description is a required OSCAL field that is not acknowledged by FedRAMP. Consider offering context or citing 800-60.
The categorizations array should have one entry that includes:
system set to "http://doi.org/10.6028/NIST.SP.800-60v2r1"
the information-type-ids arraqy should have one entry
Use the NIST SP 800-60 invormation type ID
Exactly match the case as it appears in 800-60. (e.g., C.2.3.1 or D.15.5 )
The confidentiality-impact must have:
a base field with the value defined in 800-60.
a selected field with the value selected by the CSP.
If the value in selected does not match the value in base , use adjustment-justification to capture the "Statement for Impact Adjustment Justification"
base and selected values must be one of fips-199-low , fips-199-moderate or fips-199-high
integrity-impact and availability-impact are treated the same as confidentiality-impact` above.
Other information types or categorizations may be present if the SSP also represents compliance with other frameworks; however, the US Government must operate under NIST RMF and will only recognize the NIST SP 800-60 types.
OSCAL Representation
system-security-plan:
system-characteristics:
security-sensitivity-level: fips-199-high
system-information:
information-types:
- uuid: 11111111-2222-4000-8000-006000000001
title: Information Type Name
description: A description of the information.
categorizations:
- system: http://doi.org/10.6028/NIST.SP.800-60v2r1
information-type-ids:
- C.2.4.1
confidentiality-impact:
base: fips-199-moderate
selected: fips-199-moderate
adjustment-justification: Required if the base and selected values do not
match.
integrity-impact:
base: fips-199-moderate
selected: fips-199-low
adjustment-justification: Required if the base and selected values do not
match.
availability-impact:
base: fips-199-moderate
selected: fips-199-moderate
adjustment-justification: Required if the base and selected values do not
match.
OSCAL Allowed Values
Reqired value for system :
http://doi.org/10.6028/NIST.SP.800-60v2r1
Valid values for security-sensitivity-level , base and selected fields:
fips-199-low
fips-199-moderate
fips-199-high
Appendix L: CSO-Specific Required Laws and Regulations
Needs Work
Content cleanup
YAML Example
For MVP:
attach a Word or PDF document enumerating the applicable laws and regulations.
For Normalized:
Provide one back-matter/ resources entry per applicable law or regulation that includes:
a title with the title of the law or regulation
a props entry with:
name = type
value = law
rlinks entry that links to the law or regulation
Appendix M: Integrated Inventory Workbook
See Inventory Approaches for guidance.
Appendix N: Continuous Monitoring Plan
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The CA-7 ( id = ca-7 control should have links entries to the RoB
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the Continuous Monitoring Plan as a back-matter/ resources entry
create a component for the Continuous Monitoring Plan
From the componet, add a links entry that references the resource (#uuid-value)
The CA-7 control has by-components entrys that cite the Continuous Monitoring Plan component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix O: POA&M
See the FedRAMP POA&M book.
Appendix P: Supply Chain Risk Management Plan (SCRMP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
MVP Key Points Include:
The SR-2 ( id = sr-2 control should have links entries to the user guide
This is not normalized and is only for legacy conversion MVP
Normalized Key points include:
attach the SCRMP as a back-matter/ resources entry
create a component for the SCRMP
From the componet, add a links entry that references the resource (#uuid-value)
The SR-2 control has by-components entrys that cite the SCRMP component
Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.
Appendix Q: Cryptographic Modules
Cryptographic Modules Implemented for Data-in-Transit (DIT)
OSCAL'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 that provides details about the validation.
The Product Definition : A component that describes the hardware or software product.
The validation definition is a component 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 .
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: Data-In-Transit Example Product with FIPS 140-2 Validation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300003
type: software
title: OpenSSL
description: 'Provide a description and any pertinent note regarding the use
of this CM.'
props:
- name: asset-type
value: cryptographic-module
- name: version
value: 3.0.8
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: OpenSSL FIPS Provider
- name: function
ns: http://fedramp.gov/ns/oscal
value: data-in-transit
remarks: Usage statement
links:
- href: '#11111111-2222-4000-8000-009001200002'
rel: validation
text: A link to the 3rd party validation information related to this cryptographic
module.
status:
state: operational
- uuid: 11111111-2222-4000-8000-009001200002
type: validation
title: OpenSSL FIPS 140-2 Validation
description: Describe any relevant information regarding this validation of
the CM.
props:
- name: asset-type
value: cryptographic-module
- name: validation-type
value: fips-140-2
- name: validation-reference
value: '4811'
status:
state: operational
Understanding the Data-in-Transit (DIT) Mapping
When documenting cryptographic protections for data-in-transit, the OSCAL model focuses on the relationship between the specific software provider and its validated state.
Software Component & Function: The first block defines the actual implementation (e.g., OpenSSL ). The property name: function with the value data-in-transit explicitly categorizes the module’s role. This allows auditors and automated tools to identify which software is responsible for protecting communication channels, such as TLS or SSH connections, across the system boundary.
Decoupled Validation Metadata: Rather than burying version-specific details in a text field, OSCAL uses a link to connect the software component to a separate validation component. This second component (highlighted by the validation-reference value 4811 ) points directly to the NIST CMVP certificate.
Operational Status: The state: operational field confirms that the module is currently in use within the environment. If a module were undergoing an update or was in a "historical" state, this status could be updated to reflect the current risk posture without needing to rewrite the entire narrative.
By structuring the SSP this way, you ensure that every cryptographic module used for DIT is traceable to a specific FIPS 140-2 or 140-3 certificate, satisfying the requirements for SC-13 (Cryptographic Protection) in a machine-verifiable format.
Cryptographic Modules Implemented for Data-at-Rest (DAR)
The approach is the same as in the cryptographic module data-in-transit section.
Component Representation: Data-At=Rest Example Product with FIPS 140-2 Validation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300012
type: software
title: Database Row Encryption Module
description: Briefly describe the cryptographic module.
props:
- name: asset-type
value: cryptographic-module
- name: version
value: 1.2.3
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: Databases-R-Us
- name: function
ns: http://fedramp.gov/ns/oscal
value: data-at-rest
remarks: Used to encrypt and decrypt rows in the database.
status:
state: operational
- uuid: 11111111-2222-4000-8000-009001200001
type: validation
title: Database Row Encryption Module (DREM)
description: Briefly describe the cryptographic module.
props:
- name: asset-type
value: cryptographic-module
- name: validation-type
value: fips-140-2
- name: validation-reference
value: '0000'
status:
state: operational
Understanding the Data-at-Rest (DAR) Mapping
In the OSCAL representation of data-at-rest protections, the focus shifts from communication protocols to the specific encryption mechanisms securing stored information.
Defining the Storage Function: The property name: function with the value data-at-rest explicitly categorizes the module’s role. The accompanying remarks field—such as "Used to encrypt and decrypt rows in the database"—provides the necessary context for human reviewers to understand the scope of the encryption (e.g., full-disk vs. application-layer encryption).
Asset Categorization: By using the asset-type: cryptographic-module property, the component is tagged for automated compliance auditing. This allows the system to verify that every component handling sensitive federal data is linked to a valid cryptographic implementation, directly supporting SC-28 (Protection of Information at Rest) .
Validation Linkage: Similar to the data-in-transit model, the software component is linked to a validation component that holds the NIST CMVP metadata. The validation-reference (e.g., 0000 ) acts as the source of truth for the FIPS 140-2 or 140-3 certificate number, ensuring that the module meets the mandatory federal security standards for data storage.
By organizing DAR in this manner, the SSP provides a granular inventory of encryption at every layer of the technology stack—from the database row level up to the storage volume—while maintaining a clear audit trail to the validated cryptographic provider.
NOTE:
While the examples show FIPS 140-2, the same OSCAL structure applies to FIPS 140-3. Simply update the `validation-type` property to reflect the current standard.
System Components and Inventory
Inventory Approaches
OSCAL makes two approaches available for depicting the system inventory:
Flat Approach : Aligns with today's FedRAMP Integrated inventory workbook where all of the information on a spreadsheet row is captured in a single assembly.
Normalized Approach : Common information is normalized as OSCAL components. inventory-items point to components for common information.
With the flat 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.
See Inventory: Flat Approach for more information.
Retrofit Adoption Path: MVP
If you have an existing FedRAMP authorization and are using the FedRAMP inventory spreadsheet template, start with the flat approach, and migrate over time to the normalized approach.
With the Normalized 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.
See Inventory: Normalized Approach for more information.
New Adoption Path: Core
If you are adopting OSCAL at the beginning of your FedRAMP journey, define components first, then regerence those components as you generate inventory.
Example
The same Linux operating system is used as the platform for all database and web servers. Most details about operating system are captured once as a component, including OS 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 are linked to the component.
Inventory: Flat Approach
The flat approach to inventory is only intended as a starting point for service providers converting from a legacy FedRAMP inventory spreadsheet template.
If you are not converting legacy inventory, use the Inventory: Normalized Approach .
With the flat 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.
Flat Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
inventory-items:
- uuid: 11111111-2222-4000-8000-011000000001
description: Legacy Example (No implemented-component).
props:
- name: asset-id
value: unique-asset-ID-01
- name: ipv4-address
value: 10.1.1.1
- name: ipv6-address
value: 2001:db8:3333:4444:5555:6666:7777:8888
- name: virtual
value: 'no'
- name: public
value: 'no'
- name: fqdn
value: dns.name
- name: uri
value: uniform.resource.identifier
- name: netbios-name
value: netbios-name
- name: mac-address
value: 00:00:00:00:00:00
- name: asset-type
value: operating-system
- name: serial-number
value: 'Serial #'
- name: asset-tag
value: Asset Tag
- name: vlan-id
value: VLAN Identifier
- name: network-id
value: Network Identifier
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: Big Vendor, Inc.
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: database
- name: allows-authenticated-scan
value: 'no'
remarks: If no, explain why. If yes, omit remarks field.
- name: physical-location
value: Physical location of Asset
- name: is-scanned
value: 'yes'
remarks: If no, explain why. If yes, omit remarks field.
- name: function
value: Required brief, text-based description.
remarks: Optional, longer, formatted description.
links:
- href: '#11111111-2222-4000-8000-009000000002'
rel: validation
- href: '#11111111-2222-4000-8000-001000000059'
rel: baseline
responsible-parties:
- role-id: asset-owner
party-uuids:
- 11111111-2222-4000-8000-004000000016
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-004000000017
remarks: 'COMMENTS: Additional information about this item.
This links to a FIPS 140-2 validated software component that is used by this
inventory item. This type of linkage to a validation through the component
is preferable to the link[rel=''validation''] example above.'
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.
Inventory: Normalized Approach
The normalized approach is prefered. Organizations starting new with no legacy inventory reporting should use this.
For organizations converting from a legacy FedRAMP inventory spreadsheet template, consider starting with the Inventory: Flat Approach and migrating to the normalized approach over time.
With the Normalized 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.
Component-based Representation
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300300
type: software
title: Linux Operating System
description: This is a web server that communicates with a database via an encrypted connection
props:
- name: asset-type
value: operating-system
- name: allows-authenticated-scan
value: 'yes'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: web
links:
- href: '#11111111-2222-4000-8000-001000000059'
rel: baseline
status:
state: operational
inventory-items:
- uuid: 11111111-2222-4000-8000-011000000023
description: Instance of the Linux Operating System
props:
- name: asset-id
value: unique-asset-ID-23
- name: asset-type
value: operating-system
- name: ipv4-address
value: 10.23.23.23
- name: ipv6-address
value: 0000:0000:0000:0000:0000:ffff:0a17:1717
- name: virtual
value: 'yes'
- name: public
value: 'no'
- name: fqdn
value: linux-host.example.internal
- name: physical-location
value: Primary Data Center
- name: is-scanned
value: 'yes'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
responsible-parties:
- role-id: asset-owner
party-uuids:
- 11111111-2222-4000-8000-004000000010
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-004000000017
implemented-components:
- component-uuid: 11111111-2222-4000-8000-009000300300
Notes:
If component-sample is an image of a Linux virtual machine (VM), and 10 instances of that VM are in use, there would be one (1) component assembly and ten (10) inventory-item assemblies, all referencing the same component.
Inventory Data Locations and XPath Queries
The following queries are intended to show where to find each piece of information within the system inventory template.
FedRAMP Security Controls
Control Response: Approaches
OSCAL offers a great deal of flexibility for controls responses. To balance consistency, interoperability and ease of adoption, the OSCAL Foundation recommends two approaches:
Flat Approach : Aligns with FedRAMP's SSP Word template where control responses are at the statement level, and the narriative alone distinguishes between compoents within the response.
Normalized Approach : Control responses are decomposed to align with relevant components.
With the flat approach , the entire statement-level response from a FedRAMP Word-based SSP is represented "as-is" in a single by-component assembly in OSCAL.
See Control Response: Flat Approach for more information.
Retrofit Adoption Path: MVP
If you have an existing FedRAMP authorization with an existing Word-based FedRAMP SSP, start with the flat approach and migrate over time to the normalized approach.
With the normalized approach , components are associated with control response statements. Responses are possible either for the whole statement or assocaited with a specific component relative to the statement response.
See Control Response: Normalized Approach for more information.
New Adoption Path: Core
If you are adopting OSCAL at the beginning of your FedRAMP journey, respond to control statements at the component level as much as practical. Define OSCAL components ahead of time, and be prepared to add components as needed for control response authoring.
Control Response: Flat Approach
The flat approach to control responses is only intended as a starting point for service providers converting from a legacy FedRAMP SSP Word template.
If you are not converting a legacy SSP, use the Control Response: Normalized Approach .
With the flat approach, the entire statement-level response from a FedRAMP Word-based SSP is represented "as-is" in a single by-component entry in OSCAL.
Retrofit Adoption Path: MVP
With OSCAL SSPs, all control responses must be assocaited with a component. To ensure this is always possible, OSCAL SSPs also require the existence of a this system component, which represents the entire system.
When converting from a legacy Word-based SSP, the simpelest form of OSCAL adoption is to move the text from each control statement response into the "this system" component response.
Transition to Normalized
Over time, components can be added to the components array in system-characteristics . Some components will be added in order to represent SSP tables, such as leveraged authorizations, external services and cryptographic modules. Others may be added to support inventory normalization . Add any additional components you need to support or control responses.
At any time, additional by-components entries can be added to a statements entry, and linked to a component. This may occur one component at a time.
Example Transition
The legacy Word-Based SSP, response to AC-1, Statement a is:
The Trust an Compliance Team developed, maintains and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.
The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt
MVP OSCAL Representation
The entire statement above is represented as follows:
metadata/roles entries for the ISSO and Trust and Compliance Team.
a this-system entry in the components array
an implemented-requirements entry for AC-1 ( ac-1 )
a statements entry for AC-1, part a ( ac-1_smt.a )
a by-components entry with the component-uuid value of the this-system entry in the components array
a description field with the statement from the Word-based SSP.
system-security-plan:
metadata:
roles:
- role-id: information-system-security-officer
title: ISSO
- role-id: trust-and-compliance
title: Corporate Trust and Compliance Team
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'This component represents the entire system or authorization boundary.'
control-implementation:
description: 'OSCAL-required field.'
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: 'The Trust an Compliance Team developed, maintains and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.
The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt.'
implementation-status:
state: implemented
responsible-roles:
- role-id: information-system-security-officer
- role-id: trust-and-compliance
Transition
In moving to the normalized approach, OSCAL components must eventually be defined for required documents. This will result in additional entries to the components array as follows:
Additional entries to the components array
a type set to policy or process-procedure
a title with the title of the policy or procedure
a responsible-roles array with the appropraite role-id cited.
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000001
type: policy
title: XYZ Access Control Policy
description: 'This is the corporate AC Policy.'
responsible-roles:
- role-id: trust-and-compliance
- uuid: 11111111-2222-4000-8000-009000000003
type: policy
title: PDQ Access Control Procedure
description: 'This is the system-specific AC Procedure.'
responsible-roles:
- role-id: information-system-security-officer
Once defined, additional by-component entries may be added to the AC-1, part a atatement; however they do not need to be added all at once. For example, the policy may be addressed in one pass and the procedures deferred.
add one additional by-components entry for the policy
move only the policy portion of the control response
drop the trust-and-compliance role
It is not necessary to move the trust-and-compliance role as it is defined for the component above.
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: 'The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt.'
implementation-status:
state: implemented
responsible-roles:
- role-id: information-system-security-officer
- component-uuid: 11111111-2222-4000-8000-009000000001
uuid: 11111111-2222-4000-8000-012000010102
description: 'The Trust an Compliance Team developed, maintans and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.'
implementation-status:
state: implemented
When all components have been added, the original by-components entry for this-system may still be used for providing information (control responses, status differences or additional roles) that do not fit specific component responses.
Control Response: Normalized Approach
The normalized approach is prefered. Organizations starting new with no legacy SSP content should use this.
For organizations converting from a legacy FedRAMP SSP Word template, consider starting with the Control Response: Flat Approach and migrating to the normalized approach over time.
With the normalized approach, system elements are first defined as OSCAL components . Relvant components are then associated with control statements via statements / by-components entries. Control responses are then provided in the approrpiate by-component entry.
system-security-plan:
Responding to Control Baselines
OSCAL references controls in baselines and catalogs. The statements are not duplicated into an OSCAL SSP the way they are with a Word SSP.
Conrol baseline requirements are imported by an OSCAL SSP and referenced as needed.
Importing a Baseline
Import the appropriate FedRAMP Baseline, either as an OSCAL profile or as an OSCAL reserved profile catalog .
system-security-plan:
import-profile:
href: https://raw.githubusercontent.com/OSCAL-Foundation/fedramp-resources/refs/heads/main/baselines/rev5/yaml/FedRAMP_rev5_HIGH-baseline-resolved-profile_catalog.yaml
The OSCAL Foundation makes the FedRAMP baselines available as OSCAL _profiles_ and _resolved profile catalogs_ [on GitHub](https://github.com/OSCAL-Foundation/fedramp-resources/tree/main/baselines/rev5).
See Baselines for more information about those files.
Referencing Controls
With the approprate baseline imported above, OSCAL SSP control responses simply cite the control id from the baseline.
For each control in the imported baseline there MUST be exactly one implemented-requirements entry that includes:
a uuid
a control-id with a value that matches a control in the imported baseline
a set-parameters array, only if the control has one or more parameters that don't already have their value established in the baseline. See Parameter Assignments for more information.
a statements array contains the control responses. See Control Implementation Statements for more information.
system-security-plan:
control-implementation:
description: 'This description field is required by OSCAL, but ignored by FedRAMP.'
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
set-parameters:
[content cut]
statements:
[content cut]
- uuid: 11111111-2222-4000-8000-012000010001
control-id: ac-2
[content cut]
- uuid: 11111111-2222-4000-8000-012000010002
control-id: ac-2.1
[content cut]
Responsible Roles
Every control should have one or more responsible roles identified.
In OSCAL, there are three possible sources for responsible roles:
By Control : (Retrofit MVP only) assign responsible roles to the implemented-requirement for the entire control
By Component (Implied) : infer responsible roles from the components cited in the by-component array
By Component (Explicit) : assign responsible roles to the statement / by-component array
Retrofit Adoption Path: MVP
When initially converting a Word-based FedRAMP SSP to OSCAL, assign all roles by control to the implemented-requirements / responsible-roles array. This aligns with the FedRAMP Word-based SSP template.
As the SSP is migrated to a normalized approach using components, the assignment of roles is moved from the entire control to statement-level, component responses.
With fully normalized OSCAL content, responsible roles are inferred via the components associated with a control via statements / by-components . Each assocaited component SHOULD have owner and administrator responsible roles and linked to specific parties (teams or individuals).
If additional roles need to be cited, they are explicilty assigned to by-components / responsible-roles . If an explicitly needed role does not associate cleanly to a specific component, it is assigned to the by-components / responsible-roles entry for this system (component type = this-system ).
WORKING HERE
Representation
Parameter Assignments
Representation
If a FedRAMP control has one or more parameters, add a set-parameters array Within an implemented-requirements entry. There must be one set-parameters entry for each parameter in the control as follows:
a param-id set to the parameter value from the OSCAL-based FedRAMP baselines
a values array with:
one string entry per response
If the response is list, such as a list of user types to receive a procedure, add one entry per list item.
Only set parameters at the `implemented-requirements` level. While OSCAL also supports the ability to set parameters within `by-components` entries, this does not align with FedRAMP's handling of parameters and should not be used.
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
set-parameters:
- param-id: ac-01_odp.01
values:
- all managers, administrators and users of the system
- param-id: ac-01_odp.02
values:
- all managers and administrators of the system
- param-id: ac-01_odp.03
values:
- System-level
- param-id: ac-01_odp.04
values:
- System Architect
- param-id: ac-01_odp.05
values:
- at least every 3 years
- param-id: ac-01_odp.06
values:
- change in organizational legal status or ownership
- param-id: ac-01_odp.07
values:
- at least annually
- param-id: ac-01_odp.08
values:
- change in policy or a security incident involving a failure of access control
mechanisms
Selection Parameters and Nested Parameters
Some select parameters contain one or more assignment parameters. In this instance, simply provide the final selection value within the set-parameters entry for the select and omit any set-parameters entries related to the assignment .
Example
AC-7_ part (b) has three assignment parameters nested within a single selection parameter. Line breaks and bullets have been added below to better illustrate the nesting.
Automatically
[ Selection (one or more):
lock the account or node for an [ Assignment : organization-defined time period];
lock the account or node until released by an administrator;
delay next logon prompt per [ Assignment : organization-defined delay algorithm];
notify system administrator;
take other [ Assignment : organization-defined action]]
when the maximum number of unsuccessful attempts is exceeded.
Although the OSCAL controls will have four parameters, only the final value for the selection parameter is assigned in the SSP. The other parameters are ignored.
If more than one choice is is applicable, add each as a separate entry in the values array. For example if the final choices are:
lock the account or node for an [ Assignment : 30 minutes];
lock the account or node until released by an administrator;
The set-parameters array would be:
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-7
set-parameters:
- param-id: ac-07_odp.03
values:
- lock the account or node for 30 minutes;
- lock the account or node until released by an administrator;
Parameters ac-07_odp.01 and ac-07_odp.02 belong to part (a). They would normally be included and are only omitted for the example.
Parameters ac-07_odp.04 , ac-07_odp.05 and ac-07_odp.06 are part of ac-07_odp.03 and are omitted.
Implementaiton 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="http://fedramp.gov/ns/oscal")
field containing the intended completion date. With XML, prop fields
must appear before other sibling fields (such as set-parmeter , responsible-role , etc.), 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
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 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.
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 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="http://fedramp.gov/ns/oscal") field containing the UUID of the
leveraged authorization as it appears in the
/*/system-implementation/leveraged-authorization assembly.
Representation
Responding By Component
OSCAL SSPs represent control responses in control-implementation / implemented-requirements / statements .
See Control Implementation Statements to understand how to associate control responses with specific baseline controls and control statements.
Within statements , all responses must be assocaited with one or more components via the by-components array.
OSCAL enables you to be as granular as you wish. Individual components may be added for operating systems, container images, firewalls, policies, procedures and plans. There is always a "this-system" component representing the entire system / authorization-boundary.
The "This System" Component
There must always be a "This System" component defined in the SSP. For control responses, this is used in several ways:
Holistic Overview : The SSP author may wish to provide a more
holistic overview of how several components work together, even if
details are provided individually in other by-component assemblies.
Catch-all : Any control response that does not cleanly align with
another system component may be described in the "This System"
component.
Legacy SSP Conversion : When converting a legacy SSP to OSCAL,
the legacy control response statements may initially be associated
with the "This System" component until the SSP author is able
to provide responses for individual components.
responses occur within by-components / description .
In a legacy Word-based SSP, it was often necessary to provide narriative for each relevant component in a control response. The entire narriative for all components was captured in a single table cell as separate paragraphs.
With OSCAL, you have the option of keeping a single narriative block, or breaking out a control response by its discrete components.
Retrofit Adoption Path MVP
When converting a Word-based FedRAMP SSP to OSCAL, move all control responses to the this-system component.
Every OSCAL SSP must have a this-system component defined. It is the only required component.
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'Represents the entire authorization boundary'
status:
state: operational
Every statements / by-components array has exactly one entry that references the this-system component and includes the content from the Word-based SSP.
Each statements array entry includes:
a required uuid field
a required by-components array. Each array entry includes:
a required component-uuid field that cites the this-sytem component from above.
a required uuid field
a required description field that contains the content from the Word-based SSP control response.
a required implementation-status element with:
a required state field with a value of of implemented .
system-security-plan:
control-implementation:
description: n/a.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: Word-based SSP AC-1, statement a response.
implementation-status:
state: implemented
- statement-id: ac-1_smt.b
uuid: 11111111-2222-4000-8000-012000010200
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010201
description: Word-based SSP AC-1, statement b response.
- statement-id: ac-1_smt.c
uuid: 11111111-2222-4000-8000-012000010300
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010301
description: Word-based SSP AC-1, statement c response.
implementation-status:
state: implemented
See the Example below.
Native Adoption Path
When creating an SSP from scratch, ensure appropriate components are defined before authoring a control response. The this-system component must always be present. Other components are present baed on their use within the sytem. See Components for more information.
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'Represents the entire authorization boundary'
status:
state: operational
- uuid: 11111111-2222-4000-8000-009000600001
type: policy
title: Access Control and Identity Management Policy
description: 'A corporate policy used for the system.'
status:
state: operational
Every statements / by-components array has one or more entries that reference components describes how that component is satisfying that control requirement statement.
Each statements array entry includes:
a required uuid field
a required by-components array. Each array entry includes:
a required component-uuid field that cites the appropriate component from above.
a required uuid field
a required description field that contains the content from the Word-based SSP control response.
a required implementation-status element with:
a required state field with a value of of implemented .
system-security-plan:
control-implementation:
description: n/a.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000600001
uuid: 11111111-2222-4000-8000-012000010102
description: Describe how this policy satisfies part a.
implementation-status:
state: implemented
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: "Provide general context about satisfying part a that doesn't fit a defined component."
implementation-status:
state: implemented
Example
IA-2 Identificaiton and Authentication (Organizational Users) is satisfied by a combination of:
the IA Policy
an IA Procedure
a container running KeyCloak
an enterprise directory capability
This was originally described in the the IA-2 narriative as:
All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
The IA Policy requires use of the enterprise directory for authentication of organizational users. The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
Within the OSCAL SSP, this entire statement can initially be assocaited with the "this-system" component in the by-component response to AC-2.
by-component ( this-system )
All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
The IA Policy requires use of the enterprise directory for authentication of organizational users. The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
Moving Toward Normalization
At a later date, the SSP author can define components for the IA Policy and system-level IA Procedure and associate them with AC-2. The content shifts to be represented like this:
by-component ( this-system )
All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
by-component ( policy )
The IA Policy requires use of the enterprise directory for authentication of organizational users.
by-component ( process-procedure )
The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
Fully Normalized
Eventually, components are added for KeyCloak and the enterprise directory; however, some of this narriative describes how the two work together. The this-system component can still be used for any narriative that doesn't fit cleanly in another component.
by-component ( this-system )
All components requiring authentication are configured to redirect users to KeyCloak.
by-component ( software / KeyCloak)
When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication.
If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
by-component ( service / enterprise directory)
The enterprise directory reports the user's authentication success or failure back to KeyCloak.
by-component ( policy )
The IA Policy requires use of the enterprise directory for authentication of organizational users.
by-component ( process-procedure )
The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
This is now fully normalized.
Control Implementation Statements
Typically, the controls in the FedRAMP baselines have lettered parts (a., b., etc.). A few only have a top-level statement with no parts. Current FedRAMP templates expect responses at the lettered part level when present and at the top-level otherwise.
OSCAL SSPs cite controls and control requirement statements in responses.
Within the OSCAL FedRAMP baselines, each control statement is assigned an identifier. Any lettered parts are also assigned identifiers.
Citing statement identifiers correctly is critical to automated processing.
See Citing Control Statements for important information.
Typical
Most FedRAMP controls have two or more lettered parts. FedRAMP expects control responses at this level.
Within the control-implementation / implemented-requirements array, each entry includes:
a required uuid field
a required control-id field that cites the control using its id from the baseline .
a required statements array. Each array entry includes:
a statement-id field that cites the control statement using its id from the baseline .
a by-components array
See Responding By Component for more information.
Multi-Part Statement Representation
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
[content cut]
Non-Typical
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
A single-statement representation is identical to a typical multi-part statement representation, except for the following:
there is only one entry in the statements array
the statement-id value cites the baseline ID for the statement part itself instead of one of its child parts.
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-2.1
statements:
- statement-id: ac-2.1_smt
uuid: 11111111-2222-4000-8000-012000010100
by-components:
[content cut]
Control Response: Policies, Procedures, Plans, RoB, and Guides
Most FedRAMP-required attachments derive their requirement from one or more NIST SP 800-53 controls.
With an OSCAL SSP, the attachment is linked directly from the control. This is how tools know which attachment satisfies each requirement.
Control ID
Artifact to Link
Expected
Each -1
Policy
1
Each -1
Procedure(s)
1+
SA-5 ( id = sa-5 )
Appendix D: User Guide
1
PL-4 ( id = pl-4 )
Rules of Behavior
1
CP-2 ( id = cp-2 )
Information System Contingency Plan (ISCP)
1
CM-9 ( id = cm-9 )
Configuration Management Plan (CMP)
1
IR-8 ( id = ir-8 )
Incident Response Plan (IRP)
1
CA-7 ( id = ca-7 )
Continuous Monitoring Plan
1
SR-2 ( id = sr-2 )
Supply Chain Risk Management Plan (SCRMP)
1
Retrofit MVP
For Retrofit MVP, simply use a links array in the implemented-requirements entry for each "-1" control.
system-security-plan:
control-implementation:
description: There is one control in this example. Follow this pattern for each
additional control.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
links:
- href: ./AC_Policy.docx
rel: policy
media-type: application/docx
- href: ./AC_Procedure.docx
rel: procedure
media-type: application/docx
Normalized
For Retrofit Advanced, and all New adoption:
Attach the document as a back-matter resource.
Create a component that represents the document
Specify the component in the control response
Attach Document
Attach each document as back-matter / resources entries and include a props array with:
name set to type
value set to policy , procedure , plan , users-guide or rules-of-behavior
system-security-plan:
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000005
title: Access Control and Identity Management Policy
description: A single policy that addresses both the AC and IA families.
props:
- name: type
value: policy
- name: published
value: '2023-01-01T00:00:00Z'
- name: version
value: '1.2'
rlinks:
- href: ./attachments/policies/sample_AC_and_IA_policy.pdf
media-type: application/pdf
Create Component
Create a component for each document in system-implementation / components and include:
a props array with one entry:
name set to implementation-point
value set to internal if the document is system-specific; or
value set to external and class set to corporate if the document is Corporate
a links array with one entry:
href contains a URI fragment that cites the back-matter resource
a hashtag ( # ) followed by the UUID of the back-matter resource.
rel contains attachment
All other fields depicted in the example are required by OSCAL to be present.
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000600001
type: policy
title: Access Control and Identity Management Policy
description: 'This is a corporate AC policy used for the system.'
props:
- name: implementation-point
value: external
class: corporate
links:
- href: '#11111111-2222-4000-8000-001000000005'
rel: attachment
status:
state: operational
Control Response
Use implemented-requirements / statements / by-components entries in every control response that cites the document.
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000600001
uuid: 11111111-2222-4000-8000-012000010102
description: Describe how this policy satisfies part a.
implementation-status:
state: implemented
Inheritence 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
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000020000
control-id: ac-2
statements:
- statement-id: ac-2_smt.a
uuid: 11111111-2222-4000-8000-012000020100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000020102
description: 'Confidential control response.'
implementation-status:
state: implemented
export:
provided:
- uuid: 11111111-2222-4000-8000-015000000001
description: This system's statement of capabilities which may be inherited
by a customer's leveraging systems toward satisfaction of AC-2, part a.
responsibilities:
- uuid: 11111111-2222-4000-8000-016000000001
provided-uuid: 11111111-2222-4000-8000-015000000001
description: 'Leveraged system''s statement of a leveraging system''s
responsibilities in satisfaction of AC-2, part a.'
responsible-roles:
- role-id: cloud-service-provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
See the NIST OSCAL Leveraged Authorization Presentation for more information.
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 the Response: Identifying Inheritable Controls and Customer Responsibilities section, and documented a component int the leveraging system SSP 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 must have the value flag set to the UUID of the leveraged system or component.
Representation
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000100004
type: system
title: Leveraged Authorized System
description: Briefly describe the leveraged system.
status:
state: operational
control-implementation:
implemented-requirements:
statements:
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000004
uuid: 11111111-2222-4000-8000-012000020104
description: For the portion inherited from an underlying FedRAMP-authorized
provider, describe **what** is inherited.
implementation-status:
state: implemented
inherited:
- uuid: 11111111-2222-4000-8000-017000000001
provided-uuid: 11111111-0000-4000-9009-002001002001
description: 'Optional description.'
satisfied:
- uuid: 11111111-2222-4000-8000-018000000001
responsibility-uuid: 11111111-0000-4000-9009-002001002002
description: 'Description of how the responsibility was satisfied.'
See the NIST OSCAL Leveraged Authorization Presentation for more information.
Citing Control Statements
OSCAL SSPs cite OSCAL baseline statement identifiers when representing control implementation responses. Citing the identifiers correctly is critical to machine processing.
Within OSCAL baselines, identifiers are assigned to statement parts and item parts for reference by SSPs.
The statement Part
All OSCal parts entries have:
a required id field; and
a required name field.
For every control in the FedRAMP baselines there is exactly one parts entry where name = statement . This is the statement part.
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
Simple Controls
For simple controls, the statement part has a prose field that includes the control requirement statement.
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
prose: 'Support the management of system accounts using {{ insert: param, ac-02.01_odp }}.'
The id value for the statement part (i.e. ac-2.1_smt ) is cited by the SSP's statements array when responding to this control.
Controls with Child Statements
For a control with child statements (a., b., etc.), the statement part includes a nested parts array. Every element in the nested parts array has:
a required id field; and
a required name field. Always with a value of item .
a prose field that includes this part of the control requirement statement.
an additional nested parts array IF this part has child parts.
Each control in the FedRAMP OSCAL baselines has a parts array at the root of the control. Each parts entry includes:
a required id
a required name .
catalog:
groups:
controls:
- id: ac-1
title: Policy and Procedures
parts:
- id: ac-1_smt
name: statement
parts:
- id: ac-1_smt.a
name: item
props:
- name: label
value: 'a.'
prose: 'Develop, document, and disseminate to {{ insert: param, ac-1_prm_1 }}:'
For SSP authoring, ignore any parts entry in the baseline outside of the statement part and its child parts. Other part types are for control assessments.
Response Point Properties
To aid SSP authoring tools in identifying the required statement level at which to respond, response-point properties are included in the FedRAMP baselines.
SSP authoring tools should limit the scope of response-point property searches to the statement part and its child parts. Ignore response-point properties in the parts related to assessments.
A response-point property appears in the props array and includes:
a name set to response-point
a ns set to http://fedramp.gov/ns/oscal
a value with a value that is any string and can be ignored.
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
props:
- name: response-point
ns: http://fedramp.gov/ns/oscal
value: You must fill in this response point.
prose: 'Support the management of system accounts using {{ insert: param, ac-02.01_odp }}.'
When an SSP tool encounters a parts entry that contains this property, it should be presented to users of SSP authoring tools as the expected level of response for that control.