A FedRAMP SSP (System Security Plan) is the bedrock of a FedRAMP assessment and the primary document of the security package in which a cloud service provider (CSP) details their system architecture, data flows and authorization boundaries, and all security controls and their implementation.
Keep in mind that to prevent conflicts of interest, 3PAO’s are prohibited by regulation from helping a CSP put together a FedRAMP SSP and also conducting that CSP’s FedRAMP assessment.
A FedRAMP SSP is a highly detailed document that must be readable, relevant, consistent, and complete. Even tiny mistakes can cause lengthy delays in the FedRAMP certification process. Here are some tips for writing a successful FedRAMP SSP.
Allocate sufficient time and resources to writing your FedRAMP SSP
Expect your FedRAMP SSP to be several hundred pages long. Putting together an SSP is never an overnight project, and it’s rarely a one-person job. Organizations generally require the input of several subject matter experts with deep technical knowledge of the systems they are documenting, as well as NIST and FedRAMP security controls.
Make sure the FedRAMP SSP is clear, concise, consistent, and complete
Although an SSP is a group project, it shouldn’t “look” like one when it is finished. FedRAMP PMO’s don’t expect System Security Plans to read like Pulitzer Prize-worthy literature, but they do expect that CSP’s to turn in a logically organized document that describes systems and controls clearly and completely, and that is not riddled with spelling and grammar errors. When reviewing an SSP, a FedRAMP PMO looks for the 4 C’s:
* Do not write meandering, convoluted, or overly long descriptions. Avoid the use of passive voice, as it could cause confusion. Do not include text that is not directly relevant to the specific control being described.
* Describe each system and control completely, but use as few words as possible. Make each word count.
* All system names and abbreviations, hardware and software elements, and citations referenced in the SSP should be referenced in exactly the same way throughout the entire document. The presentation style and level of detail should also be consistent throughout.
* Use the correct FedRAMP SSP template, and do not modify or remove sections. However, sections can be added if necessary. Address all required controls. If a control has multiple requirements, you must address all of them. If a control is inherited or does not apply, use a risk-based justification to explain why. You must describe how each control is addressed in your system; you cannot simply copy/paste or rephrase the control requirements.
Identify all people and places relevant to your controls
All people who are responsible for implementing/enforcing a security control must be identified, by role. All roles defined for a control should also be included in the SSP’s Roles and Privileges table.
The SSP must also describe all possible places where a control is implemented; for example:
* Access for both privileged and non-privileged users
* Access control, audit logging, maintenance, flaw remediation, and configuration management for all platforms
* Physical controls at all facilities
Be sure to select the correct Implementation Status for each control
A common SSP error is checking the wrong Implementation Status; for example, a control is marked Planned but does not identify a planned date. FedRAMP offers the following general guidance:
* If all or part of the control is an alternative implementation, check both “Partially Implemented” and “Alternative Implementation.”
* If all or part of the control is planned, check both “Partially Implemented” and “Planned.”
* If selecting a status of Planned, Alternative Implementation, and/or Not Applicable, clearly explain the aspects of the control that are Planned, Alternative, and/or Not Applicable in the implementation description.
* If the control is solely a customer responsibility, and the CSP has no responsibility for the implementation of the control, check “Implemented,” along with the appropriate customer-related control origination.
Use a GRC automation solution
Traditionally, creating a FedRAMP SSP has been an arduous, manual, and chaotic process involving dozens of text documents and spreadsheets. Updating and maintaining it over time was extremely difficult and prone to error, and it wasn’t integrated with any of the technologies 3PAO’s use to carry out FedRAMP assessments.
Now, CSP’s have access to automation solutions that utilize pre-loaded, drag-and-drop modules to walk them through the process of preparing their SSP, ensuring completeness and accuracy. CSP’s not only save time and money upfront, while preparing their SSP, but later on, when they are ready to work with their 3PAO.
Michael Peters is the CEO of Lazarus Alliance, Inc., the Proactive Cyber Security™ firm, and Continuum GRC. He has served as an independent information security consultant, executive, researcher, and author. He is an internationally recognized and awarded security expert with years of IT and business leadership experience and many previous executive leadership positions.
He has contributed significantly to curriculum development for graduate degree programs in information security, advanced technology, cyberspace law, and privacy, and to industry standard professional certifications. He has been featured in many publications and broadcast media outlets as the “Go-to Guy” for executive leadership, information security, cyberspace law, and governance.