-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Producing PRIVACY baselines as overlays over HIGH, MODERATE and LOW #35
Comments
@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? |
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. |
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:
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
The text was updated successfully, but these errors were encountered: