Search Results

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-par...

FedRAMP's baselines are available in OSCAL XML, JSON and YAML formats on the OSCAL Foundation's fedramp-resources GitHub repository. The OSCAL Foundation is making FedRAMP baselines available both as OSCAL profiles and as pre-processed resolved profile catalog...

All FedRAMP artifacts include a title page. The content found on the title page is represented using core OSCAL content in metadata. title the artifact title as FedRAMP requires it to appear published the formal publication date of the artifact (using OSCAL ...

"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 pr...

SSP Approvals follow the Roles pattern, using the content-approver role. Defined Identifiers Required Role IDs: content-approver

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-19...

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 manag...

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 ident...

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...

Cryptographic Modules Implemented for Data-in-Transit (DIT) This page needs work: The examples needs to be converted to YAML A description of the YAML constructs needs to be provided OSCAL's component model treats independent validation of products and ser...

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...

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 ...

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...

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: Commo...

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 approa...

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 migra...

Every control should have one or more responsible roles identified. In OSCAL, there are three options for identifying responsible roles: By Control: (Retrofit MVP only) assign responsible roles to the implemented-requirement for the entire control By Compone...

Need rework and to cover aggregated parameters Every applicable control must have at least one responsible-role defined. There must be a separate responsible-role assembly for each responsible role. OSCAL requires the specified role-id to be valid in the defin...