Check for CUI marking on all digital authorization package content

aj-stein-gsa commented 1 month ago

Constraint Task

As a digital authorization package maintainer, to meet FedRAMP requirements, avoid passbacks, and properly identify data security requirements while doing so, I want to know all my documents in the package have properly selected the correct data classification or return a passback error.

Intended Outcome

Goal

Identify package documents that require a CUI marking (so all but catalogs and profiles; those are inherently not controlled, they go everywhere)

Syntax

[x] An expect constraint to check that for /(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)/metadata/prop[@name="marking"]/@value to return a message with @level="ERROR" for a document that does not prop[@name="marking"]/@value = cui.
~An allowed-values constraint constraint to check the syntax /(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)/metadata/prop[@name="marking"]/@value for an allowed value of cui. This enumeration will allow undefined values @allow-other="yes", see allowed-values guidance below.~

VALID:

<system-security-plan>
  <metadata>
    <prop name="marking" value="cui"/>
  </metadata>   
</system-security-plan>

<assessment-plan>
  <metadata>
    <prop name="marking" value="cui"/>
  </metadata>   
</assessment-plan>

INVALID:

<system-security-plan>
  <metadata>
    <!-- no marking prop at all -->
  </metadata>   
</system-security-plan>

<assessment-plan>
  <metadata>
    <!-- no marking prop at all -->
  </metadata>   
</assessment-plan>

Syntax Type

This is optional core OSCAL syntax.

Allowed Values

There are only NIST-defined allowed values.

Metapath(s) to Content

/(assessment-plan|assessment-results|plan-of-action-and-milestones|system-security-plan)/metadata/prop[@name="marking"]/@value

Purpose of the OSCAL Content

[x] Check for proper data classification of package documents (SSP; SAP; SAR; POAMs)

Dependencies

N/A

Acceptance Criteria

[x] All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
- [x] Explanation is present and accurate
- [x] sample content is present and accurate
- [x] Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
[x] All constraints associated with the review task have been created
[x] The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
[x] The constraint conforms to the FedRAMP Constraint Style Guide.
- [x] All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
[ ] Known good test content is created for unit testing.
[ ] Known bad test content is created for unit testing.
[ ] Unit testing is configured to run both known good and known bad test content examples.
[ ] Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
[x] A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
[x] This issue is referenced in the PR.

Other information

Part of epic #804.

aj-stein-gsa commented 2 weeks ago

@DimitriZhurkin please review the checklist tomorrow and be ready to confirm if this issue, now that PRs are closed, is ready to ship.

DimitriZhurkin commented 2 weeks ago

Technically, unit tests exist only for SSP. Work on SAP, SAR, and POA&M hasn't started yet.

Rene2mt commented 2 weeks ago

@aj-stein-gsa and @DimitriZhurkin the constraint itself is the same (https://github.com/GSA/fedramp-automation/pull/875/files#diff-d8b799dfbfbf5f5ac64efe9def7e0cf21d38ded8ebc763b4c266aaa59060f63e) for the models, but as Dimitri noted, we'd have to update the unit tests and create additional sample test files for SAP, SAR & POA&M. Unit test file would looks something like this for marking-PASS.yaml:

# Driver for the valid marking constraint unit test.
test-case:
  name: The valid marking constraint unit test.
  description: Test that the SSP, SAP, SAR, and POA&M metadata contains the "marking" property.
  content: 
    - ../content/ssp-all-VALID.xml
    - ../content/sap-all-VALID.xml
    - ../content/sar-all-VALID.xml
    - ../content/poam-all-VALID.xml
  expectations:
    - constraint-id: marking
      result: pass

And we'd have to do something similar for marking-FAIL.yaml. Should we do that now, or scope this issue to just the SSP which is already done, and create separate issues for adding unit test vectors for the SAP, SAR, and POA&M?

aj-stein-gsa commented 2 weeks ago

Should we do that now, or scope this issue to just the SSP which is already done, and create separate issues for adding unit test vectors for the SAP, SAR, and POA&M?

If we need to consider the scope of work to be everything but the constraint @test logic, so docs and examples, which makes the work effort more clear and faster? I don't have a strong opinion on this one, so I can just pick if others do not. 😄

aj-stein-gsa commented 2 weeks ago

Per conversation in a backlog meeting at the time of this writing, for low-risk cross-model //metadata constraints, we can accept not explicitly adding per-model tests for such requirements that are also covered in generic documentation for cross-model requirements, I am happy to accept the included tests and examples as-is and the work is ready to release.

GSA / fedramp-automation