Prototype Metaschema models and mockup data samples

[aj-stein-nist]

User Story:

As an OSCAL tools developer, in order to understand the current draft work of the NIST's design for the rules assembly and surrounding model for rules, I would like to see draft Metaschema models and relevant content examples to help highlight those changes.

Goals:

• Identify relevant content sources to use as examples (i.e., openshift, CSA) Review current approaches to defining rules to confirm minimal data fields in rules-related models #1391
• Complete draft Metaschema models for rule assembly within:
  • component-definitions
  • system-security-plans
• Mocked up content examples to demonstrate the updates and drive community feedback in:
  • a component-definition
  • a system-security-plan
• Identify any gaps in the current models to address in Review current approaches to defining rules to confirm minimal data fields in rules-related models #1391.
  • consider if referencing a rule without a test in a control implementation or a statement is appropriate re Prototype Metaschema models and mockup data samples #1364 (comment)

Dependencies:

• Design a rule assembly #1339

Acceptance Criteria

• Publish examples a gists or as sources in the metaschema/examples folder.
• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

[aj-stein-nist]

I took some time to talk with @vikas-agarwal76 about the ability to to link a rule-implementation with a rule directly to a control's implemented-requirement or embedded statement without explicitly needing to bind a pre-determined test in the testing-scenario so the component owner (of a component in a component-definition) must not need to know tests in advance in all cases. Dave and I agreed to think more about this in our next modeling session.

[aj-stein-nist]

Updated MVP example for public review and discussion with the community. Concrete examples with use cases and real-world components to come. :-)

f5251a1

[aj-stein-nist]

Working through the "gaps in the current models to address" in the design document from the last iteration and will continue on that today and the next few days as we draft some examples.

[aj-stein-nist]

Dave and I will sync up on Wednesday and try to finish this off with complete(ish) model updates, touch up the current example, and potentially add more.

[aj-stein-nist]

Re "consider if referencing a rule without a test in a control implementation or a statement is appropriate," we did come up with a solution in recent updates in the feature branch.

From now on, for an implemented-requirement in at the control or its statement, you will have the ability to define one of the following in a rule-implementation:

• condition: bundle a test and rule binding fully specified, you control the full level of detail
• rule-uuid: just reference the rule and only the rule because the component-definition author/owner wants to stub out rules but does not yet know any or a specific test and/or test-rule binding.

/cc @vikas-agarwal76, we believe you had resurfaced this requirement in previous discussion, so I wanted you to know it is in now (including the draft models in this branch).

[aj-stein-nist]

I am moving this into current sprint. Forgot about it during sprint planning.

[Compton-US]

This issue was rules specific, by generally, this seems partially addressed by: usnistgov/OSCAL-Reference#19

This facilitates publishing a reference that outlines proposed changes. A few concerns remain:

• How to know exactly what has changed in the model through the reference documentation.
  (although this discussion came up as a part of the SRM prototype content)
• How to publish a set of schemas for with the proposed changes.
  (although work was done to make local generation easier through Makefiles.)
• How to publish examples in a way that is predictable for those reviewing proposed changes.
  (although work is in process to build the foundation for examples and tutorials in OSCAL)

I am going to add the question label, because we might close this issue, but open the necessary tasks to address any gaps that may exist based on what we are making an ordinary part of our process to release prototypes.

[Arminta-Jenkins-NIST]

At the 11/9 Triage Meeting: @iMichaela the rules will still be an issue. We will revisit the issue at a later date. #icebox issue