SSP Completeness Checks: 8 Illustrated Architecture and Narratives

[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:

• At least one authorization boundary diagram
• At least one authorization boundary description
• At least one network diagram
• At least one network description
• At least one data flow diagram
• At least one data flow description

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

No response

TASKS

• Specialize media-type constraints for each FedRAMP resource type #674
• Implement Constraints for Diagram Link Validations That Are No Longer Blocked #864
• Add Diagram Link Validation Constraints  #865

[aj-stein-gsa]

Check #881 and #882 for alignment with this issue.

Sorry when I spoke earlier I didn't see what epic you were talking about. I mean those in relation to the PPSM. I would like to review those in the context of #806.

I misunderstood your question. In the context of this diagrams epic, we need to talk about #864 and previous touchups from before that (but you will see in that PR).

[brian-ruf]

Example SSP content is being updated HERE.

Data	Location	Documentation Link	Documentation Notes	Example Updated
Boundary Diagram(s)	//system-characteristics/authorization-boundary/diagram/link/@href	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#authorization-boundary	update example to use actual UUIDs	Y
Boundary Description	//system-characteristics/authorization-boundary/description	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#authorization-boundary	update example to use actual UUIDs	Y
Network Diagram(s)	//system-characteristics/network-architecture/diagram/link/@href	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#network-architecture	update example to use actual UUIDs	Y
Network Description	//system-characteristics/network-architecture/description	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#network-architecture	update example to use actual UUIDs	Y
Data Flow Diagram(s)	//system-characteristics/data-flow/diagram/link/@href	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#data-flow	update example to use actual UUIDs	Y
Data Flow Description	//system-characteristics/data-flow/description	https://automate.fedramp.gov/documentation/ssp/4-ssp-template-to-oscal-mapping/#data-flow	update example to use actual UUIDs	Y

[brian-ruf]

the following is required by core OSCAL and requires no constraint:

• //system-characteristics/authorization-boundary/description
• //system-characteristics/network-architecture/description
• //system-characteristics/data-flow/description

The following is optional under core OSCAL, but required by FedRAMP and require constraints:

• //system-characteristics/authorization-boundary/diagram/link/@href
• //system-characteristics/network-architecture/diagram/link/@href
• //system-characteristics/data-flow/diagram/link/@href

For each of the above links, the following checks are required:

• Is the //diagram/link/@href present? (ERROR if not present)

• Is the //diagram/description present? (ERROR if not present)

• Is the attachment indicated by the above @href viable to the FedRAMP PMO? (ERROR if not viable)

  • For example, is the link resolvable when processed within FedRAMP systems or the public Internet?
  • addressed by issue Implement Constraints for Diagram Link Validations That Are No Longer Blocked #864

[brian-ruf]

• Each diagram has an associated description, which is also required, but enforced through core OSCAL as a require field, thus requires no FedRAMP constraint.

• The following relevant constraints were previously defined and tracked in the constraint tracker:

  • has-authorization-boundary-diagram-link-href-target
  • has-network-architecture-diagram-link-href-target
  • has-data-flow-diagram-link-href-target

No constraint tasks need to be defined as existing constraint work in progress already addresses the necessary work.
The relevant tasks have been added to the core issue text above for tracking.

[aj-stein-gsa]

We looked at this and there is some need for doc touch-ups but other than constraints coded and more or less ready to go. There is some consideration about recommending/requiring the "link-to-resource, no inline linking" approach for diagram image data itself.

[brian-ruf]

Per today's conversation, @aj-stein-gsa, @Rene2mt and @brian-ruf agree that we should be enforcing a required description for each attached diagram. This is already implemented, and only mentioned here for completeness of the topic. Updating the above comment to reflect this addition.