.png)
This blog is the fifth in a 15-part blog series, discussing each domain in Cybersecurity Maturity Model Certification (CMMC). In this blog, we will explore the CMMC domain, Configuration Management.
The Configuration Management (CM) domain discusses establishing a process for maintaining your organizational systems, ranging from software to hardware capabilities. In addition, it involves tracking these changes and discussing policies related to CM.
We will be exploring Configuration Management in the following manner:
The focus ranges from system baselining, configuration enforcement, change management, functionality discussion, and user-installed software in the Configuration Management domain. The domain covers various topics, and each relates to how your organization should configure your systems.
Now, let's break down the individual practices to get a better understanding of each:
One of the first steps within Configuration Management is establishing and maintaining baseline configurations for your system. System baselining will include hardware, software, firmware, and the documentation of all these different types of systems, which should occur throughout each system's system development life cycle.
All baseline configurations should be documented, reviewed by appropriate personnel, and agreed upon before being established in your organization.
Baseline configurations can include information about the system components, network topology, and logical placement of your system components within the system architecture. Consistently maintaining your baseline configurations is also imperative, as your system can change over time.
All information systems and information technology products within your organization should have security configuration settings set up and maintained.
These are the set of parameters that affect the security posture of your system, and they must address any security vulnerabilities that could affect your systems.
Your organization can develop and decide these security parameters, but they must be secure and provide recognized and standardized benchmarks that reflect a stable security setting. These security parameters should be established organization-wide, and any sub-settings for specific systems can be established as needed.
Another critical requirement within the Configuration Management (CM) domain is to track, review, approve, and log any changes that may occur to your organizational systems (that are different from the baseline) to develop that idea further.
This requirement is known as configuration change control. It involves the proposal, justification, implementation, testing, and review of any changes to your systems, which can include upgrades, modifications, or new implementations.
Your organization should set up a process allowing this to happen, including approving or disapproving specific changes. Logs of all changes should be maintained, no matter how small the change might be (both before and after a change is made).
Any change should be analyzed before it is implemented in your system to determine its impact. Not all changes are beneficial to a system, and changes to complex environments such as your information systems must be reviewed for their security impacts.
Change reviews prevent unforeseen issues and decrease any security risks or vulnerabilities that may arise from the change. This is a proactive requirement and should be done before each change, no matter how minor it might seem. Allowing for safe and secure changes will prevent any impact on your organization.
Access Restrictions for change requirement focuses on defining, documenting, approving, and enforcing any physical or logical access restrictions associated with changes to your systems. Access restriction for change applies to any hardware, software, or firmware within your organization.
Your organization must only allow qualified/authorized individuals to implement changes, as it will prevent any potential mishap or security breach. The restrictions must also include access control limitations and focus on software libraries, workflow automation, media libraries, and change windows.
Depending on the nature of your organization, a system may offer a wide array of functionality and services. It puts more functions of the organization at risk because they are under one system, but it also limits services to only that one component, which can be risky. It is commonly done for efficiency and convenience.
However, your organization should employ the principle of least functionality, which is where you configure a system to provide only its most essential capabilities and functions. Your organization must review functions and services that a system provides, determine which may be plausible for removal, and disable or remove them accordingly.
Building on this, your organization should further restrict or disable the use of any nonessential functions, programs, ports, protocols, or services. If restriction or disablement is not possible, you must prevent using these. In addition, your organization can determine which files are restricted, preventing unauthorized access or use.
Your organization should implement policies that determine the use of authorized software and prevent the use of unauthorized software.
The process used to identify unauthorized software programs is known as exclude list or deny-by-exception. The opposite, which allows you to identify software authorized to be used on your system, is known as whitelisting or permit-by-exception.
Include list is the stronger policy of the two, as it focuses on what is allowed. Your organization can determine which to use, which can be a combination.
Though each organization's policies vary, users are typically permitted to install software depending on their role, access, and need.
To ensure that these installations are safe and appropriate, your organization must implement, maintain, and control the software that is potentially installed in your systems.
Your organization may determine the software that is allowed and not allowed and establish policies regarding this. Policy enforcement should include procedural methods and automated methods.
It is crucial to control the software that a user installs. Otherwise, it can create unnecessary risks or expose your system to flaws in that software. You must implement a formal approval process for any software your organization does not already allow.
We have discussed various practices in the Configuration Management Domain that all point to how your organization should manage and maintain its organizational information systems, how they should be configured, the policies and procedures surrounding this domain, and the responsibilities of your organization that are essential to consider.
For CMMC 2.0, there are no Level 1 practices for the Configuration Management domain.
There are nine practices for Level 2. Here is some guidance on what to include for audit or look for within your organization:
For CMMC Level 3, the CM practices are yet to be determined.
.png)
