Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilize OSCAL "metaschema" for parsing OSCAL #18

Open
ronaldtse opened this issue Jul 26, 2023 · 12 comments
Open

Utilize OSCAL "metaschema" for parsing OSCAL #18

ronaldtse opened this issue Jul 26, 2023 · 12 comments
Assignees
Labels
enhancement New feature or request

Comments

@ronaldtse
Copy link
Contributor

ronaldtse commented Jul 26, 2023

NIST OSCAL is a cybersecurity-artifact data specification language that provides a set of data schemas used.

The OSCAL data structures are versioned according to a "metaschema XML". This metaschema XML further defines the data structure across the JSON, YAML and XML implementation formats. i.e. the "Metaschema" is defined in XML, and this "Metaschema" dictates how the resulting "OSCAL JSON", "OSCAL YAML", and "OSCAL XML" data schema looks like.

These are the particulars about the OSCAL Metaschema:

  • The metaschema is versioned, e.g. 1.0, 1.0.1, 1.0.4.
  • The metaschema changes
  • There are multiple metaschemas for OSCAL (Catalog, Assessment Plan, etc)

We need to generate the (Ruby) object accessors in the "oscal" gem, because:

  • Currently, the Ruby "oscal" gem implements only the "OSCAL Catalog" data schema at a particular version (one of the data schemas provided by the Metaschema). Once we have this, it means that we can support 1.0, 1.0.1, 1.0.4 etc versions in the same gem.

  • Allows us to use one implementation across all Metaschema versions. Users need to parse/build not only the latest version, but also older versions.

  • Allows the "oscal" Ruby gem to parse and build all the data schema objects across JSON, YAML and XML.

The relevant input to this task are:

The approach is:

  • Use the lutaml-model gem to parse the OSCAL Metaschema XML.
  • For each data schema and each schema version, through meta-programming, develop a set of classes based on lutaml-model. For example, a round-trip for Catalog version 1.0.4 is possible through Oscal::Catalog::Version104.parse(catalog_xml).to_xml.

We will need to reimplement the internals of the current gem because we need to generate the classes depending on the metaschema XML.

Let's first do the Catalog metaschema (with multiple metaschema versions):

The other metaschemas can be found at:

@ronaldtse
Copy link
Contributor Author

Maybe we can bridge this using the Shale gem? @HassanAkbar

@HassanAkbar
Copy link
Member

@ronaldtse Sure, will look into it after finalizing stepmod-utils issues.

@RS-Credentive
Copy link
Contributor

Hey, I am working on this with a couple of others (for python) here: https://github.com/Credentive-Sec/metaschema-python

I have some design notes and there are weekly calls with the metaschema team to talk about the challenges and discuss ideas. Let me know if you're interested in joining. The more the merrier!

@ronaldtse
Copy link
Contributor Author

Instead of the Shale gem we are looking at our own lutaml-model gem which has superseded Shale.

@ronaldtse
Copy link
Contributor Author

This task is now active. We will first move this to the https://github.com/lutaml/ org to continue.

@ronaldtse
Copy link
Contributor Author

This task is now handled by @hasaniskandar

@RS-Credentive
Copy link
Contributor

The 'metaschema-python' library is now the 'metaschema-codegen' library, expressly for the purpose of supporting multiple programming languages as output. Very happy to have a chat with you all anytime to talk about where it is and how to make it produce ruby libraries as an output.

@ronaldtse
Copy link
Contributor Author

Thanks @RS-Credentive for the tip! We'd be more than happy to contribute to the metaschema-codegen after we complete implementation.

Our goal here is to handle all versions of the OSCAL metaschemas using the same Ruby library, since we're trying to help our users on the other side (Metanorma) to handle OSCAL as simply as possible.

The other goal we have is to improve our schema handling library (lutaml-model), so it's just a process we need to work through.

@RS-Credentive
Copy link
Contributor

I'm happy to share any tips or information that I have gleaned, so feel free to ping me. I highly recommend joining the once a week metaschema calls on Friday at 1 PM Eastern. If your team would like to participate, I can forward the invitation or put you in touch with the organizers. It's hosted by the ex NIST/OSCAL now GSA/Fedramp team that is writing metaschema.

@ronaldtse
Copy link
Contributor Author

ronaldtse commented Oct 17, 2024

@RS-Credentive Happy to join the call for this week! My email is [email protected] if you don't mind communicating the details separately. P.S. Is Michaela etc now with the new team?

@RS-Credentive
Copy link
Contributor

Michaela is still manning the ship at NIST. Dave and AJ are building a team at FedRAMP.

@ronaldtse
Copy link
Contributor Author

Thank you @RS-Credentive !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants