Producing PRIVACY baselines as overlays over HIGH, MODERATE and LOW

[wendellpiez]

User Story:

As captured from the full text of SP800-53B, we have four OSCAL profiles, one for each of the security impact levels HIGH, MODERATE and LOW, and also a separate profile for the controls identified for the "privacy baseline" (PRIVACY).

However, the controls selected as "privacy" controls are not intended to be managed or grouped by themselves: this selection is intended to be deployed as an overlay (supplementary control set) to any or each of the security baselines, i.e. as HIGH+PRIVACY, MODERATE+PRIVACY, LOW+PRIVACY.

These composite groupings can and should be represented as OSCAL profiles.

Goals:

1. Deploy OSCAL profiles that represent these combinations as overlays
2. Consider alternatives and refine methods for addressing use cases for 'overlays' and other combinations, at this level of complexity, of controls selected from the same or different catalogs via multiple imports.
3. (optional) Test and extend profile resolution to confirm this use case is supported

The third goal, which would include developing unit tests to reflect the import semantics, could be spun off onto a separate Issue, if it proves to be complex.

Dependencies:

If goal #3 is in scope, we should be prepared to consider edge cases in OSCAL profile import semantics, regarding chains of imports, merge behavior etc.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.

[wendellpiez]

@david-waltermire-nist and @iMichaela, I now have drafts of three OSCAL profiles written as overlays of HIGH, MODERATE and LOW respectively, each one calling in the PRIVACY controls in addition to the baseline. (Straight from the catalog, not via intermediate profile, though we could choose to do that.)

@david-waltermire-nist I need a little guidance as to where to put these - in a separate branch of my fork of this repository, but does it branch off the work already in progress? Or they could go into the branch already behind PR #32?

[joshualubell]

I'm not sure it's correct to call the privacy baseline an overlay. As far as I can tell, the primary difference between a baseline versus an overlay is that an overlay contains specialized tailoring to meet the requirements of a community of interest (such as Industrial Control System security professionals), whereas a baseline (with the exception of the SP 800-53(B) low/moderate/high baselines) is intended to meet an organization's requirements.

From an OSCAL standpoint, I see the privacy baseline as an unresolvable profile. This is because, as Wendell points out, the privacy baseline is not intended to implemented in isolation. 800-53B says that privacy control enhancements cannot be selected and implemented without the selection and implementation of the associated base control (footnote 18 on page 7), yet the privacy baseline contains control enhancements without their base controls (in instances when the base control does not directly protect against a loss of privacy). As far as I'm aware this is not generally the case with overlays. I know it's not the case with the SP 800-82 overlay.

Therefore, as an OSCAL user, I would love to see low+privacy, moderate+privacy, and high+privacy resolved profiles generated directly from the four unresolved profiles (low, moderate, high, privacy). I think the privacy baseline is terrific use case for OSCAL profile resolution where input is two (unresolved) profiles, one of which is unresolvable unless combined with the other. So please count me as an enthusiastic "yes" for Goal 3.