Optional security-sensitivity-level

[RS-Credentive]

User Story

As an OSCAL implementer, I need to be able to address different compliance regimes. These regimes will define security-sensitivity-level differently and often will not use FIPS 199 as a baseline. In some cases, the sensitivity level is deterministically related to the related control profile, so specifying both a profile and sensitivity level is unnecessary. The sensitivity level will automatically determine the profile, and the chosen profile implies the sensitivity level.

For example, a CA under the FPKI common policy will determine which certificate types and profiles should be issued, and the set of controls that apply to that CA are completely determined by the chosen certificate types. In this case, it is unnecessary and irrelevant to identify a security-sensitivity-level. Furthermore, if the individual or team completing the SSP chooses the wrong combination of security-sensitivity-level and profile, this is an error condition, and the SSP should be rejected as invalid.

Goals

Security-sensitivity-level and security-impact-level should be optional attributes.

Dependencies

No response

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.
• 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.
• An SSP without any security-sensitivity-level or security-impact-level defined should be processed as valid with NIST tooling
• The schemas describing the SSP model should not mandate the presence of these attributes.

Revisions

No response

[aj-stein-nist]

We have to consider short-term accommodation and long-term approach for supporting community needs.

• In the short-term, we can:
  • confirm we to intend to support non-RMF (SP 800-37) properties
  • consider relaxing the schema for the security sensitivity level based on this short-term confirmation
• In the long-term, we may need to:
  • document our long-term design principles, present and future
  • leverage the documented design principles for future cases similar to this

We are comfortable reviewing this for possible inclusion in upcoming sprints and not deferring this work. More to follow.

[iMichaela]

This issue (short-term approach) also addresses concerns raised by European OSCAL users as well. I worked today with @Arminta-Jenkins-NIST and show where to make the changes (against the develop branch). She needs to push the commit and submit the PR later today or tomorrow.

[iMichaela]

@aj-stein-nist How do you want to document the long-term design principles in support of non-(NIST/FedRAMPP) processes and procedures?