Possible Issue with Data Center input in OSCAL SSP Validation

This relates to ...

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

What happened?

Here’s a polished and professional version:

I am currently working on implementing data centers in the OSCAL SSP as outlined in the All Valid FedRAMP SSP guide. Following the structure specified in the guide, I have structured the data centers within the SSP JSON file as follows:

According to the ssp-all-VALID.xml file, data centers should be nested in the following structure: system-security-plan > metadata > locations > props

The equivalent XML example in the guide looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0"
                      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                      xsi:schemaLocation="http://csrc.nist.gov/ns/oscal/1.0 https://github.com/usnistgov/OSCAL/releases/download/v1.1.2/oscal_ssp_schema.xsd"
                      uuid="12345678-1234-4321-8765-123456789012">
  <metadata>
    <title>Enhanced Example System Security Plan</title>
    <published>2024-08-01T14:30:00Z</published>
    <last-modified>2024-08-01T14:30:00Z</last-modified>
    <version>1.1</version>
    <oscal-version>1.1.2</oscal-version>
    <document-id scheme="https://example.com/identifiers">SSP-2024-002</document-id>
    <prop name="fedramp-version" ns="https://fedramp.gov/ns/oscal" value="fedramp-3.0.0rc1-oscal-1.1.2"/>

    <location uuid="11111112-0000-4000-9001-000000000009">
      <address>
        <country>US</country>
      </address>
      <prop name="type" value="data-center" class="primary"/>
    </location>
    <location uuid="11111112-0000-4000-9000-000000000003">
      <address>
        <country>US</country>
      </address>
      <prop name="type" value="data-center" class="alternate"/>
    </location>

I translated the 'locations' structure to JSON as follows:

"locations": [
  {
    "uuid": "11111112-0000-4000-9001-000000000009",
    "address": {
      "country": "US"
    },
    "props": [
      {
        "name": "type",
        "value": "data-center",
        "class": "primary"
      }
    ]
  },
  {
    "uuid": "11111112-0000-4000-9000-000000000003",
    "address": {
      "country": "US"
    },
    "props": [
      {
        "name": "type",
        "value": "data-center",
        "class": "alternate"
      }
    ]
  }
]

To ensure alignment with our system’s requirements, I expanded upon this example and included additional fields in each data center entry, resulting in the following JSON structure (below is dummy data that I am testing before actual content implementation):

"locations": [
  {
    "uuid": "90a7f3a9-0000-0000-0000-0d2137c4d05f",
    "title": "Primary Data Center 1",
    "address": {
      "city": "New York",
      "state": "NY",
      "country": "US"
    },
    "props": [
      {
        "name": "type",
        "value": "data-center",
        "class": "primary"
      }
    ],
    "remarks": "This is the primary data center for Example System."
  },
  {
    "uuid": "eced0000-0000-0000-0000-000011a4d057",
    "title": "Primary Data Center 2",
    "address": {
      "city": "Los Angeles",
      "state": "CA",
      "country": "US"
    },
    "props": [
      {
        "name": "type",
        "value": "data-center",
        "class": "primary"
      }
    ],
    "remarks": "This is the first alternate data center for backup and disaster recovery."
  },
  {
    "uuid": "0000f0000-9ac9-0000-9051-0000c9d10000",
    "title": "Alternate Data Center 2",
    "address": {
      "city": "Chicago",
      "state": "IL",
      "country": "US"
    },
    "props": [
      {
        "name": "type",
        "value": "data-center",
        "class": "alternate"
      }
    ],
    "remarks": "This is the second alternate data center for redundancy and load balancing."
  }
]

However, upon validation, I received the errors shown in the Relevant Log Output

These errors suggest that the validation process may not be recognizing the data centers properly within the locations structure as shown in the ssp-all-VALID.xml file. It’s unclear if this is an issue on my end or if there’s a misalignment in the validator’s expectations regarding the location of data center definitions.

Any guidance on ensuring the validator recognizes these data centers appropriately or on addressing these specific error messages would be greatly appreciated. Thank you in advance for your assistance.

Relevant log output

* [ERROR] [/system-security-plan/metadata[1]] There must be at least two (2) data centers listed.
* [ERROR] [/system-security-plan/metadata[1]] There must be a single primary data center.
* [ERROR] [/system-security-plan/metadata[1]] There must be one or more alternate data center(s).

How do we replicate this issue?

Insert Data Centers as shown in: All Valid FedRAMP SSP guide

Use constraints files:

fedramp-external-constraints.xml
fedramp-external-allowed-values.xml

Where, exactly?

This is for OSCAL in JSON Format. OSCAL CLI Version: 2.2.0

Other relevant details

Just Verified in the Sarif Output and it does look for it in the Metadata instead of locations.

Hi @JoseGHdz, thanks for the report.

I will still have a few more questions to help determine your issue.

How are you obtaining the fedramp-external-constraints.xml and fedramp-external-allowed-values.xml, Docker or directly via GItHub? I need to know the exacts version of the file to know if you used a version with a bug fixed sometime in the last week.
What is the exact command you ran?
In the JSON variant we just see "locations": {}, can you show more context of the SSP? If not, can you please confirm locations are inside of metadata? I was confused by this concluding comment in the bug report.

Just Verified in the Sarif Output and it does look for it in the Metadata instead of locations.

The model does not have locations at "the same level" as metadata, but inside of it, like so.


{
  "system-security-plan": {
     "metadata": {
         "locations": [
            ...
         ]
      }
   }
}

For @JoseGHdz I will mark this as blocked (for submitter feedback) until we can work on it more.

Hi @JoseGHdz, thanks for the report.

I will still have a few more questions to help determine your issue.

How are you obtaining the fedramp-external-constraints.xml and fedramp-external-allowed-values.xml, Docker or directly via GItHub? I need to know the exacts version of the file to know if you used a version with a bug fixed sometime in the last week.

What is the exact command you ran?

In the JSON variant we just see "locations": {}, can you show more context of the SSP? If not, can you please confirm locations are inside of metadata? I was confused by this concluding comment in the bug report.

Just Verified in the Sarif Output and it does look for it in the Metadata instead of locations.

The model does not have locations at "the same level" as metadata, but inside of it, like so.
{
  "system-security-plan": {
     "metadata": {
         "locations": [
            ...
         ]
      }
   }
}

Hey AJ,

I obtained the constraint files from Github since I am currently using the manual version of the OSCAL CLI.
The command that I ran is oscal-cli validate /Users/josehernandez/Desktop/oscal_ssp.json -c /Users/josehernandez/Desktop/fedramp-external-constraints.xml -c /Users/josehernandez/Desktop/fedramp-external-allowed-values.xml -o ssp-validation-results.sarif --sarif-include-pass

For the third item. Location is encapsulated under Metadata. What I meant with the serif file is that the validator looks for Data Center items inside of Metadata but outside of locations which is under the metadata.

{
  "system-security-plan": {
    "uuid": "00002900-0000-0000-0000-572a00000000",
    "metadata": {
      "title": "FedRAMP System Security Plan",
      "published": "2024-11-04T00:00:00Z",
      "last-modified": "2024-11-04T00:00:00Z",
      "version": "fedramp2.2.0-oscal1.1.2",
      "oscal-version": "1.1.2",
      "locations": [
        {
          "uuid": "90a7f3a9-0000-0000-0000-0d2137c4d05f",
          "title": "Primary Data Center 1",
          "address": {
            "city": "New York",
            "state": "NY",
            "country": "US"
          },
          "props": [
            {
              "name": "type",
              "value": "data-center",
              "class": "primary"

            }
          ],
          "remarks": "This is the primary data center for Example System."
        },
        {
          "uuid": "eced0000-0000-0000-0000-000011a4d057",
          "title": "Primary Data Center 2",
          "address": {
            "city": "Los Angeles",
            "state": "CA",
            "country": "US"
          },
          "props": [
            {
              "name": "type",
              "value": "data-center",
              "class": "primary"

            }
          ],
          "remarks": "This is the first alternate data center for backup and disaster recovery."
        },
        {
          "uuid": "0000f0000-9ac9-0000-9051-0000c9d10000",
          "title": "Alternate Data Center 2",
          "address": {
            "city": "Chicago",
            "state": "IL",
            "country": "US"
          },
          "props": [
            {
              "name": "type",
              "value": "data-center",
              "class": "alternate"

            }
          ],
          "remarks": "This is the second alternate data center for redundancy and load balancing."
        }
      ]

Again, thanks for prompt updates. We really appreciate the feedback and working with us directly on GitHub. We cannot say that enough!

I am not sure how you are downloading them directly, but did you refresh a copy of the downloaded files to validate the bug exists? If you are downloading individual files, it becomes harder to know the specific version with sitting together in an office hours session. Can you try downloading the most recent copies after you read this from this specific URL or more easily run things from Docker like so?

On Windows:

# Go to this folder with your_ssp.xml file you used to report this issue.
cd path/to/example/ssp
docker run --rm -it -v ${PWD}:/data ghcr.io/gsa/fedramp-automation/validation-tools:latest validate /data/your_ssp.xml -c /opt/fedramp/constraints/fedramp-external-allowed-values.xml -c /opt/fedramp/constraints/fedramp-external-constraints.xml -o /data/your_ssp --disable-schema-validation

On Linux or macOS:

# Go to this folder with your_ssp.xml file you used to report this issue.
cd path/to/example/ssp
docker run --rm -it -v $(pwd):/data ghcr.io/gsa/fedramp-automation/validation-tools:latest validate /data/your_ssp.xml -c /opt/fedramp/constraints/fedramp-external-allowed-values.xml -c /opt/fedramp/constraints/fedramp-external-constraints.xml -o /data/your_ssp --disable-schema-validation

Again, thanks for prompt updates. We really appreciate the feedback and working with us directly on GitHub. We cannot say that enough!

I am not sure how you are downloading them directly, but did you refresh a copy of the downloaded files to validate the bug exists? If you are downloading individual files, it becomes harder to know the specific version with sitting together in an office hours session. Can you try downloading the most recent copies after you read this from this specific URL or more easily run things from Docker like so?

On Windows:
# Go to this folder with your_ssp.xml file you used to report this issue.
cd path/to/example/ssp
docker run --rm -it -v ${PWD}:/data ghcr.io/gsa/fedramp-automation/validation-tools:latest validate /data/your_ssp.xml -c /opt/fedramp/constraints/fedramp-external-allowed-values.xml -c /opt/fedramp/constraints/fedramp-external-constraints.xml -o /data/your_ssp --disable-schema-validation
On Linux or macOS:
# Go to this folder with your_ssp.xml file you used to report this issue.
cd path/to/example/ssp
docker run --rm -it -v $(pwd):/data ghcr.io/gsa/fedramp-automation/validation-tools:latest validate /data/your_ssp.xml -c /opt/fedramp/constraints/fedramp-external-allowed-values.xml -c /opt/fedramp/constraints/fedramp-external-constraints.xml -o /data/your_ssp --disable-schema-validation

Hey AJ, I was able to resolve the issue by just downloading the most up to date version of the constraints files. The download dates for the versions that I was using are:

fedramp-external-allowed-values.xml --> 9/11/2024
fedramp-external-constraints.xml --> 10/15/2024

@JoseGHdz thanks I guess you knew that I would ask after office hours. Sorry I didn't see the message before the office hours meetings. Thanks for following up and closing the issue.

GSA / fedramp-automation