When it comes to recent CMMC discussions, it feels as though the trees are being missed due to the forest being in the way. Specifically, quite a few discussions on "necessary evidence" needed to satisfy either DIBCAC or C3PAOs miss the intent of the controls in question. These evidence discussions are devolving to the point where there are absolutes with no leniency, which is not how risk management occurs in real life. Before going down a rabbit hole on the train wreck that is CMMC, our time is best spent on something worthwhile like providing some useful education that everyone can benefit from.

Threat, Vulnerability & Risk Management Practices

Threat, vulnerability and risk management practices are meant to achieve a minimum level of protection - this equates to a reduction in the total risk due to the protections offered by implemented controls. Think of this as a "risk management ecosystem" as it pertains to your CMMC compliance efforts. These ecosystem components have unique meanings that need to be understood to reasonably protect people, processes, technology and data.

Why is this useful? Understanding the context of how these components integrate can lead to more meaningful discussions and practical risk management activities. The diagram below is meant to show those interactions. It also helps show that compensating controls (e.g., POA&M items) are not bad, since compensating controls can help reasonably mitigate deficiencies.

For example, RA.L2-3.11.3 (vulnerability remediation) can mean a variety of different things that range from process changes, to personnel training to technology-related maintenance (e.g., patching). That control compliments but is different from SI.L1-3.14.1 (flaw remediation) that can mean a wide variety of options that range from physical/logical isolation, patching, restrictive ACLs, etc. These controls are not 100% focused on software patching, so organizations need to look at any kind of remediation efforts in more of a holistic manner. As for DIBCAC/C3PAOs, please understand that evidence on those controls means more than just patch level reporting. This is where real risk management decisions need to be evaluated, since every organization is different in how it approaches "remediation" since that means more than just patching.

Contextual Definitions

Please be a good person and avoid "word crimes" since words matter in compliance:

• Threat. A person or thing likely to cause damage or danger (noun) or to indicate impending damage or danger (verb).
• Risk. A situation where someone or something valued is exposed to danger, harm or loss (noun) or to expose someone or something valued to danger, harm or loss (verb).
• Vulnerability. A weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.
• Control. The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information.
• Compensating Control. The security controls employed in lieu of the recommended control(s) that provide equivalent or comparable protection for an information system or organization.
• Procedure. A set of instructions used to describe a process or procedure that performs an explicit operation or explicit reaction to a given event. The design and implementation of a procedure must be reasonable and appropriate to address the control.
• Reasonable. Appropriate or fair level of care. This forms the basis of the legal concepts of "due diligence" and "due care" that pertain to negligence.
• Mitigate. To make less severe or painful or to cause to become less harsh or hostile.