SSP Completeness Checks: Appendix K Federal Information Processing Standard (FIPS) 199 Categorization

[brian-ruf]

This is a ...

fix - something needs to be different

This relates to ...

• the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP OSCAL Validations

User Story

As a consumer of FedRAMP automated completeness checks I want the following OSCAL-based SSP items to be automatically verified for completeness by metaschema constraints:

• Check for at least one information type in the table
• Check for 800-60 information type designation on all information type entries
• Check for typical information types (such as those related to logging. IaaS and PaaS have other system data related to the operation of the system.) (Deferred to Stage 2)
• For each information type, check that the initial CIA levels are properly reflected based on the 800-60 (Deferred to Stage 2)
• For each information type, highlight any up/downgrade of CIA relative to the initial 800-60 level
• Ensure the system impact level is the same or higher than the “high water mark” of all information types

Goals

SSP Completeness checks are defined, tested and documented

Dependencies

No response

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) 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.
• all constraints associated with the review task have been converted/created
• automate.fedramp.gov content has been updated accordingly
• the metaschema help prop has an appropriate link to the constraint
• the template has an content that models the desired OSCAL presentation
• the constraint runs against the example template
• known-bad content has been created
• the constraint appropriately flags the known-bad content as invalid

Other information

The following aligns with Stage 1 of our Constraints Strategy:

• Check for at least one information type in the table
• For each information type, check that the initial CIA levels are properly reflected based on the 800-60
• For each information type, highlight any up/downgrade of CIA relative to the initial 800-60 level
• Ensure the system impact level is the same or higher than the “high water mark” of all information types

The following aligns with Stage 2 of our Constraints Strategy and will be deferred:

• Check for typical information types (such as those related to logging. IaaS and PaaS have other system data related to the operation of the system.)
• Check for 800-60 information type designation on all information type entries

Tasks

• [ ]

[brian-ruf]

CONTEXT:

• //system-characteristics/system-information

TARGET:

• .

Data	Location	Documentation Status
800-60 Information Types [1+]	./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]

TARGET:

• ./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]

Data	Location	Documentation Status
Confidentiality Base [1+] (required)	./confidentiality-impact/base/text()
Integrity Base [1+] (required)	./integrity-impact/base/text()
Availability Base [1+] (required)	./availability-impact/base/text()
Confidentiality Selected [1+]	./confidentiality-impact/selected/text()
Integrity Selected [1+]	./integrity-impact/selected/text()
Availability Selected [1+]	./availability-impact/selected/text()
Confidentiality Justification [1+]	./confidentiality-impact/adjustment-justification/node()
Integrity Justification [1+]	./integrity-impact/adjustment-justification/node()
Availability Justification [1+]	./availability-impact/adjustment-justification/node()

[brian-ruf]

Constraints Needed:

CONTEXT: context="//system-characteristics/system-information"

TARGET: target='.'

• There must be one or more NIST SP 800-60v2 Information Types identified:
  • count(./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]) >= 1

TARGET: target='./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]'

• Selected Confidentiality Impact is required

  • count(./confidentiality-impact/selected) = 1

• Selected Integrity Impact is required

  • count(./integrity-impact/selected) = 1

• Selected Availability Impact is required

  • count(./availability-impact/selected) = 1

TARGET: target='./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]/(confidentiality-impact | integrity-impact | availability-impact)[not(./base eq ./selected)]'

• If the base value does not equal the selected value, a justification is required
  • count(./adjustment-justification) = 1

Allowed Values:

• Only 800-60v2 information types allowed (already addressed as part of PR Update 800-60 Revision 2 Volume 1 information types with names and categories #917 and issue Add more details and organization to 800-60 Revision 2 Volume 1 information type allowed-values constraint #890)

• Only fips-199-low, fips-199-moderate, or fips-199-high values are allowed for base and selected

  • TARGET: target='./information-type[./categorization[@system='https://doi.org/10.6028/NIST.SP.800-60v2r1']]/(confidentiality-impact|integrity-impact|availability-impact)/(base|selected)'
  • Use the following verbatim:
    • fips-199-low: A 'low' sensitivity level as defined in FIPS-199.
    • fips-199-moderate: A 'moderate' sensitivity level as defined in FIPS-199.
    • fips-199-high: A 'high' sensitivity level as defined in FIPS-199.

[brian-ruf]

@aj-stein-gsa & @Rene2mt - this is ready to be made into task issues