WASHINGTON: A new computer language developed by NIST could greatly improve the ability to quickly assess compliance and security in cloud environments, including those used by the Defense Department’s JEDI, as well as those used by the Intelligence Community and the defense industrial base.
NIST released the first version of the Open Security Controls Assessment Language (OSCAL) on Thursday.
Because OSCAL provides formats that are machine readable, it will enable a greater degree of compliance and security automation in what are already highly automated cloud environments, enabling assessments to keep pace with software development and IT operations.
OSCAL will make it easier to more quickly assess cloud environment compliance and security against custom as well as established cybersecurity standards, such as NIST Special Publication 800-53.
“Security automation with OSCAL supports a more fastidious, faster, and repeatable assessment of cloud services’ security posture against multiple regulatory frameworks, and with less subjectivism coming from the human element,” Iorga wrote. “With OSCAL, about 60 percent of the assessment can be automated.”
Challenges to Securing DoD’s Cloud Environments
As Breaking Defense readers know, there is a huge push to implement DevSecOps and cloud Infrastructure as Code (IaC) in DoD’s cloud environments. DevSecOps and IaC are separate initiatives but are closely related. DISA’s Cloud Computing Program Office is spearheading a DoD-wide initiative on IaC, and the Air Force’s Chief Software Architect is co-leading a DoD-wide initiative to implement DevSecOps.
DevSecOps, which heavily relies upon IaC, provides opportunities to rapidly speed up how apps are developed and delivered to warfighters and warfighter support functions, such as logistics – shrinking the time it takes to develop and deliver apps from years, months, or weeks to hours or even minutes, in some cases.
But the same tech that enables this speed of delivery opens threat vectors that are increasingly targeted for hacking, security experts say. This is one reason many DoD entities are moving to zero-trust security. In the specific case of IaC, OSCAL provides the ability to automate compliance and security assessments in DevSecOps cloud environments.
IaC uses software to manage infrastructure (e.g., servers) rather than relying on manual configuration of hardware by people. IaC drastically increases the efficiency of provisioning, configuring, and managing cloud infrastructure. IaC is a component and enabler of DevSecOps, a practice that combines software development with IT operations, while “baking in” cybersecurity.
Underlying DevSecOps are the principles of continuous integration and continuous deployment (CI/CD). Continuous integration means that new code is always being tested, combined with other code updates, and merged into existing code. Such code updates can include new features, bug fixes, and security patches. Continuous deployment means the updated code is incorporated into an app’s code base as soon as it’s ready so that users can access the most recent version.
As an example of CI/CD, DoD “releases” its Platform One (i.e., its DevSecOps environment) 31 times a day, according to Nicolas Chaillan, the Air Force’s chief software officer and co-lead on the DoD-wide initiative to implement DevSecOps. Each release pushes out updated code. Highly automated DevSecOps is, partly, what makes DoD’s 31 daily releases possible.
One of the benefits of IaC is the ability to develop software-based, machine-readable templates that automate the series of tasks to, for instance, spin up cloud resources (e.g., compute, memory, storage, etc.) required to make apps available to users — whether the app is accessed via a soldier’s device, in a plane, or aboard a ship. Highly automated IaC is, partly, what makes rapid scalability possible.
“IaC is the foundation of everything we do,” said Chaillan, who spoke at a recent event hosted by the Institute for Critical Infrastructure Technology on emerging IaC and application programming interface (API) cybersecurity threat vectors.
But there’s one potential problem with the IaC approach. “Those templates can have misconfigurations or [security] vulnerabilities and replicate those at scale,” said Chris Hughes, principal cybersecurity engineer at Rise8, speaking at the same ICIT event. That means a security vulnerability in one template that is applied to, say, 100 servers quickly spreads the security vulnerability across the cloud environment.
The issue is further complicated because of how dynamic DevSecOps cloud environments are. The automation that enables speed also entails changing the underlying cloud infrastructure, as needed, to scale up or down required IT resources. As quickly as someone could document the environment using traditional methods, it likely will have changed again because of CI/CD.
“The problem of outdated docs,” Hughes notes, presents challenges for cybersecurity pros trying to secure complex, ever-changing environments, as well as those responsible for ensuring the security compliance of IT that is allowed to run in DoD’s cloud environment — a concept called authorization to operate (AtO). And in a CI/CD environment, there must be continuous AtO.
Technical writers have been modernizing workflows and adopting practices like docs-as-code to align to Agile software development practices and DevSecOps environments for years. But security compliance docs are a different beast from developer or user docs. Producing security compliance docs and then — most importantly — quickly applying the required security configurations in a timely and efficient manner to rapidly and frequently changing IT environments present a new challenge.
Enter OSCAL: Automated Cloud Compliance and Security Assessments
Iorga created OSCAL to help address the challenge of dynamic and complex IaC cloud environments. In the blog post, Iorga summarized the challenge: “For two decades, agencies worked diligently to implement the Office of Management and Budget’s Circular A-130: Managing Information as a Strategic Resource, but the employed [AtO] processes relied on paper-based documentation, manual assessment processes, and non-interoperable proprietary automation processes and tools that do not support security data portability.”
And, Iorga continued, “As systems become more complex and more cloud solutions are adopted, the jobs of security practitioners and authorizing officials have become more difficult — involving multiple sets of documents while requiring an understanding of how the systems stack, depend on each other, or interconnect and how the controls are inherited to identify risks that need to be mitigated.”
These legacy, paper-based security compliance processes don’t align with complex, fast-moving, ever-changing DevSecOps environments. So, how do operators ensure security compliance and AtO requirements in DevSecOps environments? Well, with automation, of course.
And OSCAL’s “interoperable and portable” nature means it can be used in a variety of cloud environments — from DoD and IC to federal civilian government and even the commercial sector.
Breaking Defense contacted NIST for comments from Iorga, but didn’t hear back before publication. Readers can review Iorga’s in-depth blog post and refer to OSCAL documentation and resources that NIST has published.
Iorga’s work could go a long way to enabling improved continuous AtO processes by incorporating automated compliance and security assessments into IaC templates, in turn allowing DoD to move at what Chaillan calls “the pace of relevance.”