Introduction
I really wanted to open up this blog with a funny “Three types of assessments walk into a bar” joke since those types of jokes always depend on some common stereotypes. Alas, I don’t think it would be well received. I literally asked ChatGPT to give me a funny joke about common misunderstandings between the different assessment types involved in CMMC and this is what it put out:
—————————————————————————————————–
A Security Control Assessment, a Vulnerability Assessment, and a Risk Assessment walk into a bar.
The bartender says,
“Is this some kind of audit?”
The Security Control Assessment says,
“I just want to make sure everyone claims they’re doing the right thing.”
The Vulnerability Assessment says,
“I’ll be over here pointing out all the ways this place could burn down.”
The Risk Assessment sips a drink and says,
“Relax. It’s only a problem if someone cares.”
—————————————————————————————————–
Pure comedy gold, right?
As unfunny as that AI written joke was, I still give it credit. It calls out some common misunderstandings that I see working with organizations preparing for the Cybersecurity Maturity Model Certification (CMMC) and building a solid governance program. Mainly, some often conflate Security Control Assessments, Vulnerability Assessments, and Risk Assessments together. They are related, but they are not the same!
Here’s another blog where my aim is to provide clarity. In this post, I’d like to break down the differences between an organization’s Risk Assessment, their Vulnerability Assessments, and the Security Control Assessment. Each is a fundamental part of a mature, effective cyber governance program, and you need to perform all of them to be ready for CMMC. I also want to vindicate the common intuition many have regarding the relationships between these assessments and bolster the correlative approaches between them. I do affirm these different assessments are related, and their outputs ought to work together. We’ll go into more details on that soon.
Do you kiss your mother with that mouth?
One thing that I always try to be careful about is making sure that the person I’m speaking with is on the same page when it comes to basic definitions of terms. When it comes to the different assessment types involved in CMMC, at the beginning of the conversation, this is not always the case. There are several different ideas and assumptions as to what each of these assessment types entails and means. Just a piece of advice: always make sure everyone clearly understands what each person means when they say “Risk Assessment” or “Control/Gap Assessment” etc. It’ll save you a world of trouble! I can’t tell you how many times I’ve asked if an organization has performed a Risk Assessment before and they, with confidence, have pointed me to their most recent vulnerability scan results and said “Voilà!”; to which I respond, “Do you kiss your mother with that mouth?” Jokes aside, getting this right is critical. There are direct requirements that will be marked as either “Met” or “Not Met” by an assessor, and the determination is heavily dependent on having a clear understanding of these requirements. So, let’s define our terms.
To start with the basics, an assessment is simply the action of making a judgement/determination about something. In governance, risk, and compliance, this is usually a documented activity and, depending on the type of assessment being performed, is governed and guided by a formally documented procedural guide. When implementing CMMC Level 2, organizations typically perform three major types of assessments: Risk Assessments, Security Control Assessments, and Vulnerability Assessments. All of these are related in at least some way but are vastly different and distinct activities within an organization.
Risk Assessments
According to the National Institute of Standards and Technology (NIST) Glossary of terms, a Risk Assessment is “The process of identifying risks to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation of a system.” In my opinion, Risk Assessments are the most important and healthy assessment an organization can do for itself, as they set the precedent or basis for other security requirements selected for the implementation of the system. For CMMC/NIST SP 800-171 Rev 2, risk assessments are required per RA.L2-3.11.1 and, practically speaking, is performed by a group of stakeholders in the organization that can speak to all the different aspects and concerns of a system and can voice their concerns and their perceived risks regarding the parts of the system they vouch for.
An organization can perform a risk assessment in different ways, but it usually involves scheduling a meeting with the company’s relevant stakeholders to identify the sources of threats that exist across the organization and target the information system components they oversee. This often feels like a brainstorming session where people voice potential threats they believe could disrupt system operations that, if exploited, could negatively impact desired outcomes and business objectives.
This conversation leads to a calculated prioritization of the risks that have been discussed based on factors such as the assumed likelihood that the risk will be realized and/or exploited and the severity of impact that the risk, were it to be realized in the system, would have on the system.
Then, stakeholders and leadership determine what must be done about the risks they’ve identified by making risk response decisions. This is where leadership is faced with decisions regarding how much they care about the identified risk and what they think is the best approach (hence why ChatGPT mentioned someone caring in the joke). They are often heavily subjective decisions and are regularly determined by the disposition, inclinations, and whims of leadership. Common risk response decisions include the following:
- Avoiding the risk by taking action to remove its source entirely from the system.
- Sharing the risk by splitting the responsibility of risk and the consequence of exploitation with another organization.
- Mitigating the risk by putting administrative, technical, or physical security controls in place.
- Transferring the risk by totally shifting both responsibility and consequences to another organization.
- Accepting the risk by deciding to do nothing beyond acknowledging it, with stakeholders and leadership agreeing to tolerate its presence.
The outcome of a risk assessment should be a documented register/list of all the identified risks, their priority/risk values, and the risk response decisions and strategies. This register/list, and their relevant details, should be updated on a regular basis and when new risks are identified in the system and communicated to stakeholders.
The reason why contractors must implement NIST SP 800-171 per DFARS 252.204-7012 is because the Department of Defense has identified the risks involved with non-federal systems storing, processing, and transmitting sensitive government data, namely Controlled Unclassified Information (CUI), and has determined that their mitigation for the risks involved is the implementation of security requirements contained therein.
For more information on Risk Assessments and how they should be conducted, please review NIST SP 800-30. Though it’s focused on federal Information system-related risk assessments, most of the principles are still helpful in understanding risk assessments – so much so that the CMMC Assessment Guide for Level 2 references it!
Vulnerability Assessments
Now that I’ve established what a Risk Assessment is, let’s clear up one of the most common misunderstandings. Risk Assessments are not the same as Vulnerability Scans or Assessments. They’re closely related, but they are distinct activities that serve different purposes.
A Vulnerability Assessment is the overarching intentional activity of identifying vulnerabilities for a system and documenting them for future remediation purposes. It uses tools like vulnerability scanners, third-party penetration testing, and other manual reviews to look for the “holes” that bad actors can exploit.
There are a few requirements in CMMC that are pertinent here. Firstly, RA.L2-3.11.2 requires organizations to scan for vulnerabilities in their information system at a defined frequency and when new vulnerabilities are discovered that may impact the system. Additionally, CA.L2-3.12.2 requires organizations to identify and document Operational Plans of Action (POAs) for compliance deficiencies and vulnerabilities.
From reading the requirements, you’ll notice that within CMMC, there is no requirement to perform a traditional penetration test or do a “vulnerability assessment”; only that the organization is required to scan for vulnerabilities, track/document them, and remediate them in accordance with risk assessments (per RA.L2-3.11.3). Here’s where the fun begins!
Remember when I said risk assessments and vulnerability assessments are closely related? Well, that’s because RA.L2-3.11.3 requires identified vulnerabilities (i.e., from vulnerability assessments, scans, pen-tests, etc.) to be remediated in accordance with risk assessments. Vulnerabilities are risks to the organization; however, they are not the only risks to the organization. This means that part of the risk assessment, and what’s included in the risk register, must preemptively take vulnerabilities into account and include a strategy for how the organization needs to address vulnerabilities (which are risks to the organization) that are discovered as part of a vulnerability assessment/scan. What this normally looks like is identifying vulnerabilities, as a whole, in the risk register and defining the remediation time threshold for different criticality levels as part of the mitigation risk response decision.
Security Control Assessment
The final assessment type to mention is the “Security Control Assessment”. A Security Control Assessment is “The testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization,” according to the NIST Glossary, once again. In more practical terms, this is what a CMMC Third-Party Assessment Organization (C3PAO), or the internal security team, will do every so often to determine if the requirements have been implemented and should result in a “Security Assessment Report” (SAR) and, for CMMC/NIST SP 800-171, a calculated Supplier Performance Risk System (SPRS) score. This score is calculated based on the requirements in DFARS 252.204-7019 and the 32 CFR Part 170 and is uploaded to the SPRS system as part of the contractor’s obligations under these requirements.
For a CMMC Level 2 Security Control Assessment that is performed by a C3PAO every three years, if all requirements are met or if all the conditions are met for having a Plan of Action and Milestones (POA&Ms) for certain requirements, this assessment also results in a CMMC Certification for the system that was assessed.
Security Control Assessments focus entirely on whether the controls selected for the organization have actually been implemented in the system correctly and are working as intended. For the protection of CUI in contractor systems, NIST SP 800-171 was the list of controls (security requirements) selected for the associated risks and are, in turn, the requirements that are validated during such an assessment.
The reason why I include Security Control Assessments here is that one of the results of a security control assessment for an organization may be the identification of a previously unrealized risk related to the way a certain requirement is applied uniquely in a certain organization. Sometimes, a requirement that is being assessed as part of the security control assessment cannot be applied in a way that is as straightforward as it may be for another system. Therefore, you could see risks associated with the unique nature of the system at hand. Additionally, some requirements that will be scrutinized as part of a security control assessment implicitly require certain things to be included in the risk assessment and register.
Here are a few examples:
- L2-3.2.1 requires that “security risks associated with organizational activities involving CUI are identified”. This means that the risks documented in the risk registry and considered during risk assessments should include those involving CUI.
- L2-3.11.3, as mentioned earlier, requires that the risk assessment address vulnerabilities to guide the remediation requirements for identified vulnerabilities in the system.
Conclusion
I’m truly hoping that this short blog has helped clarify the relationship and the stark differences between these common assessment types. These are important ones to get right so that you’re not floundering in your CMMC implementation and so that you’re prepared for your Security Control Assessment whenever it happens (should already be doing it annually per DFARS 252.204-7019 and CMMC’s CA.L2-3.12.1). At IntelliGRC, we’re constantly striving to help organizations tackle these challenges and tasks while trying to educate along the way. We truly love the “teach a person to fish” model ‘round these parts and hope you’ve benefited a tad from this content.
If you’re struggling with performing Security Control Assessments, Risk Assessments, doing basic vulnerability assessments and management, or need help with understanding or implementing any of the other requirements from CMMC, we’d love to hear from you and see how we can help! You can always touch base with me, Steven Molter, on LinkedIn or contact us through our Contact Us page on our website.
Until next time, happy implementing!