An Introduction to OSCAL

An Introduction to OSCAL

The Open Security Controls Assessment Language (OSCAL) is a set of data formats that is used to express machine-readable representations of control catalogs, baselines, and security documentation. It is important to recognize that OSCAL is not a tool, but instead a language. Using OSCAL allows us a data interchange format between certain actors (such as catalog authors, security professionals, and assessors) and tools (vulnerability management tools, assessment tools, and so on). Through the use of OSCAL, information can be deduplicated with a custom level of granularity and flexibility. 

OSCAL can be used to develop documentation and other “paper-based” assessment processes such as system security plans (SSPs), assessment plans, and results. In other words, OSCAL can be used to facilitate the automation of tasks that in the past required documents and processes that did not scale well in modern systems, such as cloud-based systems. OSCAL was originally developed by the National Institute of Standards and Technology (NIST) in hopes to automate FedRAMP authorizations. As of the time of writing, OSCAL supports JSON, XML, and YAML formats. 

Benefits of OSCAL

Having a machine-readable format for compliance opens the door for automation. Automation saves resources and has long term promises for returns on investment in both time and money. OSCAL tackles the problem of manually creating documentation head on and can result in accelerating the Authority to Operate (ATO) process. In May 2022, FedRAMP received their first OSCAL SSP and hopes to accept more authorization deliverables using OSCAL. 

In addition to automation, OSCAL allows for the creation of validation rules when examining compliance against evidence created in this structured format. This paves the way for consistent feedback based on the controls of a specific compliance framework. 

OSCAL Components

OSCAL enables automated traceability through layer constructs. There are three major layers for OSCAL. The models allow different assessments and results to be created and combined in order to automate the management of a security plan for the system.

Controls Layer

The catalog model is the rules of representing security controls. For example, PCI or NIST 800-53. Ready to implement machine generated security control catalogs that align with a variety of frameworks, such as NIST Special Publication 800-53. Note that an organization can create their own catalog to document their own security controls. OSCAL Profile Model is created by importing one or more control catalogs. In other words, the profile model can concatenate multiple profile catalogs. 

Implementation Layer

The OSCAL SSP model contains the component model. The component model can have specific profiles associated with it. With the component model, security tooling vendors can use this to programmatically document how their product fulfills security requirements. The OSCAL SSP model is created by importing the profile. This can be used to generate a SSP to show how an organization’s controls are satisfying a compliance framework.

Assessment Layer

The Assessment Layer contains several models important to demonstrate the effectiveness of security controls – in other words to contain evidence that a system is compliant with certain security frameworks. The assessment plan model is created by importing the SSP model. The OSCAL assessment results model is created by importing the OSCAL assessment plan. The OSCAL plan of actions and milestones (POAM) model is directly aligned with the SSP model. 

How to get started with OSCAL

To get started with OSCAL, NIST has walkthrough tutorials that provide step by step walkthroughs on how to create OSCAL in many formats. 

On GitHub, there is a great collection of community resources that are available that helps introduce OSCAL. Some of the more interesting ones are highlighted below: 

• MITRE’s InSpec OSCAL Plugin can be used with Chef Inspec to analyze the state of infrastructure, and then take the data from InSpec to configure input variables for a profile.
• IBM’s Compliance Trestle is a collection of tools that can be used to create, validate, and generate artifacts utilizing OSCAL. A set of examples can be found in this repository, and shows capabilities such as creating control catalogs from a spreadsheet, creating SSPs, and performing tasks for assessment results. 
• OSCAL Tools is a great resource published by NIST that shows a list of tools that currently use OSCAL. Note that OSCAL can be ingested by GRC tools such as Ignyte and FedRAMP SSPs can be drafted using tools such as Xacta 360. 

What’s Next with OSCAL?

OSCAL is still in early development, having its first major release (OSCAL version 1) in 2021. In OSCAL 1.1, a customer responsibility model is planned to be used which can align with Google Cloud and AWS’s responsibility models. A mapping model is also planned to allow mapping between different regulatory frameworks. The relation can be tailored based on regulatory frameworks.