This is the second post of the GoComply series that introduces open source pipeline to produce and process OSCAL and FedRAMP documents. If You want to achieve continuous compliance at the lowest possible cost, GoComply project is here to help. With GoComply, You will rely on open source tooling and your data will be stored in standardized formats and thus you will have a enough head room and knee room to achieve your organizational goals.

Introduction to OSCAL

This blog post is gonna write itself, official OSCAL web page is well maintained and documentation is detailed yet easy to comprehend.

OSCAL stands for Open Security Controls Assessment Language. It is an industry wide effort lead by NIST (National Institute of Standards and Technology) to develop set of formats expressed in XML, JSON, and YAML. These formats provide machine-readable representations of control catalogs, control baselines, system security plans, and assessment plans and results. OSCAL is still under development.

When compared to OpenControl, OSCAL is better funded, less minimalist, and way more complete attempt to introduce machine-readable file format for automated compliance operations.

Lastly, let me here stand-up and applaud NIST for developing OSCAL completely in open. Everything that goes to the sausage is available for public to review, comment, or re-use. NIST maintains public chat channel, mailing-list and bi-weekly conference calls to spur collaboration across the industry. Very well done! 👏

Problem Statement

It is pretty clear that preexisting excel sheets and hundred pages long compliance documentation (.docx) have certain limitations.

Firstly, you cannot easily re-use tailored .docx document between deployments. .docx documents usually contain too much deployment specific customization. Unfortunately, the customization is never clearly marked as such and often times not easily recognizable to be deployment specific.

Secondly, .docx documents are impossible to produce machine readable policy from. While having machine-readable policy instructions is critical factor to enable automation. And automation is important for controlling the costs, and perhaps more importantly to free up your greatest security talent to focus on more high-level and less tedious tasks.

OSCAL Layers

To understand broad mandate of the OSCAL language, let’s dive into the OSCAL Layers. Following is list of main models (think of OSCAL file types) available in OSCAL 1.0.0 Milestone 3 Release.

Model (file type) Layer Description
Catalog Catalog Catalog of controls, think of NIST-800-53
Profile Profile Specific tailored controls, think of a subset of catalog
Component Implementation Control responses in real of specific product, think of control responses of OpenShift Container Platform 4
System Security Plan Implementation Control responses to the whole deployment, usually consisting of many components
Assessment Plan Assessment List of assessment objectives, activities and targets
Assessment Results Assessment Results Tightly coupled with the Assessment Plan, contains Results on top of it
Plan of Actions & Milestones Assessment Results List of remediation activities necessary, risk based information

As we can notice in this high-level overview of the models available, OSCAL provides data models that can describe compliance artifacts from requirements, through planning and assessment to remediation planning. Each step can be produced & maintained separately by different parties and thus the ecosystem enables good amount of flexibility to every party.

Conclusion

In this brief introduction to OSCAL, we have learned about the scope and high-level capabilities of this emerging standard. In the next post, we will take a look at the open source implementation of OSCAL; oscalkit.