Configuration Management (CM) a challenging Domain within the Cybersecurity Maturity Model Certification (CMMC) and contains no Level 1 requirements. The Domain consists of 11 Practices (6-Level 2, 3-Level 3, 1-Level 4, and 1-Level 5) . Requirements cover the management of system devices, hardware, software, and network components for least functionality and change control. To meet Level 3, a company will find the nine included Practices within Level 2 and 3 are the same Controls in the Configuration Management Control Family within NIST 800-171. There are no wording changes from NIST 800-171, but the order within CMMC is slightly different.
Configuration Management is a Domain focused on controlling the threat vectors within your organization for the greater protection of FCI and CUI. The major motions within the domain are shown in the image below: establishing baselines across the enterprise, tracking and reviewing changes, and conducting configuration and change control over those baselines.
As discussed in the following Level by Level breakdowns, Microsoft or another cloud vendor may be meeting some of these requirements on behalf of your company and environment by the way they manage their physical media at the data center. Feel free to read on or you can watch a video synopsis here.
CM.2.061 - Establish and maintain baseline configurations and inventories of organizational system (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.
Two components make up this practice:
- Foundational asset management to record what devices are within your environment, along with their owners and dependencies
- Baseline configurations for building/deploying new system components, updating or maintaining those components, and how to review changes in the environment.
Going beyond user endpoints and SaaS and PaaS, companies are required to create a documented and controlled baseline for their servers, virtual machines, networks, and virtual networks. Azure, for example, can provide guidance in the Azure Security Center for all of your resources and highlight vulnerabilities. You may be alerted to implement Distributed Denial of Service (DDoS) Standard protection on Virtual Networks to guard against DDoS attacks or Azure Application Gateway for web applications with HTTPS/SSL enabled for trusted certificates. Azure Policies and Azure Blueprints can also serve as standardized template for deploying certain resources the same way every time.
FAQ: Does this practice and others in CM apply to home computers or BYOD in the growing age of remote work? Yes, and meeting all of Level 2 and Level 3 CM practices will be difficult if not impossible using unmanaged laptops and unmanaged home networks.
CM.2.062 - Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.
Least functionality applies to user devices and device applications, as well as systems and system hardware. The former is mostly addressed by limiting the user's ability to download any software without approval. However, in the situation of Platform as a Service (PaaS) like Microsoft 365, users can potentially access multiple pieces of software with a single license type and use those applications across multiple devices without ever installing anything onto a machine. Also, many of the default provisioned settings are not aligned with least functionality. Many IT leaders are surprised to uncover that external sharing is turned on automatically for example when an M365 tenant is provisioned, SharePoint Online HubSite is created, and SharePoint Teams Site or Communications Site is created.
Therefore least functionality in Microsoft 365 expands into governance decisions:
- Should users be able to share files from Teams/SharePoint/OneDrive to other users within the organization? Trusted partners? Anyone with a Microsoft Account?
- Who can create Microsoft Groups? Microsoft Teams teams (confusing we know)? Should users be able to create teams? Should users be able to download files from Teams or only read/edit?
- Should users have access to workflow and automation tools like the Microsoft Power Platform?
- Should users be able to access Teams, SharePoint, or Outlook on their mobile device?
- Should users have the ability to copy and paste text from a managed application into another non-managed application?
- The list goes on. That is why Summit 7 configures 100's of settings and administrative policies for all CMMC Level 3 Implementations.
It is wise to conduct some form of Change Control Board (CCB) or rely on an MSSP to meet with some regularity to review new features and software added to your respective PaaS or Software as a Service (SaaS).
For physical or virtual servers and networks, a network scanning and host-based vulnerability scanning tool(s) will be necessary. There are hundreds of options, but Nmap, Angry IP, and Wireshark are some of the more widely used free/open source tools for assessing the network and scanning for vulnerabilities across ports and devices on network. For Azure, Microsoft provides a native and free vulnerability scanner in the Azure Security Center, and it is powered by Qualys. Unfortunately, this is not available yet in Azure Government, but you can deploy Qualys' Gov Platform as a separate tool to run similar scans of the environment. Rapid7's Nexpose product is another great tool for this, but it is unclear if Azure Government is supported and this product is not FedRAMP certified.
CM.2.063 - Control and monitor user-installed software.
There are two moments where this practice is most evoked:
- At the time a user or admin looks to install software AND
- When a user or admin looks to update/patch said software
More than any other practice within Configuration Management (CM), this practice ties most directly to your company's need for a System Security Plan (SSP) or NIST 800-128 calls out a CM Plan. The appendix for 2.064 calls out artifacts a Certified Assessor would look for during a CMMC audit, and all of them would likely exist in an SSP: security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides, etc.
- Identify and Document All Systems Containing or Handling CUI
- Identify and Document All Endpoints on Each System
- Identify and Document All Configurations and Settings for Each Endpoint
FAQ: If an IoT device is connected to the company's public wireless network, can these devices be considered 'Out of Scope'? In terms of an audit, these devices may be considered "Out of Scope" as long as they don't authenticate against your internal infrastructure and they don't touch CUI. However, the public network would be included in the company's systems makeup and should be assessed on a regular basis to make sure devices containing CUI are not accessing that network. If the IoT device needed to connect to the private or managed network, it too would need to be assessed and configured properly.
CM.2.065 Track, review, approve, or disapprove, and log changes to organizational systems.
Whereas the last practice encouraged the creation of an SSP, this practice draws on the need for a board(s) to review and decide on changes throughout the environment. CMMC calls out "Configuration Control Board" and "Change Advisory Board", but it doesn't matter what you call the group. The likely work breakdown structure for most companies will allocate the internal IT team or external MSP to conduct most of the 'tracking', and the internal IT and security teams or external MSSP will perform some of the initial reviewing.
The review process does not need to take place at the weekly/monthly/quarterly board meeting. An effective change or configuration control board will assess the findings of the MSSP's review for example, impact on various stakeholders and user groups, and the suggestions of technical teams. Because the board may consist of non-technical stakeholders, the members should be able to make an informed approval or denial without thoroughly reviewing patch logs and vendor documentation.
There is no regularity or frequency requirement, nor a predetermined set of individuals needed to conduct an advisory board. The major requirements for this control board:
- Include stakeholders across the organization where applicable
- Address "unscheduled and unauthorized" changes (this would be the most easily missed requirement in CM)
- Keep all notes, minutes, and archived board documentation in a secure location with similar treatment as you would CUI, as they will include potentially sensitive details about your environment
Grounds for approval and disapproval will range from company to company and case by case. Approvals might not always be technical and direct causation (if we do 'A', it will create specific security issue 'B'). A company might for instance disapprove the request to deploy a subset of MacOS devices in their environment because it would introduce the need for additional policies and software to be purchased/managed. Another example would a company not approving a subset of users wanting to use a new Microsoft 365 workload, such as Power Apps, because the organization may lack the resources/expertise to configure or manage it properly.
CM.2.066 Analyze the security impact of changes prior to implementation.
NIST 800-128 makes a larger emphasis on maintaining a detailed "inventory" and running analysis in a checklist fashion across your inventory. Depending upon staffing, it is optimal to consistently assign testing for a specific system component to the same resource. For example, an administrator or security analyst could be assigned to mobile devices and device management policies. It is impossible for a single individual to test all endpoints and system software for each change across the enterprise, unless the organization consists of five members.
Security impacts by scenario can vary:
- To allow a user set to use a specific software will require them to have elevated privileges on their devices
- The new HR system will require SSO and direct access to AAD
- The company is hiring X amount of new employees and needs to implement a new badging system
Test devices and test environments are critical for this practice. MSP's can provide additional value by informing your CCB of impacts other users are having across their several accounts when a similar change was made.
CM.3.067 Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
Physical access considerations need to be given to server rooms or locations where critical system components in your inventory are stored. If you 'own' that location, then key cards or security systems with active monitoring could do the trick. Cloud providers similarly will need to follow FedRAMP Moderate or higher standards and implement least privilege access to make changes. Microsoft for instance only provides just in time access to make changes on your physical servers and hardware.
Logical access control can also be controlled in cloud PaaS and SaaS environments. For example, Microsoft 365 and Azure Government changes can be made with tight controls through AAD's Privileged Identity Management (PIM) capabilities. PIM allows you to time-bound access, require justification or approval for privileged role assignments, and send notifications to a specific account when certain roles are activated along with theaudit history.
Microsoft's TJ Banasik also wrote a great overview of Configuration Management in Azure Government you may find helpful, and it includes an application of PIM and Role Based Access Control (RBAC).
CM.3.068 Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
This practice is a continuation of 2.062 and the concept of least functionality. The only difference is that the appendix and additional discussion introduces the need to whitelist or blacklist, which leads to the final Practice for Level 3.
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.
Whitelisting is the best practice for many reasons explained elsewhere on the web, but it is a Level 4 requirement. Regardless, your team can deploy varying technologies to control what applications can launch from your endpoints and how they execute. Windows 10 and Windows Server machines can be controlled by Windows Defender Application Control (WDAC) for example, and WDAC deployment can come from Intune, Configuration Manager, or a PowerShell script. A list of WDAC rules are provided here and a complete lift from Microsoft Docs:
- Attributes of the codesigning certificate(s) used to sign an app and its binaries;
- Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file;
- The reputation of the app as determined by Microsoft's Intelligent Security Graph;
- The identity of the process that initiated the installation of the app and its binaries (managed installer);
- The path from which the app or file is launched (beginning with Windows 10 version 1903);
- The process that launched the app or binary.
Similar tools can be deployed for Linux machines, MacOS and iOS devices, etc.
For a video synopsis of this blog, watch the below session from a recent CS2 conference.