Since the proposed CMMC rule was published on December 26, I have spoken with a number of folks who think their organization is ready for an official CMMC Level 2 assessment. All too often, after speaking with them for just a few minutes, I don’t think they are. The three most common problems I have run into are:
- Incomplete/inadequate System Security Plan (SSP)
- Incomplete/inadequate documentation overall
- A lack of understanding of the differences between a DIBCAC High Assessment and a CMMC Assessment.
Let’s look at these issues individually.
Incomplete or Inadequate SSP
Many SSPs are too short and don’t include all the required information. What needs to be included? Well, the NIST 800-171 Rev 2 requirement defining the SSP states:
3.12.4: 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.
Breaking this definition down, there are five essential elements:
1. Develop, document, and periodically update
The requirement begins with “Develop, document, and periodically update,” and yet I often see SSPs that have never been updated or at least not often enough. How often is enough?
In the CMMC Level 2 Assessment Guide, under CMMC-Custom Terms, we find this statement:
Periodically: Occurring at regular intervals. As used in many requirements within CMMC, the interval length is organization-defined to provide OSA flexibility, with an interval length of no more than one year.
CMMC assessors will expect to see your SSP updated with a new revision number and date at least once each year (and you’d better keep a copy of those older versions too, don’t just renumber the current one and save it). Likewise, CMMC assessors will be looking for evidence that other requirements specifying “periodically” have been executed at least annually (for example, 3.11.1 Risk Assessment).
I spoke with one contractor who had undergone a DIBCAC High Assessment about three years previously, and during our conversation, I learned that they had not updated their SSP nor documented a risk or security assessment since that time. That’s an automatic fail in CMMC.
Your SSP is intended to be a living document, one that accurately describes your information system at all times. It should be updated whenever major changes are made and at least annually.
2. System Boundaries
3. System Environments of Operation
4. Relationships With or Connections to Other Systems
The above three elements of your SSP define your Scope. Accurately scoping your CUI environment is the key to your compliance program, and the key to scoping is understanding the flow of data in your organization. What kind of data do you have, and where does it come from? Where is it stored? Who has access to it?
Your system boundaries are your network(s) that process, store or transmit CUI. This section should have a description of your network topography, your network diagram(s), etc. Your system environments of operation generally include physical facilities along with the network components therein.
What about “other systems”? Cloud services, security tools, offsite backups, and managed service providers—these are also in your scope. They need to be documented in your SSP, network diagram, asset list, etc., and their security verified. That’s what 3.1.20 is really about:
3.1.20: Verify and control/limit connections to and use of external systems.
This is a good example of the importance of reading the discussion sections after each requirement listed in 800-171. For this one, we find a description of external systems:
External systems are systems or components of systems for which organizations typically have no direct supervision and authority over the application of security requirements…
Here we also find a discussion on how “Verification that the required requirements have been effectively implemented can be achieved …”
Be sure that for 3.1.20 you describe how you have verified the security of the “other systems” identified in your system boundary and environment of operation.
5. How security requirements are implemented
Does your SSP describe “how security requirements are implemented” or do you just check the box for Yes, No, or N/A?
Simply re-stating the requirement is not describing how the requirement is being implemented, i.e. don’t write, “We have multifactor authentication in place” as your description of how 3.5.3 is implemented. Describe your MFA implementation: What are the two factors? (password, a physical device, an OTP generated by a mobile app, biometrics), and provide details (manufacturer, device, protocols, etc.) Who uses MFA, when, on what devices, and how is it configured?
Did you use 171A? Did you use only the list of requirements in NIST SP 800-171 Rev 2 to write your SSP, or did you consult NIST SP 800-171A to learn the assessment objectives for each requirement? If you haven’t used the Assessment Guide, chances are that you have missed some (and probably many) of the assessment objectives, which means you haven’t fully implemented those requirements.
Incomplete or Inadequate Documentation
If it isn’t written down, it isn’t true.
If it’s not documented, it never happened.
Do what you say, say what you do.
Be sure that not only have you documented your policies and procedures, but they actually match how your organization operates on a day-to-day basis.
For example, if you have a written procedure for running internal vulnerability scans every 30 days, but the assessor learns that this only happens sporadically, or once a year or no one can remember (or show proof of) the last time it was done … Fail.
If your baseline configuration says that antivirus software is configured to auto-update every 24 hours, but screenshots of the actual configuration provided as evidence show it’s set for weekly (or not at all! oops) … Fail.
These tasks don’t have to be done at a particular interval defined by NIST or the DOD, they have to be done at the interval you define. Just be sure your written definitions match reality.
DIBCAC High vs. CMMC Assessment
Many contractors with a mature information security program built on NIST SP 800-171 Rev 2 aren’t fully informed of the differences between the implementation of NIST SP 800-171 Rev 2 and CMMC.
DIBCAC High is not equal to CMMC Level 2
Asset categorization in particular is often misunderstood or even ignored, especially by organizations that have had a DIBCAC High Assessment in the past. Be sure to read the CMMC Level 2 Scoping Guide very carefully.
So, are you actually ready for a CMMC Level 2 Assessment?
If you have read all of the above and nodded your head in satisfaction that your organization doesn’t fall into any of the “fail” scenarios I’ve described, good for you! You may very well be ready for an official assessment.
If not? Ask for help.
About the Author: Glenda R. Snodgrass has been President, lead consultant and project manager at The Net Effect since the company’s inception in 1996. She is a Certified CMMC Professional (CCP) and Certified CMMC Assessor (CCA), specializing in helping organizations meet their security and compliance requirements. She has conducted numerous workshops covering GLBA, PCI DSS, HIPAA, FAR 52.204-21, DFARS 252.204-7012, NIST 800-171, NIST CSF and the Cyber Security Model Certification (CMMC).
