CMMC Configuration Management Domain: Overview

Last Updated on January 12, 2024

I’ll be blunt right at the top, this is a pain in the @$$ of a requirement. Now that we got that out of the way let’s dive in. 

Why are we here? 

The Cybersecurity Maturity Model Certification (CMMC) framework breaks up cybersecurity technical controls and best practices into seventeen domains. Each domain contains capabilities, processes and practices that fall within the CMMC’s five maturity levels. US Department of Defense (DoD) suppliers must prove CMMC compliance at the maturity level their contract requires, based on the sensitivity of the Controlled Unclassified Information (CUI) they process, store, or transmit, and the cybersecurity risks they face. 

Configuration Management Domain – High Level

The Configuration Management (CM) domain focuses on defining consistent, controlled and audited configuration and change management practices, including eleven practices within two capabilities at CMMC levels 2, 3, 4 and 5. Hardware, software, databases, and even firmware must all be configured to operate securely, as specifically required for their use case. 

Keeping configurations secure and standardized is critical to eliminating vulnerabilities and reducing security risk, as well as streamlining systems management/maintenance. Assets need to be built and hardened in a consistent manner, and you need to manage all changes through a defined change control process. 

If you don’t establish configuration baselines with policies and procedures for enforcing them, you have no way to audit or measure the security of your assets. In short, a robust security posture is impossible without best-practice Configuration Management. 

For example, if your business has no Configuration Management policy for employees laptops, then differences in operating system and device configurations will negatively affect upgrades to anti-virus/anti-malware software, resulting in weakened security on many laptops and greatly increasing your risk from ransomware and other malware. 

Configuration Management Domain – The Reality for Most DIB Companies 

This is a tough practice. Essentially, as an Organization Seeking Certification (OSC) you have to have a baseline configuration, ideally for all information systems, network services, and components within your CUI/CMMC ecosystem. If you are “mature” enough to do it across your enterprise, more power to you… that is a tall task for most decent size DIB firms. 

This means it’s likely your users who touch CUI will have a standard baseline image for their endpoints; this will include (at a minimum) OS version, any added software, disabled features, services, ports, and protocols not required for the user to perform their duties or that have known vulnerabilities. To create such image and determine the configuration settings, your system administrators will need to run your OS through a vulnerability scan, addresses the vulnerabilities (critical, high, medium, etc.) and justify any vulnerabilities identified by the scanning software if these are required for the system to communicate with any services within the CUI ecosystem. 

The same, as a separate step or within, is performed with the added software. Your system admin needs to establish mechanisms to enforce these controls meaning, tools, processes, techniques, etc. to prevent changing the configuration settings (often used are GPOs, EDR software, and others).  

Once a change is made to this baseline (any change) your change management process needs to start. It needs to validate the reason for the change, the risk implications, and test the change before the change reaches production (a.k.a. touches CUI). This often mean running another vulnerability scan which flows down to create a new standard image. 

Whew… I said this one was rough. 

What are the CMMC Configuration Management Domain Capabilities and Practices? 

The Configuration Management domain practices impact all the CMMC levels except Level 1, which defines the minimum criteria for handling Federal Contract Information (FCI). There are six Configuration Management practices at CMMC Level 2, three at Level 3 (the minimum requirements for handling Controlled Unclassified Information (CUI)) and one each at levels 4 and 5. 

These eleven Configuration Management practices are fall under two capabilities: 

1. C013 Establish configuration baselines 
2. C014 Perform configuration and change management 

The six Configuration Management domain practices at CMMC Level 2 are as follows: 

• CM.2.061 Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. 
  This practice mandates that you only configure assets from a known, secure and approved baseline. This includes documenting system software and settings, specifying where an asset should be placed within your network, and/or other specifications your business requires for security. 
• CM.2.062 Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. 
  Compliance with this practice requires you to identify and remove/disable applications, ports, protocols, services and settings on your systems that are enabled by default, but are unnecessary—and therefore a security liability—in your environment. Configure your assets with only the capabilities they need to operate. 
• CM.2.063 Control and monitor user-installed software. 
  News flash: If your policies and controls don’t prohibit it, users will install random software that creates security risks both to endpoints/devices and to your overall environment. Therefore, CMMC mandates that you control what software users can install; e.g., by not giving users admin privileges on laptops. 
• CM.2.064 Establish and enforce security configuration settings for information technology products employed in organizational systems. 
  To make sure you build cybersecurity into your Configuration Management process, CMMC requires you to test, approve, document and enforce secure settings/configurations for applicable systems. Usually this means “locking down” systems to the maximum degree that still allows them to meet your business requirements. 
• CM.2.065 Track, review, approve, or disapprove, and log changes to organizational systems.
  Before you commit a configuration change to production, you need to review and approve it and then log it. Otherwise, undocumented changes proliferate and both security and reliability suffer. Regular meetings of a “change control board” are a common way to address this control. 
• CM.2.066 Analyze the security impact of changes prior to implementation.
  Your IT environment is complex, and ad hoc changes can introduce unknown risks. CMMC therefore requires you to “look before you leap” and specifically evaluate security impacts of changes. “Better safe than sorry” when it comes to defense related data. 

The three Configuration Management domain practices at CMMC Level 3 are as follows: 

• CM.3.067 Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. 
  Compliance with CMMC Level 3 mean stepping up your security game to protect CUI. One essential step involves securing your Configuration Management process itself, so unauthorized users can’t compromise it. This means ensuring only specific people can make physical and logical changes to your systems. It could involve physical access controls, special login credentials, workflow automation to enforce procedures, and more. 
• CM.3.068 Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. 
  Similar to CM.2.062 above, nonessential services weaken security by increasing your attack surface with no business benefit. CMMC Level 3 requires you to show that you’re using only the minimum resources you need to accomplish your mission. That means removing unnecessary software from servers and endpoints; setting up blacklists or whitelists to limit what software can run in your environment; and restricting unused ports, protocols and other services. Eliminating the FTP service from all your endpoints and blocking the associated ports is a common example. 
• CM.3.069 Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny- all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. 
  Following on from CM.3.068, this control directs you to create and maintain blacklisting and/or whitelisting policies so you can govern and control what software is allowed to run in your environment. 

CMMC Level 4 specifies one Configuration Management domain practice: 

• CM.4.073 Employ application whitelisting and an application vetting process for systems identified by the organization. 
  CMMC Levels 4 and 5 are designed to help protect organizations from Advanced Persistent Threats (APTs) and other sophisticated attacks. To block APTs, you need a procedure to verify that systems used for processing CUI are secure. This includes defining the steps a new application needs to go through to confirm it doesn’t harbor malicious code, and to confirm that there is a business requirement to add it to the application whitelist (see CM.3.069).

CMMC Level 5 also specifies one Configuration Management domain practice: 

• CM.5.074 Verify the integrity and correctness of security–critical or essential software as defined by the organization (e.g., roots of trust, formal verification, or cryptographic signatures). 
  At CMMC Level 5 you need a way to verify the integrity of security-critical software. Such systems may contain a Trusted Platform Module (TPM) chip. This control mandates that you configure such systems to use a secure boot process, and to authenticate security-critical applications before running them.  

What Is Needed to Comply With the CMMC Configuration Management Domain Controls?

Unless you only need to meet CMMC Level 1, the Configuration Management domain controls can present challenges and necessitate many business process changes for companies that don’t yet have formal Configuration Management policies and procedures in place and/or have a primarily cloud-based infrastructure. You may need to purchase software, such as a Mobile Device Management (MDM) solution and/or a network vulnerability scanning tool, for instance.

For people working from home, the Configuration Management domain controls apply to all devices interacting with the CUI/CMMC ecosystem, including personal devices, BYOD, etc. If you’re not already managing home networks, remote laptops and other mobile devices, you’ll need to begin doing so.  

If you’re currently NIST 800-171 compliant, or close to it, the nine Configuration Management domain controls at CMMC Level 3 are essentially identical to the controls in NIST 800-171’s Configuration Management Control Family. 

 Now What? 

Depending on factors like how reliant you are on cloud-based services, virtualization, containers, etc., how you need to implement the Configuration Management domain controls could vary significantly. There may be hundreds of decisions to make regarding secure configurations, data governance, etc. 

 If you’re concerned about how best to bring your organization into compliance with the CMMC Configuration Management domain controls, contact Pivot Point Security to connect with a CMMC expert.