Mapping Schema Language for Relationships

[tsagerCIS]

OSCAL/src/metaschema/oscal_mapping-common_metaschema.xml

Line 40 in 7869eab

<enum value="equal-to">The source is equivalent in semantic meaning to the target.</enum>

@david-waltermire-nist
Something we had touched on before, the language around the relationships in mapping. Currently, in addition to the "subset/superset/equivalent" options we have here we are also using "intersects." This is the most recent addition and isn't exactly gospel yet, but is mostly used when describing similar or related policies that cannot be said to be "contained" within the other. For instance, consider policies like incident response, disaster recovery, and backup recovery. All related enough that not mapping them feels a bit wrong, but certainly not a "part" of the other. There's an argument to be made against "intersects" but that is where our thinking is at currently.

[iMichaela]

@tsagerCIS - intersect must clearly identify without any doubt the information in common vs the disjoined information. They policies you listed will intersect only if they contain identical statements but also each have other statements.

Policy1: 
-stm_a 
-stm_b
-stm_c

Policy 2:
-stm_a
-stm_d
-stm_e

The intersect of Policy1 with Policy2 will be stm_a and the rest of the statements need to be clearly marked/identified as disjoined for traceability reasons when the mapping is used for the implementations and for assessments.

In the same way one can define a union U and then allow mapping like: CatalogA:control1 be mapped as (identical-to, equivalent-to, superset-of, subset-of) to [CatalogB:control5 U CatalogB:control7] OR to [CatalogB:control5 intersect CatalogB:control7]

Thoughts?

[david-waltermire]

It seems that intersect is a way to be vague about the relation, when there is not statement level granularity to be more specific. For instance, if you have two controls that contain only a single text block as a statement.

For example:

control1:
- smt1: Text describing requirements A, B, and C.

control2
- smt2: Text describing requirements B, C, and D.

In such a case you cannot break out the statements, so expressing Control1 ∩ Control2 is a way of saying { A, B, C } ∩ { B, C, D }.

If you can mark which statement's intersect, then it would be better to use "subset/superset/equivalent" on the intersecting set members.

For example:

Given:

control1: 
-stm_1a 
-stm_1b
-stm_1c

control2:
-stm_2b
-stm_2c
-stm_2d

If Control1 ∩ Control2, this can better expressed as something like { stm_1b, stm_1c } ≡ { stm_2b, stm_2c } based on the above, assuming that the Bs and Cs are equivalent.

Is this the right way to think about the need for intersect?

[tsagerCIS]

That sounds right to me, the intent is to describe two controls that have a "venn diagram" type relationship. Neither is subsumed within the other but there is partial overlap that we can describe or quantify. A consequence of us thinking in terms of "subset/superset" that wouldn't be a concern if we instead used language like "partial."

It also catches instances where the control text will not use the same language or reference the same policy but there's still a relationship that feels "wrong" to ignore when doing the mapping. Not everyone uses the exact same language, and this is an industry where different companies aren't exactly consistent on technical verbiage either. Whenever I do a mapping I read the glossary and definitions to see if anything jumps out at me, and to make sure we mean the same thing when we say something like "mobile code."

We're definitely illustrating some of the difficulties or limitations here, even if they're not all connected to the "intersects" relationship specifically. I'm going to stick to an example of a single control with the text "written procedures and processes to identify, classify, and respond to Cyber Security Incidents." Knowing what Incident Response policy looks like, I might start by thinking of something like:

`control1:(Incident Response)

-stm_1a (network monitoring procedures)

-stm_1b (incident handling procedures)

-stm_1c (incident classification and thresholds)

-stm_1d (data backup and restoration)`

But at this point I'm already giving the control "credit" for text that may not be included in the actual framework and may or may not be intended. I "know" that restoration of normal functionality is part of incident response, but maybe others would write that policy from a more forensics perspective and leave the rest for business continuity or data backup and restoration policy.

On the other hand, it feels far too rigid to only consider statements that are directly contained within the control text. Many are only a sentence long and written to be reader friendly and not for this purpose. Many frameworks have follow-up text or supporting documents that may add pages of clarifying text calling out specific technologies or strategies that we could be using for this, but others do not.

Anyway, you can argue against "intersects" in this manner, by saying it's basically a "sorta" and this is clearly not an effort that needs more "kindas" since we have to make plenty of our own judgement calls along the way that could all add up to trouble. Another question to ask would be if the methodology was instead "none/partial/full" if we still would have mapped those two controls.

[iMichaela]

@tsagerCIS - Please note that mathematically speaking, the intersect part of the 2 controls must be identical (word by word) to qualify for an intersect relation. Otherwise it will be some level of equivalence between them and additional functionality around the information coverage (one control cover network monitoring, incident response, etc.. while the equivalent control covers logging) and information richness/entropy (one control requires monitoring or logging the other one provides requirements around which events need to be monitored) needs to be evaluated.
Please see similar discussion in #1150

[david-waltermire]

This was addressed by PR #1150.