A System Security Plan (SSP) defines the boundary of connected components that make up an information system and outlines how you implement security requirements.
DoD, GSA, and NASA require all contractors and supply chain partners that handle controlled unclassified information (CUI) to implement the security safeguards defined in the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171.
Control 3.12.4 of NIST SP 800-171 requires non-federal organizations to develop, document and periodically update an SSP.
The purpose of this blog is to:
Explain why you need to have an SSP
Identify necessary components
Review formatting considerations
Discuss Plans of Action & Milestones (POA&M)
Explore Automation for SSP Generation
Table of Contents
Why Do You need an SSP?
The government has entrusted its supply chain partners to adequately protect information not cleared for public release. DoD started including contractual requirements to safeguard relevant data types beginning in November of 2013.
These requirements have matured over the past decade, guided by both advanced persistent threats and resource constraints within the defense industrial base. After a series of well-publicized data breaches and cyber espionage from foreign adversaries, a shift from self-assessment and self-attestation to third-party verification and certification is underway.
The requirement for an SSP first appeared in June 2015. Back then it was a practice NIST assumed non-federal organizations would be performing. This caused some confusion around whether it was a requirement to have one.
NIST formally incorporated the requirement to have an SSP in December 2016. DoD required contractors to implement this control by the end of December 2017.
NIST 800-171 requires suppliers and contractors to submit their SSP to the responsible federal agency/contracting officer when requested. In April 2018, the DoD proposed assessing and scoring SSPs based on the level of risk associated with unimplemented controls.
At a CUI System Requirement Workshop in October of 2018, representatives from NIST and NARA addressed why a third-party verification process wasn’t included in the DFARS. Gary “Gus” Guissanie, Adjunct Research Staff Member at the Institute for Defense Analysis, cited several reasons:
There is already an internal requirement to assess it (SSP) and when you sign the contract, you’re saying you meet the requirement.
DoD doesn't have someone independently assess whether or not you meet the fair labor standards act or fair pricing and all those other things, so why add it to this one.
There has been experience in the Department in other areas where - I think the term is creating a cottage industry of non-value-added stuff.
However, Gus cautioned that all this was being re-looked by DoD. There is interest, to have a better understanding of what controls are there to protect this information. Especially, for high-risk situations. For example, for moderate risk CUI:
“I may want to go look at the SSP and what your POAMs are doing and from having looked at a number of those, you can tell right away that somebody knows what they’re doing or don’t know what they’re doing”
In February 2019, the Defense Contract Management Agency (DCMA) assessed and recommended a set of business strategies that would:
Strategically obtain and assess DoD contractor system security plans
Apply a standard methodology to recognize cybersecurity readiness
Propose a methodology to determine industry cybersecurity readiness
The Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) has existed since 2019. It conducts reviews of contractors' adherence to the NIST standards.
In late 2020, DoD standardized a method for assessing the implementation of security requirements. The SSP was the basis of any evaluation for this standardization.
The SSP will exist as a roadmap moving forward, especially with upcoming CMMC rulemaking. It demonstrates compliance with the CUI safeguarding requirements.
Necessary Components
In February of 2006, NIST published SP 800-18, the Guide for Developing Security Plans for Federal Information Systems. You can tailor this guidance down to the minimum requirements detailed as security requirement 3.12.4 within NIST SP 800-171A. These assessment objectives became the basis for Practice CA.L2-3.12.4 with CMMC 2.0.
Let’s start with the specific requirements for an SSP within CMMC and we’ll use NIST SP 800-18 for additional guidance:
(A) Developing a System Security Plan
Below are the steps from NIST SP 800-18 for developing an SSP:
3.1 Assign the system with a name and unique identifier
3.2 Categorize the system using FIPS 199
Since your system contains CUI, DoD has already categorized the confidentiality impact as no less than moderate. They tailored the security controls from NIST SP 800-53 in creating NIST SP 800-171 to provide a moderate baseline.
3.3 Identify a system owner who is the key point of contact and include:
Name
Title
Agency
Address
Phone Number
Email Address
3.4 Identify an authorizing official who has the authority to accredit the system
3.5 Identify other key contact personnel who can address inquiries regarding system characteristics and operation.
3.6 Identify individual(s) authorized to address the security requirements and provide their contact information.
3.7 Indicate the system’s operational status (Operational, Under Development, Undergoing a major modification)
3.8 Classify the system as either a Major Application or General Support System
3.9 Briefly describe the functions and purpose of the system. If classified as a general support system, list all supported applications, describe their functions and the information they process. In a list of both internal and external user organizations.
(B) Describe and document the system boundary
The Supplier Performance Risk System portal provides three options to choose from when identifying the scope of a NIST SP 800-171 self-assessment:
Enterprise - Entire network under the Commercial and Government Entity (CAGE) code
Contracts - Contract specific SSP review
Enclave - Standalone under Enterprise CAGE as a Business Unit
Scope refers to the security boundaries defined by assigning the following resources to a system…
Personnel
Equipment
Funds
Technology, to an information system.
Partitioning information systems to limit access to critical or sensitive information can reduce the number of resources required to secure systems that do not require the same level of security.
The CMMC Assessment Scope Level 2 documents four categories of assets in the SSP:
CUI Assets - assets that process, store or transmit CUI
Security Protection Assets - assets that provide security functions to CUI assets
Contractor Risk Managed Assets - assets that can but are not intended to process, store, or transmit CUI because of security policy, procedures, and practices are in place.
Specialized Assets - Assets that may or may not process, store, or transmit CUI and fall into one of the categories below:
Government Property
Internet of Things (IoT) devices
Operational Technology (OT)
Restricted Information Systems
Test Equipment
Assets that are physically or logically separated from CUI assets and do not provide security functions or capabilities to any of the asset classes listed above are Out-of-Scope of Assets.
(C) Describe and document the system environment of operation
The CMMC Assessment Guide - Level 2 specifies the Environment of Operation as the physical surroundings. Section 3.10 of NIST SP 800-18 provides guidance writing a brief one to three paragraph general description of the technical system and includes any environmental factors that raise special security concerns. Typical operational environments, as defined by NIST SP 800-70, include:
Standalone or Small Office/Home Office - characterized by a variety of small-scale environments and devices.
Managed or Enterprise - characterized by organized suites of hardware and software.
Custom - characterized by functionality and degree of security that does not fit the other environments. There are two types of Custom environments, both of which could be subsets of other systems:
Specialized Security-Limited Functionality - contains systems at a high-risk of attack with security taking precedence over functionality.
Legacy - contains older systems that use older, less-secure communication mechanisms.
(d) Identify the non-applicable security requirements
There are four outcomes from evaluating security controls implementations:
Met - successfully conforms to all objectives
Not Met - does not conform fully to all of the objectives
Not Applicable (N/A) - practice does not apply
Compensating Control - alternative control used
There may be security requirements or attributes that don’t apply to your organization. Or, you may choose to satisfy a particular requirement with a compensating control. You should identify these security requirements and document the reasons why they are not applicable. The DoD Chief Information Officer (CIO) is responsible for ensuring consistent adjudication of proposed non-applicable or alternative security measures.
(E) Describe and document the method of implementation for each security requirement
For each met control, NIST SP 800-18 instructs the description to contain:
The security control title
Implementation of the security control
Applicable scoping guidance or considerations
Technology-related considerations
Controls referring to specific technologies are only applicable when employing those technologies.
Controls only apply to those components of an information system that provide the security capability addressed by the minimum security requirements.
Compensating security controls using non-automated mechanisms or procedures only satisfy minimum security requirements when automated mechanisms are not readily available.
Infrastructure-related consideration
Controls that refer to facilities (e.g. physical access controls) will only apply to those facilities that directly protect to or support for the information system.
Indicate if the security control is common
Who is responsible for its implementation
(f) Describe and document the relationship with or connection to other systems
NIST SP 800-18 instructs this requirement to document (in a table format) each interconnection with the following information:
Name of the connected system
Organization that owns or operates the system
Type of interconnection
Authorizations for interconnection
Date of agreement
FIPS 199 Category
Certification and accreditation status of the system
Name and title of the authorizing official
(g) Define the frequency to update the SSP
SSP updates should occur at least once a year or whenever significant changes occur.
(h) Update the SSP with the defined frequency
Whenever updating the SSP, the owner should:
Add a version number
Document the date the authorizing official approved the plan
Attach the approval documentation (accreditation letter, approval memorandum)
Formatting Considerations
NIST SP 800-18 Template
The first SSP format that we’ll present is from Appendix A of NIST SP 800-18. The guidance on the template advises that this is not a mandatory format. Further, it points out that various approaches for SSP development and presentation exist.
For each template reviewed, we will provide a scorecard mapping back to the requirements of NIST SP 800-171 security requirement 3.12.4. Not surprisingly, the NIST template meets 100% of the requirements identified in the guidance. It may not be the best-looking template, but it contains everything you need.
via NIST SP 800-18
NIST CUI-SSP Template
The second SSP format that we’ll present is from the supplemental material NIST SP 800-171. The guidance on the template also states that there is no prescribed format or a specified level of detail for SSPs. However, organizations should ensure they convey the required information in control 3.12.4.
Let’s take a look at the scorecard mapping back to the requirements of NIST SP 800-171 security requirement 3.12.4. This template has less coverage than the other NIST template. This template left out some of the aspects of developing the system, including identifying an authorizing official, other designated contacts, operational status and system type. However, it also is missing a placeholder to address the specific requirement of describing the interconnections with other systems. If you decide to use this template, you may want to consider addressing those gaps.
FedRAMP SSP Moderate Baseline Template
Aside from NIST, FedRAMP provides another example template to consider. The SSP Moderate Baseline template provides the framework to capture the system environment, responsibilities, and current control status required for the system.
Let’s take a look at the scorecard mapping back to the requirements of NIST SP 800-171 security requirement 3.12.4. At nearly 340 pages, the FedRAMP template is thorough, to say the least. It meets all the requirements, presents the information in a visually appealing format and we especially like how it addresses the controls at the objective level, allowing for multiple summaries per control. It does require a significant amount of tailoring to remove non-related content and update the controls from the NIST SP 800-53 framework to NIST SP 800-171 but this is our favorite template to start from.
Open Security Controls Assessment Language (OSCAL)
As DoD moves to require their supply chain to regularly provide SSPs, this requirement will likely one day evolve into a machine-readable process. NIST, in collaboration with the industry, has developed a set of formats expressed in XML, JSON, and YAML that provide machine-readable representations of system security plans.
Let’s take a look at the scorecard mapping back to the requirements of NIST SP 800-171 security requirement 3.12.4. We only assess the JSON structure for purposes of the scorecard evaluation. We did note that several fields were missing, including the authorizing official, a description of the system environment of operation and references to interconnections with other systems.
Chances are you are not going to submit an SSP in OSCAL format soon. However, we can certainly see a benefit to using machine learning in the assessment of SSPs for the identification of vulnerabilities across a wide number of SSPs. We’ll talk more about automation at the end of this blog.
JSON Format Example
XML Format Example
YAML Format Example
What is a Plan of Action and Milestone?
Plans of action and milestones (POA&Ms) are road maps. They correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. Organizations may identify deficiencies during an assessment or through continuous monitoring.
According to the Office of Management and Budget (OMB) memoranda M02-01, a plan of action and milestones (POA&M) identifies tasks, including controls or assessment objectives, not yet completed. For each POA&M item, organizations should identify the required resources, target milestone dates and scheduled completion dates.
When uploading a self-assessment score into the SPRS portal, a score of less than perfect (110) will require you to enter the date when your last POA&M item. Currently, suppliers can have a non-perfect score and still comply with DFARS 252.204-7012 as long as they document any non-implemented controls on the POA&M.
The upcoming rulemaking process for CMMC will specify which controls may be partially or not implemented at the time of the certification assessment and how long organizations seeking certification (OSC) have to close out any open POA&Ms. The current guidance is that only controls with a scoring potential of a single point (using the SPRS scoring methodology) will be able to be on a POA&M at the time of certification and OSC must have a plan to close out any open POA&Ms within 6 months from the date of the assessment.
You can find examples of POA&Ms at both the NIST and FedRAMP websites.
Automating Your SSP Generation
We’ve talked about the requirements guiding the creation of an SSP, the formatting considerations and the relationship an SSP has with a Plan of Action and Milestones. When discussing automation, GovLoop featured blogger John Keese noted that SSPs are often hundreds of pages long and they are difficult to update, resulting in a labor-intensive process to create and maintain.
We designed K2 Compliance with the automation of the SSP in mind. We were able to combine an intuitive graphical interface and a logical assessment workflow to enable organizations to export a custom SSP and POA&M specific to their environment.
Here is a breakdown of the requirements and how we address them using K2 Compliance:
Develop the System
We met most of these development requirements using a series of fillable text fields associated with the SSP. We then linked the contact table to list other designated contacts.
Describe and document the system boundary
An upload feature accepts all file formats or links.
Describe and document the system environment of operation
Enter this information into fillable text fields.
Identify the N/A security requirements
Mark the control as N/A if all assets and all objectives are not applicable.
Identify the N/A security requirements
Mark the control as N/A if all assets and all objectives not applicable.
Associate evidence using either a link or an attachment.
A process summary and technologies used are then input.
Enter a compliance determination along with an expiration date, implementation status and tier.
This allows for a more granular representation of control implementation. It accommodates multiple process summaries tied to specific assets and objectives.
Describe interconnections with other systems
We created a separate table to map all interconnected systems and linked it to the SSP template.
SSP Generation Workflow
To create an SSP, an organization:
Identifies their CMMC scope (technology, people, locations)
Apply the relevant scopes to the required security controls
Assess and describe the implementation of the required controls
Produce SSP Report
We’ve drawn from the templates described above to create an SSP template on-demand. To evaluate if this solution might be a good fit for your organization, sign up for a 30-day free trial.
