Tag Archives: OSCAL

Using OSCAL to express Canadian cybersecurity requirements as compliance-as-code

Post Syndicated from Michael Davie original https://aws.amazon.com/blogs/security/using-oscal-to-express-canadian-cybersecurity-requirements-as-compliance-as-code/

The Open Security Controls Assessment Language (OSCAL) is a project led by the National Institute of Standards and Technology (NIST) that allows security professionals to express control-related information in machine-readable formats. Expressing compliance information in this way allows security practitioners to use automated tools to support data analysis, while making it easier to address downstream requirements such as translation and accessibility. In the United States, Amazon Web Services (AWS) has collaborated closely with NIST and the FedRAMP program to advance the adoption of OSCAL, and was the first cloud service provider to submit a FedRAMP system security plan (SSP) in OSCAL format in 2022.

In Canada, the Canadian Centre for Cyber Security (CCCS) is the national technical authority for cybersecurity. CCCS publishes cybersecurity advice and guidance, including ITSG-33 Annex 3A, a catalog of security controls based on NIST Special Publication 800-53. When CCCS recently published new cloud security profiles based on NIST 800-53 Revision 5, we undertook a project to encode the relevant information in OSCAL. Expressing CCCS’s catalog and profile information in OSCAL facilitates automated analysis, including comparisons with OSCAL catalogs and profiles published by NIST and FedRAMP. This post explores the approach we took to express CCCS’s profiles in OSCAL, in addition to opportunities for future work.

OSCAL fundamentals

For the purposes of this discussion, there are two important OSCAL concepts to understand: catalogs and profiles. A catalog is a collection of security controls, such as NIST 800-53 or ITSG-33. An OSCAL catalog expresses control-specific information, including statements, parameters, and implementation guidance, in a structured and machine-readable format using either JSON, XML, or YAML.

OSCAL profiles import controls from catalogs (and other profiles) and express more specific implementation guidance. For example, the FedRAMP Moderate profile selects a subset of controls from NIST 800-53, specifies constraints for certain parameters, and provides assessment guidance. Profiles can also modify controls as they’re imported, which proved very useful for our purposes.

Expressing CCCS controls in OSCAL

Because CCCS’s ITSG-33 is based on NIST 800-53, most NIST controls can be used in CCCS profiles without modification. However, in some cases CCCS has modified the language of NIST 800-53 controls; for example, to replace mentions of a US agency or standard with a Canadian equivalent, or to add additional content specific to CCCS. Therefore, the first step in expressing CCCS requirements in OSCAL was to create a profile that makes the necessary control-level modifications. In some cases, CCCS has also created controls that are not part of NIST 800-53; these are specified in a separate catalog.

When an OSCAL profile is resolved, the information from the upstream catalogs and profiles that it’s importing controls from is assembled—along with modifications—and expressed as a catalog. By resolving the ITSG-33 modifications profile, we can programmatically generate the complete ITSG-33 catalog, incorporating NIST 800-53 controls, CCCS controls, and required modifications.

CCCS cloud security profiles

CCCS has created two profiles that are used to assess the security of cloud services: CCCS Medium and Protected B High Value Assets (PBHVA). Each of these profiles specifies a selection of controls from ITSG-33, in addition to the values for a number of parameters. Working backwards from the profiles published by CCCS as spreadsheets, we extracted the control and parameter information from each profile and expressed them in OSCAL. This exercise also informed the creation of the ITSG-33 modifications profile discussed previously, which captured control-level changes made by CCCS to NIST 800-53 controls, as well as the separate catalog of CCCS-specific controls.

Resources

In support of furthering this work within the Canadian security community, we’ve published the OSCAL files that we created as part of this project on GitHub, including:

  • CCCS-specific control catalog
  • ITSG-33 modifications profile and resolved catalog
  • CCCS Medium profile, resolved catalog, and CSV
  • PBVHA profile, resolved catalog, and CSV

We used an open-source tool, oscal-cli, to validate the structure of the OSCAL files that we created and to resolve the profiles into catalogs.

Future work

AWS is interested in further exploring the use of OSCAL to help us and our customers adhere to CCCS requirements as efficiently as possible. In the future, we want to explore how OSCAL data and tools can be used to support the efficient translation of the ITSG-33 catalog and CCCS profiles into French and the presentation of compliance information in accessible formats.

If you have feedback about this post, submit comments in the Comments section below.

Michael Davie

Michael Davie

Michael is the Canada lead for Amazon Web Services (AWS) Security Assurance. He works with customers, regulators, and AWS teams to help raise the bar on secure cloud adoption and usage. Michael has more than 20 years of experience working in the defence, intelligence, and technology sectors in Canada, and is a licensed professional engineer.

AWS announces migration plans for NIST 800-53 Revision 5

Post Syndicated from James Mueller original https://aws.amazon.com/blogs/security/aws-announces-migration-plans-for-nist-800-53-revision-5/

Amazon Web Services (AWS) is excited to begin migration plans for National Institute of Standards and Technology (NIST) 800-53 Revision 5.

The NIST 800-53 framework is a regulatory standard that defines the minimum baseline of security controls for U.S. federal information systems. In 2020, NIST released Revision 5 of the framework to improve security standards for industry partners and government agencies. The set of NIST 800-53 controls provides a foundation for additional laws and regulations within the U.S. government.

The Federal Information Security Modernization Act (FISMA) of 2014 is a law that requires federal agencies and contractors to meet information security standards. The Federal Risk and Authorization Management Program (FedRAMP) is a federal government program that provides a standardized approach to security assessment, authorization, and continuous monitoring of cloud services. Both FISMA and FedRAMP rely on the NIST 800-53 framework.

NIST 800-53 Revision 5

AWS meets the NIST 800-53 Revision 4 regulatory standards mandated by government authorities. NIST added numerous security enhancements, such as privacy and supply chain management, to Revision 5 to keep abreast of emerging threats to federal information systems.

In preparation for federal regulators to accept NIST 800-53 Revision 5 as the new requirement standard, AWS has begun efforts to adapt to the new security controls, processes, and procedures. AWS security compliance teams have analyzed the new requirements and launched a project to implement the updates. Although AWS is not required to migrate to the new Revision 5 standard until NIST announces the official regulatory compliance deadline, we are already taking steps to meet the deadline.

To learn more about AWS compliance programs, see the AWS Compliance Programs page.

 
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

James Mueller

James Mueller

James is a Security Assurance Manager for AWS. For over 20 years, he has served customers in the private, public, and non-profit sectors delivering innovative information technology solutions. He currently leads security compliance efforts to drive adoption of AWS services.

AWS achieves the first OSCAL format system security plan submission to FedRAMP

Post Syndicated from Matthew Donkin original https://aws.amazon.com/blogs/security/aws-achieves-the-first-oscal-format-system-security-plan-submission-to-fedramp/

Amazon Web Services (AWS) is the first cloud service provider to produce an Open Security Control Assessment Language (OSCAL)–formatted system security plan (SSP) for the FedRAMP Project Management Office (PMO). OSCAL is the first step in the AWS effort to automate security documentation to simplify our customers’ journey through cloud adoption and accelerate the authorization to operate (ATO) process.

AWS continues its commitment to innovation and customer obsession. Our incorporation of the OSCAL format will improve the customer experience of reviewing and assessing security documentation. It can take an estimated 4,200 workforce hours for companies to receive an ATO, with much of the effort due to manual review and transcription of documentation. Automating this process through a machine-translatable language gives our customers the ability to ingest security documentation into a governance, risk management, and compliance (GRC) tool to automate much of this time-consuming task. AWS worked with an AWS Partner, to ingest the AWS SSP through their tool, Xacta.

This is a first step in several initiatives AWS has planned to automate the security assurance process across multiple compliance frameworks. We continue to look for ways to earn trust with our customers, and over the next year we will continue to release new solutions that customers can use to rapidly deploy secure and innovative services.

“Providing the SSP packages in OSCAL is a great milestone in security automation marking the beginning of a new era in cybersecurity. We appreciate the leadership in this area and look forward to working with all cyber professionals, in particular with the visionary cloud service providers, to help deliver secure innovation faster to the people they serve.”

– Dr. Michaela Iorga, OSCAL Strategic Outreach Director, NIST

To learn more about OSCAL, visit the NIST OSCAL website. To learn more about FedRAMP’s plans for OSCAL, visit the FedRAMP Blog.

To learn what other public sector customers are doing on AWS, see our Government, Education, and Nonprofits case studies and customer success stories. Stay tuned for future updates on our Services in Scope by Compliance Program page. Let us know how this post will help your mission by reaching out to your AWS account team. Lastly, if you have feedback about this blog post, let us know in the Comments section.

Want more AWS Security news? Follow us on Twitter.

Matthew Donkin

Matthew Donkin

Matthew Donkin, AWS Security Compliance Lead, provides direction and guidance for security documentation automation, physical security compliance, and assists customers in navigating compliance in the cloud. He is leading the development of the industries’ first open security controls assessment language (OSCAL) artifacts for adoption of a faster and more reliable way to process resource intensive documentation within the authorization process.