Title 32 of the Cybersecurity Maturity Model Certification (CMMC) program requires organizations to have a System Security Plan (SSP) in place at the time of a Level 2 self-assessment or third party assessment. The absence of an up to date SSP at the time of the assessment will result in an incomplete assessment finding and noncompliance with 48 CFR 252.204-7012.
In this blog, we’ll cover the basic tenets of an SSP, then provide you with guidance on how to write a SSP for CMMC Level 2 SSP. The downloadable resource provides a comprehensive CMMC Level SSP Word template featuring 135 pages of formatted placeholders mapped to the 320 NIST SP 800-171A assessment objectives.
Title 32 of CMMC defines a system security plan as a formal document that provides an overview of the security requirements for an information system or information security program and describes the security controls in place or planned for meeting those requirements. While CMMC defines the requirements, NIST SP 800-18 provides the standard for SSP architecture. The system security plan describes the components within the system, the environment in which the system operates, the implementation of security requirements, and the relationship with or connections to other systems.
Information security programs are organization-wide and may provide protection for information and information systems (NIST SP 800-37 Rev 2). Information security program plans supplement system security plans to cover the totality of security controls employed by the organization.
Larger enterprises establish information security programs to achieve a more consistent and scalable application of controls organization-wide. Common controls inherited by an information system are incorporated into system security plans by reference. The implementation details for common controls are provided in the artifacts developed by the common control providers that are made available to system owners.
An information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information (NIST SP 800-171 Rev 2). NIST SP 800-171 security requirements apply to contractor information systems that: process, store, or transmit CUI; provide security protections for systems which process, store, or transmit CUI; or are not logically or physically isolated from systems which process, store, or transmit CUI. The CMMC Scoping Guide Level 2 defines logical and physical separation:
Logical separation prevents data transfer between physically connected assets (wired or wireless) by non-physical means such as software or network assets (e.g.,firewall, routers, VPNs, VLANs).
Physical separation occurs when assets have no connection (wired or wireless). Data transfer is only available through manual means (e.g., USB drive).
Several sections of the SSP template address the system authorization boundary, including the system scope, description of the system, placeholders for network, facility, and data flow diagrams, system component inventory, environment of operation, and system interconnections.
The system scope table categorizes the scope according to the SPRS portal:
According to the initial public draft of NIST SP 800-18 Rev 2, the system description should provide a high-level overview of the system’s characteristics, its purpose, and how it supports the organization’s mission. This might include identifying technologies or factors that present additional security-specific risks, such as cloud-based services or “bring your own device” (BYOD) policies.
The SSP should describe the environment of operation within one to three paragraphs, which includes any environmental or technical factors that raise special security concerns (for example the use of mobile devices or wireless technology). NIST SP 800-70 provides four categories of nonfederal system environments:
Network diagrams identify the physical and logical locations of the system components in the authorization boundary. Identify components based on their roles in the system, such as application interfaces, information data stores, or development, test, and production environments. Account for all system components within the diagrams, whether they are located on-premises, hosted by an external system, virtualized on system host devices, physically or logically isolated or hosted by third-party service providers.
Facility diagrams define protected physical spaces within facilities. These diagrams address scoping discussions related to step 1.3 of the CMMC Assessment Process (CAP).
Data Flow Diagrams identify the direction of data exchanges and the components that receive and transmit data, including:
The Further Discussion section of CA.L2-3.12.4 states that the SSP must include a high-level description of the assets within the CMMC Assessment Scope. The CMMC Scoping Guide Level 2 states the SSP should document the treatment of assets within the CMMC Assessment Scope. Practitioners should categorize types of assets within the system and refer to any system element exactly the same way throughout the SSP. The image below shows a system technology component table that includes asset categorizations:
Keep in mind that system components should also define facilities and people. The image below shows tables to identify facilities and types of users within the system.
The system interconnections table describes the connections to external systems. For each external system interconnect, the table identifies the connection security (IPSec, VPN, etc.), the direction of data, the type of information transmitted, and the communication method (ports and protocols).
CMMC Level 2 contains 110 practices with 320 assessment objectives. In keeping with FedRAMP guidance and industry best practices, we recommend a focused discussion for each of the 320 assessment objectives. This isn’t an explicit requirement but put yourself in the assessor’s shoes for a moment. The assessment has 320 explicit objectives to review, it makes the assessor’s life much easier when the narrative focuses on each of those 320 objectives. Shared responsibilities and control scopes may require further additional segmentation of these 320 narratives.
Your system may include connections to or use of other authorization boundaries (AWS GovCloud, Microsoft Azure, Google Workspace, etc.). FedRAMP authorized cloud service providers should be able to provide you with a Customer Responsibility Matrix (CRM).
Ensure your system security plan explicitly details how your system meets the requirements assigned in the cloud service provider’s CRM. The SSP should address customer specific responsibilities consistently (e.g. addressed under a "Customer Responsibility" heading).
Your system may contain multiple platform components (Windows, Linux, etc.). Different platforms may have unique control configurations and FedRAMP guidance recommends using a standard format for addressing controls by platform within each applicable control part.
We designed this template to accommodate this separation of control implementation statements. The control summary table identifies the responsibility role, implementation status, and origination. The implementation status is a rollup of the status for each underlying assessment objective. The control origination identifies inherited, shared, or internal implementations of the control.
Below the control summary table are tables for each of the relevant assessment objectives. In this example, the scope includes various technology platforms within the system. This column allows for a narrative to describe the implementation of the assessment objective for each platform. The Microsoft 365 GCC High implementation statement references the customer responsibilities relevant to this assessment objective from the Customer Responsibility Matrix. Separate narratives describe the implementation relevant to the Cisco Firewall versus the Nessus Vulnerability Scanner and Windows 11 CUI Laptops.
According to the discussion of CA.L2-3.12.4 from CMMC Level 2 Assessment Guide, effective system security plans make extensive use of references to policies, procedures, and additional documents. Policies and procedures as well as supporting documents should be explicitly referenced by title, date, and version. If the entire referenced document does not apply, provide specific section references. Reviewers should not have to rely on following the references to understand the control implementation. Provide an overview of what the referenced document addresses so the SSP can stand on its own.
In the example shown below, we removed the scoping column as the narrative described the implementation across all platforms within the system. The narrative cites the relevant section of the Access Control Policy and describes how the control satisfies the requirement.
Now that we’ve covered the basic tenets of the SSP, here is a preview of the Word Document Template. The template includes a cover page, revision history table, a signature line for the authorizing official, a description of the system scope, placeholders for network, facility, and data flow diagrams, a table to categorize relevant information types, threats of concern and system contacts.
The System Security Plan is a complex document that brings together work from across teams. Instead of working through iterations of Word documents and tracking progress on an Excel workbook, K2 GRC provides teams with a workspace for methodically drafting, editing, and exporting a Word-based SSP.
This approach includes the following advantages:
Whether you’re starting out on your CMMC journey or updating your SSP post assessment, we hope you find the template helpful. The template contains 135 pages of formatted placeholders for you to describe the implementation of NIST SP 800-171 Rev 2 security requirements. As you establish your narratives, this template will grow to over 200 pages. If you find this content helpful, share it with your colleagues or follow us on LinkedIn for more helpful GRC-focused content.
