What is OSCAL and Why Does It Matter for NIST and FedRAMP?
What is OSCAL and Why Does It Matter for NIST and FedRAMP?
Complying with federal cybersecurity guidelines is a difficult task. Unfortunately, many contractors and cloud service providers take a rather lax view of compliance, and it’s an all-too-common scenario for a company to build up standards and practices for audit time and let them slip immediately thereafter until the lead-up to the next audit.
Part of this is simply the immense complexity of cybersecurity. With hundreds of security controls across dozens of control families, with continuous monitoring in play, with POAMs and auditing, and more, there’s so much to consider that even just keeping track of it all can be a full-time job for multiple people.
Fortunately, the government and agencies like NIST and the DoD acknowledge this. It’s well-known that the greater the complexity and the greater the burden, the more likely people are to try to cut corners. There has been a significant push in recent years to simplify compliance, particularly within FedRAMP, specifically to account for this tendency. A prime example is the consolidation of impact levels from a complex table to three simple tiers.
Another way this simplification has manifested is through the creation and introduction of OSCAL. So what is OSCAL, who needs to use it, and why does it matter?
What is OSCAL?
OSCAL is an acronym that stands for the Open Security Controls Assessment Language. It’s a set of standards and formats developed by the National Institute of Standards and Technology (NIST) for all agencies and contractors to use. It standardizes the language used in the documentation, implementation, and assessment of security controls.
If you’ve ever had a case where two people in an organization are using the same term to refer to two different things, you know how important standardized language is. That’s the goal of OSCAL: to provide set, tangible meanings for terminology. Within that overarching goal are a variety of sub-goals.
OSCAL takes the form of a standardized language and a set of formats expressed in XML, JSON, and YAML. These three languages allow for robust and all-encompassing usage of the language.
- Data-centric, as a way to transition from legacy systems using siloed software like Word and Excel and towards more standardized language documents.
- Extensible, which allows compliance to be managed and audited by third-party architecture and automated systems.
- Integrated, in that OSCAL includes API language that allows for standardized foundations for compliance tools.
- Automated, in a way that allows agencies and CSPs to streamline their compliance and assessments.
OSCAL has one overall purpose but accomplishes many goals along the way.
What Are the Goals of OSCAL?
OSCAL is intended to be a way to standardize the security documentation developed by contractors, 3PAOs, and agencies so everyone is on the same page when they’re communicating with one another. This makes it easier and clearer on how to identify and implement controls and how to report on assessments.
Another of the main goals of OSCAL is to facilitate the automation of continuous monitoring, auditing, reporting, and some aspects of implementation. OSCAL isn’t just human language; it’s machine-readable language, which allows automated tools and platforms to take in information in a standardized format and, vice versa, generate reports using standardized terminology. This helps enhance security by removing the burden of these tasks from human shoulders, removing human error from the equation, and freeing up person-hours to work on more complex tasks that can’t be automated.
Part of how OSCAL works is by providing a centralized standard that stems from a single authority and populates throughout various frameworks, including FedRAMP and CMMC. This allows for a deep amount of interoperability between agencies, contractors, subcontractors, 3PAOs, auditors, and more. Anyone connected to the overall government apparatus and under the purview of an agency that requires cybersecurity certification can benefit from using OSCAL because it facilitates communication in all directions.
Another significant goal of OSCAL is to provide a standardized language that, along with standardized frameworks like FedRAMP and CMMC, can ensure that varying governmental agencies and departments are all on the same page, working toward the same standards, with the same guiding light to lead them.
Finally, OSCAL is a living system. It receives continuous development and ongoing monitoring to ensure that language, standards, and data all evolve with the times. Technology advances rapidly, and the threats of just a few years ago are not the same threats as today. By centralizing language, standards can be updated across the whole of the government rather than on a department and agency level. OSCAL is also community-driven. Through use and feedback, further development is handled, and any CSP or other organization with a perspective to add can contribute to the public GitHub page.
How Does OSCAL Work?
OSCAL is divided into several layers, each of which has its own purview and use case.
The Catalog layer is the layer that lists the security controls set forth by NIST in SP 800-53 and similar documents. This is the foundational layer that describes each control and is what other layers are built on using standardized language.
The Profile layer is a step above the catalog layer. It’s the layer used by a business or agency to develop an “entity profile” out of catalog controls. You know how one of the key steps in compliance is analyzing your business from top to bottom to identify which controls apply to your business and which don’t? This is building a profile, which you can then define using OSCAL language.
The Implementation layer is where you take the documentation defined by the profile layer as it relates to your business and work on implementing those security controls. OSCAL’s standardized language allows for tools like APIs and specific software applications to streamline, automate, and facilitate this implementation. While a generic tool won’t be tailored to your profile, it will cover all of the bases of the catalog layer and can be customized for your business.
The Assessment layer is the top-level layer that sits above the rest. It’s where applications live that track and perform continuous monitoring, as well as generate reports automatically using a common language defined by OSCAL, which can then be easily read and parsed by auditing software and entities themselves.
How OSCAL Can Benefit Your Organization
OSCAL provides many potential benefits in alignment with its stated goals.
Examples of these benefits include:
- It allows you to speed up and streamline documentation by supplying a common language that can easily reference individual security controls, implementation, and status within your organization.
- It allows security implementation to be automated, including generating reporting, mapping controls to standards, and performing micro-audits to identify gaps in security.
- It facilitates enhanced risk management by providing easy, readable reports that can be generated automatically from established continuous monitoring systems as well as new analyses and implementations.
- It eases and speeds up auditing, both internally and externally, by providing automated reporting and easy analysis for most controls, leaving manual auditing to clean up and spot-check.
All of this prepares you for initial submissions and auditing to achieve compliance and an Authority to Operate or Authority to Use.
Useful OSCAL Resources
For further reading, more information, and useful guides, here are some resources you may find handy.
What is OSCAL and Who Needs It? Presentation from NIST (PDF)
FedRAMP OSCAL Resources and Templates
OSCAL GitHub Contributions Guidelines
NIST’s OSCAL Resources and Concepts Page
3rd Open Security Controls Assessment Language (OSCAL) Workshop – Max Aulakh
If you have questions that aren’t answered by on
Is OSCAL Required, and If So, For Who?
As you learn more about compliance with frameworks like FedRAMP, you might see a post like this and wonder if it’s all worth it. Yet more terms and requirements, really? Well, yes and no.
OSCAL is not actually required for any current compliance frameworks. It is not mandated, and adoption is not required for any level of cybersecurity compliance, regardless of whether it’s a low or high-impact level. If you want to go through the full compliance process without using OSCAL or OSCAL-based tools, you can do so. Plenty of contractors and CSPs still use siloed software like Excel and Word to handle their compliance, and for now, this is perfectly fine.
To draw an analogy, though, building a cybersecurity program and achieving compliance without OSCAL today is much like building a house from scratch without power tools. It’s certainly possible, but it’s slower, less efficient, more prone to potential errors, and it eschews convenience for no reason.
Truthfully, OSCAL is largely just a language framework. You’re already going to be talking about these subjects; why not make sure you’re using the right terms and recording the right information in the right way? Using OSCAL helps future-proof your assessments and implementations, it helps allow automation and streamlining, and it improves your compliance chances out the gate.
Any CSP or other entity that is seeking compliance with FedRAMP, seeking an ATO, intending to work with the government and its agencies, or otherwise needs to adhere to the security controls laid out in NIST SP 800-53 can benefit greatly from learning and using OSCAL.
Additionally, other frameworks, like GDPR, HIPAA, ISO 27001, and others, all share a lot of common language and controls, and as such, OSCAL can benefit from compliance with those frameworks as well. You’re not just limited to FedRAMP when you’re using OSCAL; it benefits virtually every cybersecurity framework in common use in the Western world today.
Using OSCAL streamlines your compliance, your documentation, your ongoing continuous monitoring, and more. There’s very little reason not to use it.
Will OSCAL Be Required in the Future?
This one is a solid “maybe.” Currently, NIST and the government have not announced plans to make OSCAL a requirement for compliance. However, like all major changes, it’s possible that it will be implemented some years down the line. For many such tools and shifts in the way compliance works, the tools and standards are released for public use years before they become required.
Early adopters get to benefit from implementing it, general industry acceptance grows as more and more 3PAOs, Auditors, and CSPs implement it on their own and extoll the virtues of using it, and eventually, only a comparative few stragglers are lagging behind in using it. That’s when making it mandatory is more likely to bring those remaining stragglers into more modern compliance and do away with less stringent requirements.
So, no, for now, you aren’t required to use OSCAL. However, you can benefit greatly from doing so, so why not try it?
Making Use of OSCAL in Modern Cybersecurity Compliance
If you’re a CSP or other business, and you want to be a contractor for a government agency, the process is generally long and arduous. You need to perform a comprehensive self-assessment, identify the security controls that apply to you, and figure out what you currently have in place and the gap between where you are and where you need to be, all before you even begin implementing security enhancements.
Once you have all of that information, you then implement security, as well as monitoring, to be able to audit and report on the status of each control. All of this is compiled into a report and audited by a certified third-party auditing organization.
This entire process takes months and has a high risk of failure simply because the chances of making a mistake with such a vastly complex system are high, but mistakes can’t be allowed to achieve compliance.
OSCAL helps at each step of this process. By providing a standardized framework, you can access tools that can speed up each step of the analysis. Implementation is usually down to you and your security posture, but then OSCAL steps in again to facilitate generating reports that speed up auditing.
On top of this, using OSCAL means you’re using a standard language, which reduces the chances of making mistakes that can jeopardize your certification.
If you’re interested in achieving compliance with FedRAMP or any other framework, and you want to make use of OSCAL and related tools to do it, you’ve come to the right place. As a certified 3PAO and a provider of high-quality software for reporting and monitoring, we can handle it all for you. All you need to do is book a demo and see how it works.
*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/compliance/what-oscal-why-matter/
