Base Value for SSP Information Types Impact Levels Required Even if Non-existent

[aj-stein-nist]

Describe the bug

Some information types in SP 800-60 Volume 2 Revision 1 do not have an explicit base in the document. OSCAL requires setting them for any information type and Metaschema constraints require a base value be defined, as indicated by documentation.

This is a summary of the conundrum.

          {
            "uuid": "5820d24a-487a-4748-8bd2-ea4318337816",
            "title": "Information sharing information",
            "description":"TBD",
            "categorizations": [
              {
                "system": "https://doi.org/10.6028/NIST.SP.800-60v2r1",
                "information-type-ids": [
                  "C.3.5.9"
                ]
              }
            ],
            "confidentiality-impact": {
              "base": "????",
              "selected": "fips-199-moderate"
            },
            "integrity-impact": {
              "base": "????",
              "selected": "fips-199-moderate"
            },
            "availability-impact": {
              "base": "????",
              "selected": "fips-199-moderate"
            }

Who is the bug affecting?

OSCAL content authors for an information system writing a system security plan.

What is affected by this bug?

Properly expressing SP800-62 Volume 2 Revision 1 information types without an explicit base value in that document, as explicitly defined.

When does this occur?

Consistently when defining an OSCAL system security plan and setting the base for an information-type and attempting to use schema validation and following documented requirements of Metaschema constraints.

How do we replicate the issue?

1. Create a SSP.
2. Define C.3.5.9 impact levels with the 800-60 Volume 2 Revision 1 system classification for a given information type.

Expected behavior (i.e. solution)

OSCAL has a documented way to define system-security-plan/system-characteristics/system-information/information-type/confidentiality-impact/base and /system-security-plan/system-characteristics/system-information/information-type/integrity-impact/base and /system-security-plan/system-characteristics/system-information/information-type/availability-impact/base where the base without an explicit base value per FIPS-199 values as defined in Special Publication 800-60 Volume 2 Revision information types that specifically do not have a base value and are contextual (such as information sharing, C.3.5.9), maybe a value like none.

Other Comments

See conversation from NIST OSCAL staff and community developers regarding a recommendation to file this issue.

[aj-stein-nist]

@david-waltermire-nist I am ok adjusting this as discussed re your Gitter feedback if you are so inclined and create an enum value of none for base. I set this to discussion needed. If you adjust accordingly and note, I will make it so. Obviously a super easy fix, so let me know which release target is all.

[aj-stein-nist]

@david-waltermire-nist since this is a bug and adding another allowed-value for this given constraint with (no allow-other attribute is defined, so maybe I am misreading this?) we can pull this into 1.0.3 maybe?