Today’s blog is from Michaela Iorga, Senior Technical Lead of the Computer Security Division (CSD) in the Information Technology Laboratory at NIST. Michaela’s team at NIST is working with the industry to develop the Open Security Controls Assessment Language (OSCAL). OSCAL is a 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.
We asked Michaela a series of questions about the OSCAL project, which have been answered by her, below.
The Federal Information Security Management Act (FISMA) Implementation Program was established in January of 2003 as a result of the first Federal Information Security Management Act (PL 107-347, 44 USC 3541) of 2002. Since then, the NIST FISMA Implementation Program currently renamed Risk Management program, has developed the core key security standards and guidelines required by congressional legislation. More recently, the Federal Information Security Modernization Act of 2014 (PL 113-283, 44 USC 3554) emphasized the importance of information security to the economic and national security interests of the United States and required each federal agency to develop, document, and implement an agency-wide program to provide information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems. FISMA requires agency heads to report on the adequacy and effectiveness of the information security policies, procedures, and practices of their enterprise. For two decades, agencies worked diligently to implement the Office of Management and Budget’s (OMB) Circular A-130: “Managing Information as a Strategic Resource”, but the employed Authorization to Operate (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.
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. The complexity of the problem and the magnitude of the tasks demanded of these security practitioners calls for interoperable and portable security automation that starts with security documentation as code (i.e., documentation in machine-readable formats) and compliance as code that integrates the documentation into security assessments, auditing, and monitoring and provides traceability through the entire risk management process.
The idea of developing OSCAL was fueled by my frustration around the lack of transparency into cloud services’ security posture, in particular, from the cloud consumers’ perspective. From the beginning, OSCAL was envisioned to be the foundation for interoperable and portable security automation in support of Authorization to Operate processes for all types of systems, not just cloud-based systems – a very challenging task. Because of this challenge, our NIST team partnered in 2016 with GSA/FedRAMP to research and develop OSCAL – the standardized, openly-available, foundational representation of the security information in support of security automation and of risk management frameworks in general.
For some in the federal government, the approach of building new systems or service that meet Authorization to Operate requirements was to go and acquire the components for the system, literally build the system, configure it securely, manually document in a lengthy system security plan in MS Word or Excel how security requirements are satisfied, then assess the controls to the best of the assessor’s abilities, employing labor intensive, tedious checks, and configuration reviews. When security deficiencies were identified, then a risk decision for the system was made to either fix it or accept the risk in order to authorize the system to operate. Then monitoring the system was needed and scanning tools used to help on-going assessments. As systems became more complex and as we started adopting more and more cloud-based solutions, the assessors work, and the authorizing officials’ jobs became more difficult in making risk decisions, having to understand how the systems stack and how the controls are inherited or where the risks are. To ease this process, automation was obviously necessary. Because of that, many proprietary solutions have been developed by different vendors or by cloud providers, but some of their solutions are not interoperable and triggered vendor lock in. If an agency has a multi cloud strategy, then they need to deal with all these proprietary formats, for example, when it comes to systems’ scans for vulnerabilities.
Fast forwarding to today: we designed OSCAL not only to be able to represent the necessary security information in machine readable format so tools can consume this information and facilitate automation of the assessment process, but we also designed OSCAL with flexibility in mind so it can be used by different risk management regulatory frameworks without customizations. For example, OSCAL can be used to represent the SP 800-53 controls in XML, JSON and YAML, but at the same time, OSCAL can be used to represent the ISO/IEC 27002 controls, and SC27 WG1 plans on doing so.
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.
Our team works diligently towards the major OSCAL 1.0.0 release. In December 2020, we made available, for public review and stress-testing, the first set of release candidate (RC1) models. The initial feedback is very positive, and the comments or requests received are being incorporated in the release candidate 2 (RC2). We anticipate we will be able to release OSCAL 1.0.0 in May 2021 time frame. All this time (until May) will be used to engage the community of interest and to review the OSCAL models.
With that said, our team’s accomplishments are the source for larger benefits or accomplishments all security experts out there will be able to take advantage of. They will be able to substantially reduce the time to generate the needed information for an Authorization to Operate (ATO) decision, will be able to be more rigorous with less resources. Our internal estimates indicate that months of assessment efforts can be reduced to weeks, with additional benefits and enhanced security understanding of the systems assessed.
It is very important to note, that neither the system owners or assessors nor the adjudicating officials need to learn OSCAL or have to even ‘see’ it. OSCAL is for tools. What they will see is what the OSCAL-enabled tools will deliver – nice user-friendly interfaces or dashboards with all information in front of them. Similar to how Turbotax operates. And they will be able to focus on what they are subject matter experts on: assessing, auditing or adjudicating. If there is a need, human readable documentation can easily be created from documents in OSCAL.
OSCAL gained already international interest and adoption, and our team is very supportive of all US and international organizations interested in automating their assessment process using OSCAL. We are very confident, based on the initial feedback, that US Government security posture can be improved through improved automation of the ATO process with OSCAL. If you think of the broad adoption of cloud services by US Government and of the fact that all these cloud-based solutions need to meet security requirements, of the difficulties the assessors and the authorizing officials are faced with today when having to work with multiple sets of very large system security plans while trying to construct a clear picture of the systems stack, of each entity’s management responsibilities, then you can understand that having an OSCAL machine-readable representation of such information and having OSCAL-enabled tools that can parse the information and reconstruct it while bringing it all in one place, in front of the systems owners, assessors and authorizing officials is a huge improvement. OSCAL can do it. But this is the lowest hanging fruit of the returns in OSCAL investment. The same security information in OSCAL can be ingested by Governance Risk and Compliance tools and used to seed the assessment. With OSCAL, about 60% of the assessment can be automated.
But this is not applicable or beneficial only to cloud-based solutions. Imagine an agency that has 50-100 internal systems that need to be periodically reassessed and continuously monitored to maintain their ATO. Imagine each system will have a System Security Plan in human readable format – a 200 or more pages document, that needs to be reviewed by the assessors that needs to plan the assessment first then need to perform the actual assessment. For a system categorized as moderate impact level, the SSP document might need to describe the implementation of the 159 controls and 102 control enhancements that are part of the NIST 800-53 moderate baseline - unless some controls are tailored out. Then the assessors will have to assess all these controls and enhancements, and summarize the assessment results, and create a POA&M when applicable. Then the findings are shared with the authorizing official. The scanning results from the GRC tool need to be correlated and transformed from the proprietary format to human readable to be summarized and have the findings addressed.
Now if automation is used and the SSP is created in OSCAL, OSCAL will provide traceability to the controls baseline and to the catalog without repeating that information. OSCAL is also providing unique identifiers not only for the controls but also for the statements that are part of a control or control enhancements and also for the parameters of each statement, allowing for a more accurate and lower granularity representation of the controls implementation for each component of the system. OSCAL allows for the systems to be composed from components. A component definition will allow an organization to define playbooks of how the components of their systems ought to be secured. One can think of such approach as a Lego approach or building blocks.
Furthermore, an OSCAL assessment plan can then be generated by the assessing team and GRC tools that can import information in OSCAL and report back the assessment results in OSCAL can be used to automate a substantial percentage of the assessment process and the system’s continuous monitoring.
NIST-generated documentation is on our website: https://pages.nist.gov/OSCAL/documentation/ which is accessible from our project’s website: https://pages.nist.gov/OSCAL. I strongly encourage interested parties to navigate through the different pages of documentation NIST provides, by using the left-side navigation tabs, and review the concepts used in OSCAL, the logical layers aligned with the risk management approach and the models for each layer. My favorite pages are the ‘format outlines’ that provide the architectural maps for each model revealing the implemented assemblies, their relations, their cardinalities, their data types and – last but not the least – the hyperlinks to the referential material.
NIST also maintains several repositories on GitHub. The most important ones are: the OSCAL models (https://github.com/usnistgov/OSCAL), and the OSCAL content (https://github.com/usnistgov/oscal-content ) where interested parties can find the NIST SP 800-53 catalog of controls (rev 4 and rev 5) and their respective baselines in OSCAL (XML, JSON and YAML).
To stay up to date with the OSCAL’s projects, please visit https://pages.nist.gov/OSCAL/.
Remember to follow us on Twitter: @NISTcyber!