Checks for Attachments (Post-OSCAL Still Conventional Attachments)

[ohsh6o]

Prior to OSCAL, CSPs, 3PAOs, and FedRAMP Review Team members would edit the FedRAMP Microsoft Word template. Some of the artifacts below would be inline tables in the Word document, where as others would be discrete attachments. We need to account for this transition, and confirm whether or not it is an attachment.

For those attachments that do not explicitly have their own definition in the OSCAL model, we must review and determine the appropriate strategy for porting it into the attachment model of NIST/FedRAMP system security plans, in XPath notation these items are in /o:back-matter/o:resource. Some may be in the NIST OSCAL namespace (@ns="http://csrc.nist.gov/ns/oscal/1.0" or @ns is unset, which is default and means OSCAL core is presumed) or the FedRAMP namespace (@ns="https://fedramp.gov/ns/oscal"), so some due diligence ought to be performed.

Relevant documentation from FedRAMP to work on the acceptance criteria below, specifically the table.

• Guide to OSCAL-based FedRAMP Content
• Guide to OSCAL-based FedRAMP System Security Plans

Preconditions:

• A working definition, confirmed with the FedRAMP PMO, of "minimally viable validation" for documents that are attachments and not first-class OSCAL objects, documented and included with developer documentation in this repo.

Acceptance Criteria:

• A clear, explanatory validation message with an associated test indicating the Information Security Policies and Procedures is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the User Guide is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Rules of Behavior is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Information System Contingency Plan (ISCP) is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Configuration Management Plan (CMP) is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Incident Response Plan (IRP) is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Control Implementation Summary (CIS) Workbook is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the Separation of Duties Matrix is or is not properly attached as resource/link and properly referenced in OSCAL.
• A clear, explanatory validation message with an associated test indicating the FedRAMP Laws and Regulations is or is not properly attached as resource/link and properly referenced in OSCAL.

FedRAMP SSP Template Location	Description	OSCAL XML Model Location	Notes
§15 Attachment 1	Information Security Policies and Procedures	/system-security-plan/back-matter/resource/prop[@name="type" and . = "plan"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 2	User Guide	/system-security-plan/back-matter/resource/prop[@name="type" and . = "guidance"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 5	Rules of Behavior (ROB)	/system-security-plan/back-matter/resource/prop[@name="type" and . = "TBD"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 6	Information System Contingency Plan (ISCP)	/system-security-plan/back-matter/resource/prop[@name="type" and . = "plan"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 7	Configuration Management Plan (CMP)	/system-security-plan/back-matter/resource/prop[@name="type" and . = "plan"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 8	Incident Response Plan (IRP)	/system-security-plan/back-matter/resource/prop[@name="type" and . = "plan"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 9	Control Implementation Summary (CIS) Workbook	(dynamically generated)	This is no longer an attachment, see Guide to OSCAL-Formatted SSP Section 7.1
§15 Attachment 11	Separation of Duties Matrix	/system-security-plan/back-matter/resource/prop[@name="type" and . = "TBD"]	Text value too vague, needs more focused value in FedRAMP values to filter on
§15 Attachment 12	FedRAMP Laws and Regulations	/system-security-plan/back-matter/resource/prop[@name="type" and . = "law"]	Already attached in pre-configured OSCAL templates unless tampered with

[ohsh6o]

Re this @danielnaab:

A working definition, confirmed with the FedRAMP PMO, of "minimally viable validation" for documents that are attachments and not first-class OSCAL objects, documented and included with developer documentation in this repo.

@ohsh6o will take an action item in a separate task to figure that out and define it properly in #74.

[danielnaab]

If I understand correctly, the following documents do not need to be attached, and should instead have their contents entered via structured data. We may need a separate ticket to track adding the validation rules for these, if we aren't separately tracking the corresponding sections of the FedRAMP SSP guide.

• Digital Identity Worksheet, see: "Digital Identity Determination"
• Privacy Threshold Analysis (PTA), see: "Privacy Impact Assessment"
• CIS Workbook, see: Security Controls
• FIPS-199, see: Security Objectives Categorization (FIPS-199)
• Inventory, see: System Inventory

[ohsh6o]

If I understand correctly, the following documents do not need to be attached, and should instead have their contents entered via structured data.

That seems right to me. I will review and make sure we are on the same page Monday.

We can break down the story into different tasks, or split out the story. I point this out because, from the perspective of the FedRAMP reviewer (FART or JAB), in their review checklist, they as users will want error messaging that discusses them in the current state of affairs: as attachments.

Maybe we conceive the existence checks of them in output as Section B attachment failures, and validating the details of those structures "somewhere else" in a way you or I have not thought of yet.

Make sense?
I am

[danielnaab]

We can break down the story into different tasks, or split out the story. I point this out because, from the perspective of the FedRAMP reviewer (FART or JAB), in their review checklist, they as users will want error messaging that discusses them in the current state of affairs: as attachments.

Makes sense - methinks we could wrap the back-matter scenario inside an attachment one, to handle the two cases in a consistent way.