When people ask me, “what is the single most important document to have to start working towards complying with DFARS clause 252.204-7012 and NIST SP 800-171?”, I always point them to their System Security Plan (SSP). Wait, what? Before the archfiends of the compliance world start saying “I’m wrong” let’s start with some logic first. Logic says that you cannot have completed an assessment without a SSP being in place. Per the NIST SP 800-171 DoD Assessment Guidance for 3.12.4, “The absence of a system security plan would result in a finding that an assessment could not be completed due to incomplete information and noncompliance with DFARS clause 252.204-7012.”. Let’s tease out the Practice into each Assessment Objective (AO) a little to explain the logic.
Since CMMC 2.0 maps over to NIST SP 800-171 I will use CMMC labeling of Practices and AOs. Per CA.L2-3.12.4 at the Practice level you must:
– “Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.”
Now the question becomes how do you do this? That is where you need to start reviewing each AO and breaking it down to the individual components.
a- a system security plan is developed;
Clear as mud, right? It’s not until you get to objective b that you start getting into the meat of the requirement.
b- The system boundary is described and documented in the system security plan;
To accomplish this, you will need to have a network architecture diagram that outlines both your CUI information system boundary and all external connections to other systems.
c- the system environment of operation is described and documented in the system security plan;
In your SSP, you will need to describe what your system environment is being used for along with a basic understanding of the environment itself. Details around the security implementation will be covered in objective e of the Practice.
d- the security requirements identified and approved by the designated authority as non-applicable are identified;
As part of your SSP you will need to identify who has ownership of the information system and responsibility to determine any non-applicable Practices/AOs there would be in the SSP. Sometimes it will be much easier for the DIB to mark something as in place and the provide evidence on why it is in place albeit not in use.
An example of this would be around mobile device management. If your organizational stance is not to allow the use of mobile devices evidence could be anything from policy to a technical control that doesn’t allow for mobile device connections.
e- the method of security requirement implementation is described and documented in the system security plan;
This is where you will need to explain how each component of the information system is configured securely and utilized in addition to how data flows through the system. This Practice is complimented by several other Practices such as CA.L2-3.12.3 (Security Control Monitoring), SC.L2-3.13.2 (Security Engineering), and others to provide the reasoning on needing the details around each component in the environment. Without knowing how the system was architected, controls configured, baselines utilized, and other items you would not be able to know if the security controls are adequate or effective enough and utilize appropriate information security principles.
f- the relationship with or connection to other systems is described and documented in the system security plan;
This ties back to your network diagram that should list all connections to all external systems. An external service provider (ESP) may be in scope if they meet asset criteria described in the CMMC Level 2 scoping guidance. This AO is really about knowing and documenting all your external system connections (e.g. – HR, Payroll, etc) even if they are not in scope of the CUI environment.
g- the frequency to update the system security plan is defined; and
You will see the words ‘defined’, ‘described’, and ‘documented’ all throughout NIST SP 800-171. The question is now where to define the frequency. This will be documented in your policy for the Security Assessment domain or in an overarching security policy depending on preference. When defining the frequency in your policy just ensure that it is defined as at least annually.
h- system security plan is updated with the defined frequency.
After all the work you do to prepare an SSP one of the items that needs to be included is no more than a simple review date, reviewer, change description, version, and signature.
In closing, the SSP is an outline. All the other Practices and AOs make up the story. Try to make it a story that everyone (Assessors) will love to get their hands and a read.
For more than 20 years, KTL Solutions has provided expert guidance in utilizing technology and services to increase efficiency, productivity and security for both enterprise and government organizations. KTL is a Microsoft Gold Certified Partner and a national leader in cybersecurity and compliance for the Defense Industrial Base (DIB) community serving the Department of Defense (DoD), providing licensing and migration for Microsoft 365, Dynamics 365, Azure, and Power Platforms. KTL Solutions’ Microsoft Cloud solutions have been on the forefront of compliance regulations for the DIB regarding CMMC, DFARS, NIST 800-171, and NIST 800-53. KTL is also a CMMC RPO with deep expertise in government cloud, employing a CMMC RP authorized staff ready to help customers navigate ever-changing compliance regulations. Our suite of CMMC Preparedness Solutions ensures you feel confident about meeting requirements and are poised for future success. We are proud to offer an exclusive suite of products and services designed to tailor technology for your organization including KTL Custom Development, KTL Products and KTL Managed Services.
For additional information, please reach out to KTL services.
