Automating Cloud Policies with OSCAL

Writing policy can be a cumbersome part of a security program, especially when the organization may not have those that are dedicated to writing policy. NIST has been developing the Open Security Controls Assessment Language (OSCAL) since 2019 to help alleviate the pain that comes with writing policy.

It’s important to note that OSCAL policy automation should not be confused with Policy as Code that other tools such as HashiCorp Sentinel and Open Policy Agent (OPA) provide.

Automating Policies and System Security Plans (SSP)

A value-add that OSCAL provides is the automation of creating policies. For FedRAMP, the authoring of an SSP is important in order to achieve Authorization to Operate (ATO) status. An open source project, Compliance Trestle has an SSP author demo that can be used to do this.

Since 2015, ScaleSec have been pioneers in automating FedRAMP for customers. For example, we have developed tools such as FedRAMPup to help with the automation of an SSP for cloud service providers and developing FedRAMP-compliant infrastructure as code (e.g. Terraform).

Testing Security Controls with DevOps Toolsets

In order for OSCAL to be effective, it must also integrate with DevOps tools. Integrating with existing tooling, such as Kubernetes configuration files, helps to ensure that controls can be tested with minimal friction. The Kubernetes SIGs maintain a Python transformer that converts Kubernetes YAML to OSCAL. In addition to looking at configuration before it’s deployed to cloud infrastructure, tools such as Chef Inspec can inspect the already deployed environment configuration to populate control catalogs that map back to compliance frameworks.

Reporting Adherence to Security Controls

Tools exist that examine a cloud environment’s security posture, generally referred to as Cloud Security Posture Management (CSPM). CSPM tools are effective at analyzing the configuration of a cloud environment, but may miss out on other aspects such as process and security controls that exist outside of the cloud environment (such as code analysis and scanning). This is where OSCAL comes in. Some governance, risk and compliance (GRC) tools such as GovReady can already ingest OSCAL to provide reports.

Conclusion

OSCAL could be used for policy automation, automated testing of controls, and integrations to other tools for reporting purposes such as GRC tooling. There are many open source projects and commercial products that are being developed to automate roles that were historically filled by security professionals who specialize in policy. While OSCAL won’t yet automate all aspects of creating security policy, the capabilities and toolsets are being developed to make policy easier than ever.