OSCAL mapping model support for identifying controls in a catalog that are not mapped

[iMichaela]

User Story:

As an OSCAL user, when I map a source catalog to a target catalog, I would like to also document, in the mapping instance of the source catalog, the controls or control parts/statements for which the target catalog does not have mappable control or part.

Also, in order to successfuly reverse the source->target relationships documented in a mapped catalog, so I can infer any implementation or assessment information relative to the target catalog into the source catalog, I would like to be able to, at minimum, list the unmapped target controls in the mapping instance.

Goals:

@vikas-agarwal76 requested this feature in #1150: I believe a 5th relationship that may be good to capture would be "None" or "Null". This is to explicitly capture cases where no mapping (not even partial) exists for a source control in the target catalog. In this case the target controls will be empty. This will help distinguish cases where no mapping has been specified till now versus no mapping exists at all. One may want to explicitly state that fact for completeness to avoid any ambiguity.

Since "None" or "Null" is not a mapping relation, will not have a target, an alternative way of capturing this information such as a different construction that would follow the existing mappings to define unmapped elements (i.e., controls, or control statements).

Dependencies:

Acceptance Criteria

• The solution is aligned with the draft Control Mapping Support for control mapping #1150
• 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.

[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.