FedRAMP SSP Modeling and Mock-Up

[brian-ruf]

User Story:

As a FedRAMP Cloud Service Provider, I need to submit my FedRAMP-complaint System Security Plan in a machine-readable format that is OSCAL compliant/aligned, as defined by the FedRAMP PMO in cooperation with the NIST OSCAL effort.

Goals:

The ultimate goal is to enable third-party tool development that CSPs can use to develop FedRAMP-compliant SSPs with the guidance of an "expert system". CSPs can then submit SSP content to the FedRAMP PMO in a standardized machine-readable format that enables the PMO to perform automated compliance analysis.

Dependencies:

This must align with implementation-layer OSCAL content being developed in parallel, especially issues #213, #214 , #215 , #216, and #217.

Acceptance Criteria

1. Provide structured data modeling of a FedRAMP SSP, including cardinality.
2. Provide an OSCAL compliant/aligned specification for FedRAMP SSP content.
3. Provide real-world example SSP content expressed in the OSCAL format.

NOTE: A compliant FedRAMP SSP includes several attachments. Some of these documents contain very straight-forward structured data (such as system inventory), and some is strictly unstructured information (such as user guides). This effort will eventually include those highly structured attachments.

[brian-ruf]

FedRAMP SSP Data Modeling Work FedRAMP SSP OSCAL Mock Up

[shawndwells]

Instead of XML, could a different language be used? For example, YAML?

[brian-ruf]

@shawndwells Please take a look at both links in my above comment. The modeling work is YAML(-ish), and the mock-up is XML.

[shawndwells]

yikes - my mistake! thanks for the pointer :)

[brian-ruf]

As I work through the modeling in the context of FedRAMP processes, I am seeing a possible need to have flexibility in an OSCAL SSP format that can either include the entire SSP, or delivery of the SSP in pieces that can be assembled down-stream.

For example, the inventory may be highly static for some systems and highly dynamic for others. A CSP should have the option to either include the <system_inventory> element in the main OSCAL SSP file, or deliver it separately (and updated it often) with some linkage between the two files.

Rather that establishing a mechanism for linking that specific scenario, I'd like to ensure a mechanism that allows for any element or sub-element of the SSP to be an external file that can be merged later. Perhaps we grow on the <import> element that already exists for OSCAL profiles?

[brian-ruf]

10/11/2018 Status Meeting

This is about 90% complete, but not quite wrapped up. My goal is to have it ready for review by COB Friday, Oct 12.

[brian-ruf]

Consider both the modeling and mock-up at 100% draft and ready to begin peer review.

For the sake of schedule I am deferring the mock-up for Attachment 4(b) - Privacy Impact Analysis. It still appears in the data modeling. Since this is only required based on the responses in 4(a), and is a separate artifact, it could be treated as an attachment for now, and modeled in OSCAL later with low impact to our goals.

Further, there are two data-input sections to Attachment 4:

• Component/PII Mapping: Maps privacy information to system components. It seems prudent to leverage the component and control specification in the other work stream when I mock up that mapping.

• Additional Questions: There are over 30 additional questions, similar to the four in the Privacy Threshold Analysis. Any feedback we receive on those, could apply to this modeling as well.

I believe this can be easily addressed when we respond to peer review feedback.

[redhatrises]

@brianrufgsa was reviewing the YAML ssp mockup. I think that there are ways to make simpler and collapse some of the items. Where would be the best place to provide feedback and examples?

[brian-ruf]

@redhatrises here is probably the best place. Please note, the YAML was intended to be more of a one-for-one representation of the SSP. I did collapse some things in the SSP mock-up. Maybe look there to see if I've already address some of your thoughts. I agree with collapsing where practice, and have to align with other OSCAL efforts. Any additional insights are helpful and welcome!

[david-waltermire]

10/25/2018 Status

@brianrufgsa will create the SSP implementation under the content directory and will create a readme indicating that this content is a very drafty draft.

[redhatrises]

@brianrufgsa added a collapsed SSP yml version.

ssp.tar.gz

[iMichaela]

11/08/2018

@iMichaela will review the PR this week.

[david-waltermire]

11/15/2018

This issue has been completed.

Need to create new issues for the following:

• Need to create markdown documents based on the Visio/PDFs provided by @brianrufgsa
• Provide notional provided by @brianrufgsa samples as OSCAL document instances in the repo
• Reorganization of content subfolders by type of content, maturity, and originating organizational entity.

[david-waltermire]

@brianrufgsa Have the issues identified above been created? If so, please reference these here. Please create them otherwise. Once done, assign this back to me to close.

[brian-ruf]

Created the following issues:

• 363 Document Implementation Layer

• 364 Implementation Layer Samples

I suspect the third bullet is addressed by Issue #331, , Refactor Repository Directory Structure for Usability.

[david-waltermire]

Calling this as done.