Control Mapping: Support for additional context when defining equivalencies in sets.

[Compton-US]

User Story:

As an OSCAL implementer, I would like to specifically describe a control equivalency when requirements of a control may not be completely compatible. This support would allow me to constrain a source control that is more broadly interpreted than the target control.

"Meets or exceeds" is a commonly used phrase when describing the degree of conformance, and we already have operators that address equal-to and equivalent-to. Based on discussion, when an equivalent-to relationship between two controls is described, there will be situations where the relationship needs context to specifically describe how the equivalence is achieved. Additionally, there may be situations where this equivalency can be assured only in one direction, unless the how is precisely defined in a way that automation can interpret the intention of the author.

Goals:

The goal is to allow a human-centered, potentially subjective, statement of equivalency that can be interpreted reliably by automation. Discussion has been around the greater-than > and less-than < style set operators, where one control has a greater constraint than another. Terms that seem to most accurately capture the comparisons could be:

• exceeds - The source control, statement and/or requirement is more constrained than the target requirement. The requirement in the target will be met, but the comparison is not completely (or mathematically) equivalent.

• precludes - The source control, statement and/or requirement prevents equivalency in the target, or is deficient in some manner. The requirement in the target may not be met without constraints in the source. Some combinations may never be allowed.

Above is just to provoke discussion, and the exact terms still need consideration and definition.

Use Cases

Example 1:

An information system to be used by government, where the solution is also used in another sector where constraints are more strictly defined by an organization.

• Organization: Requires TLS [Catalog_B:Control_2]
• Organization: Requires when TLS is used, must be v1.3 [Catalog_B:Control_4:Stmt_2]
• FedRAMP: Requires TLS no less than v1.2. [Catalog_A:Control_1]

Example 2:

A health IT vendor has a profile to address HIPAA requirements for a SaaS solution. The HIPAA controls are typically very broad, and less opinionated regarding technical implementation details. The vendor is planning to license the solution to federal government and wishes to map the HIPAA profile to a FedRAMP moderate profile.

• HIPAA: Requires Encryption in Transit [Catalog_B:Control_2]
  • May Use TLS 1.0 [Catalog_B:Control_2:Stmt_3]
  • May Use TLS 1.1 [Catalog_B:Control_2:Stmt_4]
  • May Use TLS 1.2 [Catalog_B:Control_2:Stmt_5]
• FedRAMP: Requires TLS no less than v1.2 [Catalog_A:Control_1]

or another potential variation (one statement, many options):

• HIPAA: Requires Encryption in Transit [Catalog_B:Control_2]
  • May Use TLS 1.0 [Catalog_B:Control_2:Stmt_3]
  • or TLS 1.1 [Catalog_B:Control_2:Stmt_3]
  • or TLS 1.2 [Catalog_B:Control_2:Stmt_3]
• FedRAMP: Requires TLS no less than v1.2 [Catalog_A:Control_1]

Additional Discussion References:

• Mapping Schema Language for Relationships #1221
• Support for control mapping #1150
• Support for "Rules" in OSCAL Models #1058
• Support for control mapping #1150 (comment)
• Add Linking from Objectives to Statements for the 800-53 Catalog oscal-content#123

Dependencies:

This is related to the OSCAL control mapping development work that is underway.

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.

[david-waltermire]

This makes sense. To move forward we need concrete examples, using the OSCAL mapping model, that illustrate the use of these new relationships. These will be helpful in driving additional discussion around refining this proposal.

@Compton-NIST Can you convert the scenarios above into concrete examples?

[Compton-US]

For those that are curious, I will share "real time" progress on research in this gist:
https://gist.github.com/Compton-NIST/e76412d372b4e9608ae010aad243c9ae#file-mapping-md

Findings and concerns will filter over into this ticket as determined.

[Compton-US]

Part of the discussion to take place in the model review.
Handout - OSCAL Model Review 2022-10-14.pdf

[Compton-US]

These are the slides from the mapping exercise:
Mapping Exercise - OSCAL Model Review 2022-10-14.pdf

[aj-stein-nist]

Chris is away and so we will need to move this to Sprint 63 and @Compton-NIST and I can sync up later about whether this is still doable for completion in Sprint 63 (February).

[Compton-US]

This is being worked as a part of DEFINE:

• Research Effort: Determine changes and revisions required in the development mapping model. OSCAL-DEFINE#18
• Discovery: Controls and Mapping OSCAL-DEFINE#14

Keeping open pending outcome.