OSCAL and FedRAMP Automation

Oscal and FedRAMP Automation: The current FedRAMP Authorization process is a struggle.  First, you must manage multiple regulatory standards and frameworks, which change over time. Second, regulatory standards and frameworks overlap in scope and can often conflict and be difficult to manage together. And, lastly, information systems continue to increase in size and complexity.

FedRAMP has collaborated with NIST to create the Open Security Controls Assessment Language (OSCAL) which helps in Oscal and FedRAMP Automation, a standard that can be enforced for the publication, implementation, and assessment of security controls.

What is OSCAL?

OSCAL is a set of formats expressed in XML, JSON, and YAML. These formats provide machine-readable interpretations of control catalogs, control baselines, system security plans, and assessment plans and their subsequent results. The OSCAL project is modeling each with the use of a framework known as Metaschema.

This framework allows for the definition of each OSCAL model in a given OSCAL layer. The information domain of each model is defined using Metaschema, creating an information model for each OSCAL model. An OSCAL schema represents a data model that defines how to represent an OSCAL information model in a serialized format, such as JSON, YAML, or XML. The OSCAL project uses the Metaschema framework to produce these schemas supporting the XML, JSON, and YAML formats.

This framework is also used to generate converters capable of converting OSCAL content for a given model to another supported format, and to produce the documentation in this section of the website for each OSCAL model as it applies to each format.

Why Oscal and FedRAMP Automation? What are the Key Benefits?

The formats provided by the OSCAL project help to unify and standardize the processes of documenting, implementing, and assessing security controls.

Goals:

• Decrease Paperwork
• Improve System Security Assessments
• Enable Continuous Assessment

Benefits:

1. Data-centric: Transitions the legacy approach of Word and Excel documents to a “data-centric” approach based  on common data standards such as XML/JSON
2. Integrated:  Allows developers to implement APIs
3. Extensible:  Puts security compliance data that expresses security controls in both machine and human-readable formats
4. Automated:  Apply the benefits of the “data-centric” approach to automate existing processes that are resource-intensive

OSCAL Architecture

• Catalog Layer
• Profile Layer
• Implementation Layer
• Assessment Layer
• Assessment Results Layer

1. Catalog Layer

Privacy and security documentation today often discusses controls and catalogs. Control represents a security requirement, guideline, procedure, or activity. A control catalog is an organized collection of controls. The OSCAL catalog layer provides a model to represent a control catalog. Typically,  catalogs are represented in human-readable documentary form, in which controls are represented as parts of a catalog document. Controls, as defined and described in catalogs, may also be referenced and configured in other documents; thus control information must be composed in a way to make it possible to migrate across different types of documents for different purposes, without losing identity and traceability.

2. Profile Layer

The OSCAL profile layer provides a model for selecting a specific set of security control requirements from one or more control catalogs. The term “profile” in OSCAL is also called a baseline or overlay in other terminology. The OSCAL Profile model allows for selecting security controls using a number of different mechanisms, as well as tailoring those controls.

A profile can include controls from more than one catalog, so an organization could have a single profile that references controls from several catalogs. OSCAL Profiles can also be based on other OSCAL Profiles, allowing baselines to be established based on the customization of another baseline.

3. Implementation Layer

The OSCAL implementation layer provides models for describing how controls are integrated into a single system or multiple, distributed components incorporated into a system. The OSCAL implementation layer defines two models:

• The component definition model will enable a set of components that give a description of the controls supported by a specific implementation of hardware, software, or service. Additionally, by giving compliance evidence, procedures, policies, or processes.
• The system security plan (SSP) model allows the security implementation of an information system to be defined based on an OSCAL profile (or baseline). SSPs expressed in a  machine-readable format can be easily imported into a software tool, allowing for increased automation of SSP validation and system assessments. An OSCAL SSP can also be transformed from a machine-readable format to a human-readable version.

4. Assessment Layer

The OSCAL assessment layer is foundational for structured, machine-readable assessment planning information. The assessment plan model  allows:

• Assessment plan information regarding how and when a system assessment should be conducted
• Assessment scope
• Proposed assessment activities

5. Assessment Results Layer

The OSCAL assessment results layer provides models for representing specific artifacts related to conducting an assessment and capturing the assessment results and findings. The OSCAL assessment layer defines two models:

1. The assessment results model visualizes information gathered from a set of assessment activities.  The assessment model supports information from periodic or continuous assessments.
2. The plan of action and milestones (POA&M) model illustrates the findings for a periodic or continuous assessment that needs to be resolved by the owners of the systems.  Artifacts will need to be found and documented as evidence for the discovered findings.

FedRAMP Automation (ATO)

Today, security controls and control baselines are constructed in proprietary formats, requiring excessive manual efforts to illustrate their implementation. A key takeaway of Oscal and FedRAMP Automation is to transform these security controls and control baselines from a text-based and manual approach, using Word and Excel documents, to automate a set of standardized and machine-readable formats, using JSON, XML, and YAML file types.

FedRAMP Templates

FedRAMP templates provide the framework and structure to gather and store the information regarding the system environment, responsibilities, and the current status of the baseline controls necessary for that particular system. Using templates with OSCAL helps FedRAMP Automation and streamline the Oscal and FedRAMP Automation process.

There are multiple different FedRAMP templates that are organized into different categories:

Category: Readiness Assessment Phase

• FedRAMP High Readiness Assessment Report (RAR) Template
• FedRAMP Moderate Readiness Assessment Report (RAR) Template

Initial Authorization Phase

• FedRAMP Initial Authorization Package Checklist
• FedRAMP System Security Plan (SSP) High Baseline Template
• FedRAMP System Security Plan (SSP) Moderate Baseline Template
• FedRAMP System Security Plan (SSP) Low Baseline Template
• SSP ATTACHMENT 4 – FedRAMP Privacy Impact Assessment (PIA) Template
• SSP ATTACHMENT 5 – FedRAMP Rules of Behavior (RoB) Template
• SSP ATTACHMENT 6 – FedRAMP Information System Contingency Plan (ISCP) Template
• SSP ATTACHMENT 9 – FedRAMP High Control Implementation Summary (CIS) Workbook Template
• SSP ATTACHMENT 9 – FedRAMP Low or Moderate Control Implementation Summary (CIS) Workbook Template
• SSP ATTACHMENT 12 – FedRAMP Laws and Regulations Template
• SSP ATTACHMENT 13 – FedRAMP Integrated Inventory Workbook Template
• SSP ATTACHMENT 13 – FedRAMP Integrated Inventory Workbook Template
• FedRAMP Security Assessment Plan (SAP) Template
• SAP APPENDIX A – FedRAMP High-Security Test Case Procedures Template
• SAP APPENDIX A – FedRAMP Moderate Security Test Case Procedures Template
• SAP APPENDIX A – FedRAMP Low-Security Test Case Procedures Template
• FedRAMP Security Assessment Report (SAR) Template
• SAR APPENDIX A – FedRAMP Risk Exposure Table Template
• FedRAMP Plan of Action and Milestones (POA&M) Template
• FedRAMP Agency Authorization Review Report Sample Template
• FedRAMP ATO Letter Template

Monitoring Phase

• FedRAMP Automation ATO Letter Template
• FedRAMP Annual Security Assessment Report (SAR) Template
• FedRAMP New Cloud Service Offering (CSO) or Feature Onboarding Request Template
• FedRAMP Vulnerability Deviation Request Form
• FedRAMP Significant Change Form Template
• Continuous Monitoring Monthly Executive Summary Template

FedRAMP Tailored

• FedRAMP Tailored LI-SaaS Requirements
• APPENDIX A – FedRAMP Tailored Security Controls Baseline
• APPENDIX B – FedRAMP Tailored LI-SaaS Template
• APPENDIX C – FedRAMP Tailored LI-SaaS ATO Letter Template
• APPENDIX D – FedRAMP Tailored LI – SaaS Continuous Monitoring Guide
• APPENDIX E – FedRAMP Tailored LI – SaaS Self-Attestation Requirements

How Ignyte Assurance Platform is meeting OSCAL

• Ignyte Assurance consumes Oscal and FedRAMP Automation compliant content.
• Ignyte Assurance provides Oscal and FedRAMP Automation compliant content API’s.