CMMC Section 3.4: Configuration Management

Configuration management is vital, both within the CMMC framework and in general from a security and IT perspective.

Configuration management ranks right up there with incident response, even though plenty of people don’t think of configuration management as a security process. They consider it a business process. But as you’ll see, configuration management is essential.

Read on to discover where you’re doing things correctly, where you have gaps, and how this directly impacts both your security posture and your ability to pass CMMC audits.

Table of Contents:

What You Need to Know About CMMC Configuration Management
Section 3.4.1
Section 3.4.2
Section 3.4.3
Section 3.4.4
Section 3.4.5
Section 3.4.6
Section 3.4.7
Section 3.4.8
Section 3.4.9
Your Guide to CMMC Compliance Success

Don't want to read the article? Watch the full recording below. Be sure to register here for the Cybersecurity for the Rest of Us webinar series!

What You Need to Know About CMMC Configuration Management

Configuration Management falls under section 3.4, with nine individual practices to consider.

3.4.1

3.4.1: Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.

Your first Family Control starts with baseline configurations and inventories. You can look at this in many ways: Some folks stick to baseline configurations and then monitor those configurations while others work off hardware and software inventories. A mature organization does both.

The point is that you need to have something.

You can manage things via a “gold image,” the term we use across multiple industries. If you take a computer, load it with whatever software you want your employees to have, and then take an image of that computer, you can restore and obviously lay down an image to any new PCs that you buy. This is your gold image. You’re going to have some frequency at which you update that image, and the update becomes your new gold image that rolls out.

As far as configuration management is concerned, the important thing is to use software that notifies you or prevents configuration changes. For example, you could generate a report that says a number of files and folders have changed, or that new pieces of software showed up, or that someone tried to make a change. The software helps you prevent these actions and then sends a notification to the approval body to ask, “Do you allow these deviations from your baseline?”

You have to consider permissions because rogue software and hardware can be installed and implemented. Someone could attempt to put a piece of software on a computer, or a rogue access, wireless access point, or access device on your network.

3.4.2

3.4.2: Establish and enforce security configuration settings for information technology products employed in organizational systems.

You must establish and enforce security configurations and settings for your organization and the products that you deploy, using things like hardening guides for operating systems and web browsers.

The military uses Security Technical Implementation Guides (STIGs) as their guides. Anybody who’s worked with the DoD knows that when you take their gold image that has the STIG applied and you apply it to a workstation, it’s locked down and hardened to a point that it becomes almost useless.

This is why you want to have something that’s at least a hardening guide. You probably aren’t going to go to the level of STIG, but you must find a happy medium in between.

Look at other things, too, such as registry settings, accounts, file and directory permissions, ports, protocols, and remote connections. Don’t focus solely on an operating system, a web browser, or a piece of software. Look at your environment holistically.

3.4.3

3.4.3: Track, review, approve or disapprove, and log changes to organizational systems.

By now you’ll appreciate that configuration management is intertwined with change management. When you talk about tracking, reviewing, approving, disapproving, and logging changes, you’re talking about the “how” of doing something, which is change management.

You might use a Change Control Board or a Change Advisory Board to first meet with your stakeholders to discuss and present your changes and then get approval from the board members.

There are many ways you can do this, but the idea behind them all is that you choose one approach. You should document who can do what, how they do it, when they do it, and so on. Then answer some vital questions:

1. Where do we store all this stuff for future use?
2. How do we review it after the fact?
3. How do we audit it?
4. How do we provide it to a CMMC auditor as evidence that we are maintaining compliance?

3.4.4

3.4.4–Analyze the security impact of changes prior to implementation.

If you make a change, only to realize a week later you need to roll it back … where do you get that information? All of this needs to be considered.

This is where a Security Impact Analysis (SIA) comes into play. You don’t necessarily have to go out and buy specialized software or spend a lot of money, but it does take time to:

• Create it
• Get your business to approve it
• Dedicate individuals who are going to maintain it after the fact.

Your goal is to get as much information in front of security as possible. The impression that a lot of folks have is that security is the ultimate decision maker of whether something happens. But this is a misunderstanding. Security is there only to evaluate and present risk, allowing the business to make accurate decisions around whether they want to accept the risk, try to mitigate it (or partially mitigate it), or not inherit that risk and go a different route.

3.4.5

3.4.5: Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

This CMMC Family Control is harder to implement because there’s not a lot of information provided by NIS. It’s a very short practice and one that speaks mainly to how you’re segregating and who can implement changes.

How are you segregating your environment from a security perspective, for example? If you use only a single environment, such as a production environment, you may not have physical and logical segregation of the environment itself. You may have just a DMZ. But if you have multiple environments, and if you’re developing software, you have two environments: nonproduction and production.

Ideally, as you work up through the stack, you have different people reviewing, making changes, and implementing.

The concept here is that you logically and physically segregate so that you have separation of duties and least privilege. Maybe someone can promote all the way up through nonproduction, for example, but to go to production, it requires someone else (and vice versa).

Anywhere you can segregate your network, whether that’s logical or physical, do. Every time you do so, you add a few more administrative headaches, but you also boost your security significantly. And this is one of those areas where security should carry more weight.

3.4.6

3.4.6: Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.

Consider the job or role of each device. Servers are a great place to start. If you’re a small organization that needs a DHCP server, you also need a domain controller, and maybe a vulnerability scanner. You may have a beefy enough piece of hardware or virtual hardware that you can run all three of these jobs or capabilities or roles on the one device, which means you keep costs and administration down. You have only one device to patch, one device to pay for, and one to administer and maintain.

But your problem with this approach is that you aren’t segregating roles and capabilities.

Because you combine them, you have a difficult time with least privilege and least functionality, because more people are likely to have to touch or use that server in some capacity. You have more pieces of software involved that can introduce vulnerabilities. If compromised, you’re not just being compromised on your vulnerability scanner host. You’re now being compromised on your main controller and more.

The job of the folks who have to administer this and ensure that security is implemented and being followed becomes far more difficult, because you have consolidated your hardware. This becomes a business risk decision.

3.4.7

3.4.7: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.

Most organizations have an idea of what they want to do and a plan for doing it. But when you do a vulnerability assessment, are your plans being properly implemented or maintained?

For example, do you have services and functions that aren’t in use but are also not disabled? You can load up a server, install a bunch of software on it, and, by default, a bunch of services are running. But do you have any idea if you’re using them, or if you even need them? If you aren’t using them, they should be disabled or uninstalled.

Do you have ports and protocols open because your logic is, “If I leave them open, I can make sure I don’t break anything in the environment”? But then, you may have hundreds if not thousands of these protocols and ports open that you’re not using: Are they now another attack vector?

Are you denying or allowing by default for network equipment? A lot of your rules and policies for networking appliances, security appliances, and so on, could be set to “Deny All,” and you then manually specify what’s allowed. (Or you can allow all and manually deny.) Most vendors, by default, especially on the networking side, require you to decide what to allow, with everything else being an automatic deny.

3.4.8

3.4.8: 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.

A blacklist or deny list is a process that stops you from installing unauthorized software. If someone tries to install unauthorized software, the process checks the blacklist and prevents it.

A whitelist or permit list, on the other hand, specifies what you allow. Whitelisting is the stronger of the two policies for restricting, according to NIS. Whitelisting is powerful because you’re actively including what you want to be allowed, instead of being taken unaware by something you didn’t know to exclude or block.

For instance, if someone decides to install the latest video conferencing software, it may not yet be on your blacklist, and would slip through.

But if your whitelist allows only Zoom, Teams, and WebEx for video conferencing, you needn’t be concerned with how many organizations come out with similar software, or with how many vendors exist in this space. It doesn’t matter what anyone tries to install, because if it isn’t on your whitelist, it won’t meet your criteria—so it will be blocked.

Your whitelist will be a much smaller list to manage than a blacklist, and it should also equate to virtually a copy of your software asset inventory.

3.4.9

3.4.9: Control and monitor user-installed software.

You need policies that govern what software is allowed and what’s prohibited, but you also need to document these policies. Your users need to know the process for requesting software, what they’re allowed to do, what they cannot do, and so on. This not only helps reduce policy violations but provides a mechanism for upholding it.

You also need to look at permissions to determine if you have a problem with user-installed software. If you have people with local admin privileges, for example, then it doesn’t really matter that no one’s in the network admin group or CIS admin group and active directory, because they already have local admin privileges.

So, do you have a good handle on local admin? With every additional piece of software brought into your environment, that’s one additional program or piece of software that has to be patched, updated, checked for vulnerabilities, and maintained. You must monitor end of life, end of service, and more.

Adding software to your environment may be great for one user, but it could give you five additional tasks that you as the administrator or security professional are now responsible for. With each one of these, consider both the security repercussions and the business implications. Present these in the most unbiased manner that you can, and then present the risks and your recommendations to whoever the person or group or board or people are in the organization who ultimately make the decisions.

Your Guide to CMMC Configuration Management Success

Configuration management is one of the most vital tasks within the CMMC framework (and from a security and IT perspective).

Follow these nine CMMC Family Controls and you will make your environment more secure, experience fewer surprises, and be in a better position to pass your CMMC audit.