Whether for an agency assessment or a Joint Authorization Board (JAB) assessment, the FedRAMP System Security Plan (SSP) is the foundational document that supports a FedRAMP assessment. From it, the government agency representatives and the Third Party Assessment Organization (3PAO) are able to get an understanding of how the FedRAMP baseline security controls are implemented throughout the cloud service provider’s (CSP) system. A poorly written SSP or one that excludes important control implementations will only delay the assessment process and cost the CSP valuable time and resources.
Why is the SSP So Important to a FedRAMP Assessment?
As mentioned previously, the SSP is the foundational document that supports a FedRAMP assessment. The SSP is used by a 3PAO to develop a Security Assessment Plan (SAP). Therefore the SSP must provide sufficient detail on how each control is implemented in order for the 3PAO to develop a test approach for the control.
Also, in cloud implementations it is not unusual to share the full implementation of a control between a CSP and the user of the cloud service offering. Therefore, the SSP also serves to define the boundaries for shared controls between the CSP and the client, for example.
How Do I Get Started Writing the SSP?
Fortunately, the FedRAMP PMO has developed an SSP template for low, moderate, and high baselines. Download them here. The templates are extremely helpful in providing order and structure for the document, but the content is king. Take some time to review the template and get a feel for depth of information required; the Moderate Baseline Template is over 300 pages. Detailed descriptions for control implementations are the bulk of the document, but there are other critical areas that must be addressed accurately as well. See below for key areas to address when writing a FedRAMP SSP.
What is Important to Know When Writing a FedRAMP SSP?
While CSPs must complete all areas of the SSP, below are five areas to focus on when developing a FedRAMP SSP for a low, moderate, or high baseline system.
- Clearly define the system boundaries. The network architecture diagram must be sufficiently detailed to understand all of the components that make up the system as well as where the boundaries of the system are defined. Without a clear boundary, system components that should be included in the assessment may get overlooked. If a component is overlooked, then the appropriate security controls may not be implemented, or the system may not get patched appropriately, thus presenting a vulnerability to the system. The system boundary definition (or network architecture diagram) must include all security related components (e.g., network devices, servers supporting identification and authentication, DNS servers, etc.) as well as web, application, and database servers. Internal and external interfaces must also be defined. With all the information required by the network architecture, it may be helpful to develop multiple diagrams depicting the various layers of the system. To assist with defining the boundary, use an automated tool that can perform discovery scans for hosts on the network.
- Ensure the system hardware and software inventory are complete. The items identified in the network architecture diagram must also be listed on the system hardware and software inventory. If there is a discrepancy between the architecture diagram and the hardware and software inventory, it will bring into question the accuracy of the documentation and may require additional effort to validate both the network architecture diagram and hardware and software inventories.
- Clearly define the data flow through the system. The CSP must clearly document how government data is received, processed, and stored throughout the cloud service offering. In addition, the data flow diagram must accurately describe all the ways users access the data and how government data may leave the boundary of the system. An accurate data flow diagram will help ensure that government data is protected from the moment it is received by the system and throughout its lifecycle within the system. It is important to remember that what is depicted in the diagrams must be in harmony with the control implementation descriptions.
- Completely define the implementation of the control across every applicable component. With so many components comprising the system, it is easy to forget to describe how a control is implemented across each applicable component. One method to assist in the effort of ensuring completeness of the description of controls across the system is to develop a requirements traceability matrix (RTM). The “Y-axis” of the RTM is the listing of each FedRAMP control, and the “X-axis” is the listing of each component of the system. To complete the matrix, simply put an X in the intersection of the component and the requirement. Then, when describing how a specific control is implemented across the system, ensure that each component identified from the matrix is represented in the control description. Developing the RTM will force the CSP engineering team to consider every requirement for every component and how the control can be implemented. While developing an RTM requires a substantial time investment, it will pay off in the end as it will decrease the likelihood of an incomplete control description in the SSP. Auditing is a great example. There are several FedRAMP auditing requirements. Developing an RTM will require the engineering team to consider how each component within the system generates audit events, where the audit events are written, how the audit events can be sent to a centralized audit repository, the contents of each audit event, whether the component can generate required audit events, etc. The same holds true for any custom application. The RTM will help the developers of the custom software components understand the requirements that they must develop to in order to meet FedRAMP requirements. Never leave a control description blank. If the control does not apply, check the N/A box and describe why the control does not apply. Good examples of controls that may not apply to cloud service offerings are controls related to VoIP or wireless.
- Clearly define all parties responsible for implementing a requirement. Oftentimes, the complete implementation of a requirement is a shared responsibility between the CSP and their client, or the CSP and another cloud provider (e.g., PaaS or IaaS). Much like defining system boundaries, the delineation between the CSPs responsibility for the requirement and the responsibilities of other organizations is critical. A well-defined description between the CSP’s responsibilities and those of another organization will help the 3PAO appropriately scope the tests. Identification and Authentication requirements (e.g., IA-2 (11 and 12)) offer a relevant example of how a given requirement can be shared between a CSP and another party. A Federal agency may require the authentication of its users via a Common Access Card, or CAC. The CSP is not responsible for implementing the CAC readers at the federal agency, but it is responsible for accepting the authentication data (e.g., SAML token) from the agency and appropriately using that data for identification and authentication to the cloud system.
What Other Documentation is Required in Addition to the SSP?
Unfortunately, the documentation requirements don’t stop at the SSP. There are a number of other required documents that are attachments to the SSP. Below is partial list of other significant documents that are required in the overall FedRAMP assessment package:
- Information Security Policies and Procedures (supporting the “dash 1” requirements for each control family (e.g., IA-1).
- User Guides
- Contingency Plans
- Incident Response Plans
- Configuration Management Plans
- Control Implementation Summary (CIS) and Worksheet
Summary
Due to the complexities of cloud service offerings and the intricacies of the FedRAMP documentation requirements, writing a FedRAMP SSP is a significant undertaking. If an organization does not want to dive into the deep end of the FedRAMP documentation pool alone, they can work with a FedRAMP 3PAO that provides advisory services. Linford and Company has extensive experience writing SSPs for highly complex programs supporting the Federal government. If you would like to learn more about how Linford and Company can assist your organization regarding either FedRAMP advisory or assessment services, please contact us.
If you are looking for additional information regarding FedRAMP, read our other blog posts here:
- An Introduction to the Federal Risk and Authorization Management Program
- An Expert Guide to a FedRAMP Readiness Assessment
Ray Dunham started his career as an Air Force Officer in 1996 in the field of Communications and Computer Systems. Following his time in the Air Force, Ray worked in the defense industry in areas of system architecture, system engineering, and primarily information security. Ray leads L&C’s FedRAMP practice but also supports SOC examinations. Ray enjoys working with clients to secure their environments and provide guidance on information security principles and practices.