Support for "Rules" in OSCAL Models

[aj-stein-nist]

User Story:

As an OSCAL tool developer, in order to ensure my software can document testing requirements that an information system must implement as one part of cumulative control implementation requirements, I would like enhancement to the OSCAL models to more explicitly define the concept of a rule as a first-class citizen. Modifications and new additions to OSCAL to tool developers to build software for users to give specific criteria to test for a specific kind of implementation implied by control requirements, and have such criteria expressed in OSCAL.

Goals:

• Define notional use cases for the rule, operationally, then in terms of OSCAL mechanics
• Design supporting structure and insertion points for TBD rule assembly
• Design a rule assembly #1339
• Review current approaches to defining rules to confirm minimal data fields in rules-related models #1391
• Prototype Metaschema models and mockup data samples #1364
• Finalize the rule design (in the story above)
• Update the framing document content into Contents page and other relevant pages as needed
• Analyze use cases and determine where rule assembly should and should not be used in relevant OSCAL models
• Obtain NIST team and community buy-in for design that supports continuum of automated to manual rules

Dependencies:

N/A

Acceptance Criteria

• 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]

While reviewing the backlog today, #821 seems related, but specifically focused on component-definitions. This story work is very similarly aligned, but perhaps greater in scope. User feedback this week indicates it might not be ideal to have such checks only or exclusive in a component, but more modeling work is needed to determine that.

[aj-stein-nist]

First things we ought to tackle:

• How do rules fit into each of the OSCAL models conceptually? (Does the concept of "rules" make sense in a catalog's model and document instance, for example? It seemingly makes sense at first glance in component or system-security-plan, right? Analyze this for each and every model.)
• How we will we connect/reference to the check for the rule (from Rule Checks in OSCAL Models #1059)?
• For third parties, how do we allow them to include checks for a model document instance? They might not "own" the document instance of a model (e.g. a SSP, a component) as its original author? They have to shim it in even if they are not the original author(s).

[aj-stein-nist]

Discussed more with Dave today. Will begin by sketching out the "do rules fit into each of the OSCAL models conceptually?" question as well as gathering consensus on what the the relevant data elements are.

[aj-stein-nist]

@david-waltermire-nist, I know we will have another backlog refinement in the near future, but you had asked if I am ready to pull this one into Sprint 49 if you and team are ready.

[aj-stein-nist]

Notes from our last touch-base with interest community members.

My current action item: build information model outline with recommended changes to include the concepts of rules.

[aj-stein-nist]

NOTE: This draft is obsolete, please see the updated draft spec below.

Proposed Information Model for rule

Moving forward, we might suppose a rule can look like this:

• rule [0 to ∞]
  • uuid [1]
  • title [1]
  • description [1]
  • origin [0 to ∞]
  • subject [0 to ∞]
  • props [0 to ∞]
  • link [0 to 1]
    • href
    • rel:
      • satisfies-partially
      • satisfies-completely
      • recommended-with
      • required-with
      • conflicts-with

A rule will be a summary explanation of mechanisms to evaluate and/or test amount of security and/or privacy information in OSCAL, including linkages to relevant controls. I specifically do not call out where rules should be inside a document instance of an OSCAL model yet because that is a separate discussed below.

Because a rule is an explicit mechanism to test or evaluate if a system satisfies a given statement, there are some obvious parts of the information model.

• uuid: uniquely identify the rule in its embedded OSCAL model document instance
• title: a summary title for the rule in question
• description: the brief explanation of the test
• origin: where the rule information originated from, be it a person or an automated assessment tool. We expect there are fully automated, semi-automated, and manual evaluation methods. origin, as it is used now in the assessment-results model
• subject: the subject of assessment, be it a person, process, or system component (service, server, et cetera)
• props: One or more properties with variables and their values to be mapped as inputs to a tool, if the origin is an automated assessment tool.
• link: this linkage is intended to function in two ways: 1) by way of specific @rel values (satisfies-partially; satisfies-completely) denotes if it partially or completely satisfies requirements elsewhere in a OSCAL document instance (e.g. the statement of an implemented-requirement of a control); 2) denotes it's relation to other adjacent rules by way of specific @rel values for the link (recommended-with; required-with; conflicts-with). This can be used in combination to allow specific rules to be annotated in a way for sufficient aggregation of what OSCAL document instance data they satisfy.

[david-waltermire]

A few questions:

• Given the above, if multiple rules are used to "satisfies-partially", how do you define the set of rules that "satisfies-completely"?
• How would you point to the rule or check implementation?

[aj-stein-nist]

A few questions:

* Given the above, if multiple rules are used to "satisfies-partially", how do you define the set of rules that "satisfies-completely"?

I think it will be up operator expertise, unfortunately. I was thinking about this a lot yesterday, and I have no good ideas on how we can determine that without some really complex semantics not in place yet.

But back to the actual question, you could use link/@href to point the implemented-requirement/statement (in the case of a component-definition for example) with a link/@rel bound to satisfies-completely and then set additional link/@hrefs for with the UUID fragements pointing to others independent rules that support that same implemented-requirement/statement and the link/@rel would be set to required-with. I know this leans heavily on link but I didn't know if we wanted new constructs here and additional complexity.

* How would you point to the rule or check implementation?

I think I need to flesh out an example, but that would be the origin construct. Is this a good reuse of such a construct or a bad one?

[iMichaela]

@aj-stein-nist and @david-waltermire-nist Would a numeric value associated with the rel for the satisfaction (aka percentage or score) make sense? In this way, an additive operation can be applied to identify the cumulative effect of partial satisfaction and aggregation towards satisfies-completely. The numeric values would be inputs from authoritative entities that can be identified through their ID, since it would be nice to know who decided this test satisfies 30% and not 80%
Also, a field that would indicate this rule is part of a superset of rules what is the uuid of that superset might be nice.

[aj-stein-nist]

@aj-stein-nist and @david-waltermire-nist Would a numeric value associated with the rel for the satisfaction (aka percentage or score) make sense?

Personally, I think it would be hard to measure and quantify, your question makes me believe maybe the satisfies- rel attributes need more thought. I meant it be qualitative and intended for expert human insight, but as I write this I realize that also might be too bold.

In this way, an additive operation can be applied to identify the cumulative effect of partial satisfaction and aggregation towards satisfies-completely.

I like the idea in principle but I have no idea how we could implement this in practice. Do you have any ideas around this? I too will reflect on it.

The numeric values would be inputs from authoritative entities that can be identified through their ID, since it would be nice to know who decided this test satisfies 30% and not 80% Also, a field that would indicate this rule is part of a superset of rules what is the uuid of that superset might be nice.

My intent with link/@rel="required-with" or link/@rel="recommended-with" was to allow for that through a tagging approach. In most instances, I find this more flexible. Are there downsides to this approach?