Profile: add 'remarks' field to (modify.alter) add and remove

[openprivacy]

User Story:

As an OSCAL user, I wish to be able to provide a justification for control parts that are added or removed

Goals:

Natively (and locally) capture a justfication for a controls part change by adding a remarks field:

• profile.modify.alter.add.remarks
• profile.modify.alter.remove.remarks

Dependencies:

This is a non-breaking change, as remarks is an optional field.

Acceptance Criteria

• 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.
  • Update Adding contents to controls
  • Update Removing contents from controls
• 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]

Would add/remarks add the remarks to the resolved profile? (I think not, especially since remarks is not permitted as a child of control.)

The requirement is fair, but the remarks might better be directly inside the alter, lest it confuse the semantics of add and remove. (Are these remarks to be added or are they remarks about what/why the add is added? NB it would then be an optional feature of a profile resolver to do something with the remarks.

(If the remarks are really to be added to the baseline, that sounds like a kind of part.)

[openprivacy]

Let me start by saying that I am a novice at profile resolution.

The goal is to be able to carry through a justification for the add or remove from Profile through Assessment so that the rationale for a missing (or additional) part is available, perhaps similarly to control guidance. Does this make sense?

[iMichaela]

@openprivacy - in my view, an author of a profile is an authoritative individual that will not need to justify why is tailoring an initial imported source (catalog or another profile). This capability exists in the SSP because that is the place where a normative baseline could be tailored but the tailoring needs to be justified. The information is then carried on through the assessment.

[wendellpiez]

@openprivacy yes I think the particular use case you describe is an SSP-layer thing not a profile layer thing.

It bears worth thinking about however - do you think a single tailored baseline would commonly or typically be used for multiple SSPs (more or less the design assumption) or on the contrary, do you think every system - hence every SSP and every assessment - will have to address its own system-specific baseline? (And therefore every SSP would have its own profile.)

This is a consideration because your suggestion that the baseline should carry metadata documenting (justifying/rationalizing) itself is not crazy on the face of it, but it does raise interesting questions (about the intended consumers and uses of that information). Particularly since we think there is a principle that an SSP does not define a baseline, it can only reference one. (But in describing its implementation it is free to say whatever it needs as @iMichaela says.)

Again, in a profile this info can already be put into a part if you like. It's just that the details of the semantics (of such a part) will have to be defined between the parties to exchange (as usual).