Discovery: Controls and Mapping

[Compton-US]

This is a research effort that is currently in progress.

This effort is currently under review for initiation here: #18

Spiral 1 has been started.

• Spiral 1: Consolidate all issues and research into single spiral. #22

[Compton-US]

Feedback from Gitter with a different perspective relative to mapping and comparisons:

• Different meanings of "mapping" -> Thread

  • You keep using that word "mapping", I do not think it means what you think I think it means. :)
  • You use it, correctly, to mean comparing two distinct policy frameworks to identify overlap or equivalence.
  • I use it, also correctly (in the context of my community), to mean comparing two instances of a policy under a framework to determine whether the policies are expressed in an equivalent or comparable way.

• You guys have the terms "equal-to", "superset-of", and "subset-of". Whereas I use the following terms:

  • Comparable: Two policy statement express essentially the same requirement.
  • Acceptable: Two policy statements express different requirements, but from a security perspective, they are both okay. The differences are not material. <Very subjective!>
  • Disparate: Two policy statements express different requirements, and one of them is deficient as stated, when compared with the other.
  • Unknown: Two policy statements are expressed differently, and one of them is missing a key detail. We therefore cannot determine whether or not the second policy statement is comparable to the first.

• The difference between "Disparate" and "Unknown":

  • When a policy is very clearly written, and it is obviously different, it is disparate. If details are missing and I can't even make a determination, it is unknown.

• So why should you care?

  • Maybe you shouldn't, but my community (FPKI) cares a lot about this.
  • Is there any part of the OSCAL standard that supports this kind of activity? I don't think I can use the mapping facility because it's really intended for the other meaning of "mapping"

Gitter Discussion Thread

[degenaro]

Perhaps mapping can be made more flexible by allowing the required relationship token be from a locally defined set of valid values. For example, in addition to maps[1] there could be relationships[0 or 1] that comprise the set of valid relationships that override the presumed set?

[iMichaela]

You guys have the terms "equal-to", "superset-of", and "subset-of". Whereas I use the following terms:

• Comparable: Two policy statements express essentially the same requirement.
• Acceptable: Two policy statements express different requirements, but from a security perspective, they are both okay. The differences are not material. <Very subjective!>
• Disparate: Two policy statements express different requirements, and one of them is deficient as stated when compared with the other.
• Unknown: Two policy statements are expressed differently, and one of them is missing a key detail. We therefore cannot determine whether or not the second policy statement is comparable to the first.

I do not see how the comparable, acceptable, and unknown can be used by an automation process to determine semantical differences or similarities in a way that allows for:

• the relationship to be traversed in both directions
• the use of the relation in an SSP and during the assessment to determine the tests that will support one assessment with multiple reports.

When we use the relationships defined, and have
A1= ' Implement TLS`
B1= 'Implement TLS 1.2 or above'
the relationship is A1 is a subset of B1 because the requiremetns are decomposed into required elements of the set:

A1 = set a = (TLS) <- one element
B1 = set b = ( TLS, 1.2, 1.3) <- 3 elements

A1 subset-of B1
OR
B1 superset-of A1

To assess A1 the assessor needs one test to demonstrate TLS is implemented
To assess B1 the assessor needs 3 test: is TLS implemented?, is it v 1.2? is it v 1.3?

Rob - Do you mind providing an example of 2 small sets of controls or policy requirements and their mapping, and the mapping use in the context of the implementation of the policy requirements and the relationship use in the assessment of the source set of the requirements to project the findings into the target set.

[Compton-US]

The general outline of the qualifier tag can be viewed in this issue.

The general outline of the provenance tag can be viewed in this issue.

For both of these, I produced the rough outline, and we are looking for input/feedback around the terms used, as well as the allowed values. Feedback can be added in the discussion by commenting below.

Also, thoughts around what is required and the cardinalities are welcome. This has not been considered yet.

---

Places to find the code:

Draft Mapping Model

Existing draft (previously in the develop branch)
https://github.com/usnistgov/OSCAL/tree/feature-mapping

Staging for all proposed changes (no merges yet, but coming soon)
https://github.com/usnistgov/OSCAL/tree/prototype-mapping-model

Specific Tags (Work in Progress)
https://github.com/usnistgov/OSCAL/tree/compton-working-provenance
https://github.com/usnistgov/OSCAL/tree/compton-working-qualifier

[Compton-US]

We've started publishing the draft documentation for prototype models. The documentation for mapping can be found here:

https://pages.nist.gov/OSCAL-Reference/models/prototype-mapping-model/

Specific locations:

• Provenance: https://pages.nist.gov/OSCAL-Reference/models/prototype-mapping-model/mapping/json-reference/#/mapping-collection/provenance
• Qualifier: https://pages.nist.gov/OSCAL-Reference/models/prototype-mapping-model/mapping/json-reference/#/mapping-collection/mappings/mapping/maps/qualifiers

Please note that element names and allowed values, and constraints are very conceptual and still need definition. Cardinalities and constraints are also not defined at the moment. Input is welcome.

[degenaro]

1. provenance should be for each mapping (inside mappings) rather than at top level. As per its description - “Describes requirements, incompatibilities and gaps that are identified between a target and source in a mapping item.” Hence it is for each target and source pair i.e, mapping.
2. Should the source-resource and target-resource type also support profiles? Currently only catalog can be set as type. We can always resolve a profile to a catalog, but explicitly allowing profile would be a good way to convey whether it is an original catalog or a profile.
3. There should be a way of explicitly capturing unmapped controls from source-resource to specify that no mapping exists for these controls (to distinguish from the case where the mapping is still in progress or incomplete). This is not included in the schema.

[Compton-US]

Thanks for this! On #1, that is a copy-paste error. Provenance description property should describe the context and intended use of the mapping so that it is clear to the user of the mapping document. It is intended to be used for the mapping as a whole. We need to correct that. The qualifier assembly description property has the correct description. I hear your point on #2, and we'll look at that. On #3, we do have an issue for creating an assembly to specify unmapped controls. It does need to be implemented in the prototype.

[degenaro]

mapping-collection.json

Here is a sample mapping for XYZ set of controls to NIST 800-53 rev4, using the previous develop version of OSCAL. Notice that we've used properties to capture mapping percentages and relationships (controls, procedures, rules). Perhaps there's a better way of doing that?

[Compton-US]

Summary of Issues

• Spiral: Determine approach to documenting in the SSP and Component Definition a mapped control or statement. #32 (ssp referencing)
• Spiral: Determine approach to mapping with context of evidence #30 (evidence)
• Spiral: Determine approach for unmapped items in a mapping. #29 (unmapped)
• Spiral: Change Request creation for a provenance assembly in mapping. #28 (provenance)
• Spiral: Change Request creation for a qualifier assembly/tag in mapping. #27 (qualifier)
• Research Effort: Determine changes and revisions required in the development mapping model. #18 (primary)

Reference Links

• Reference Prototype: https://pages.nist.gov/OSCAL-Reference/models/prototype-mapping-model/
• Working Branch: https://github.com/usnistgov/OSCAL/tree/prototype-mapping-model
• Previous Development Model: https://github.com/usnistgov/OSCAL/tree/feature-mapping
• Spiral Documents: https://github.com/usnistgov/OSCAL-DEFINE/tree/main/research-2023/effort-mapping-model

Note: The prototype builds on the previous development model.