3.4.1 Establish / Maintain Baseline Configurations

3.4.1 practice description and assessment objectives

This series reviews the top failed (misunderstood) 800-171 and CMMC requirements.

Originally posted on LinkedIn – check the start of series here for community conversation and thoughts!

3.4.1 𝐄𝐬𝐭𝐚𝐛𝐥𝐢𝐬𝐡/𝐦𝐚𝐢𝐧𝐭𝐚𝐢𝐧 𝐛𝐚𝐬𝐞𝐥𝐢𝐧𝐞 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧𝐬

This one is both commonly misunderstood and difficult to implement, even though it can be 100% a manual process.

First, the requirement language is split into two main parts: “Do you have a baseline configuration?” “Do you have a system inventory?”

Let’s talk about baseline configuration first.

A baseline configuration *at minimum* is the known good configuration of each system type.

The main reason why baselines are important for security is because the baseline is used to identify how and when a system has been maliciously modified by an attacker. An additional benefit of baseline configurations is that these records can help you rebuild your systems securely in the future if something goes wrong or you need to add capacity.

Baselines can be captured using a build checklist or procedure, an exported system config file, a series of version-controlled configuration scripts or applied policies, a version-controlled image, or by capturing a bunch of information against the system that shows how it is configured.

Share your wisdom! If you know more about baselines, or have a great tool to gather them, please comment! Microsoft tech support has an amazing script for Windows computers, but I don’t think it is publicly released. Anyone know?


Continuing the analysis of the baseline half of this requirement!

My last post talked about what a baseline is in general. But there is more to the baseline requirement.. the “includes” part.

The requirement statement as a whole is below.
𝘌𝘴𝘵𝘢𝘣𝘭𝘪𝘴𝘩 𝘢𝘯𝘥 𝘮𝘢𝘪𝘯𝘵𝘢𝘪𝘯 𝘣𝘢𝘴𝘦𝘭𝘪𝘯𝘦 𝘤𝘰𝘯𝘧𝘪𝘨𝘶𝘳𝘢𝘵𝘪𝘰𝘯𝘴 𝘢𝘯𝘥 𝘪𝘯𝘷𝘦𝘯𝘵𝘰𝘳𝘪𝘦𝘴 𝘰𝘧 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘢𝘭 𝘴𝘺𝘴𝘵𝘦𝘮𝘴 (𝒊𝒏𝒄𝒍𝒖𝒅𝒊𝒏𝒈 𝘩𝘢𝘳𝘥𝘸𝘢𝘳𝘦, 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦, 𝘧𝘪𝘳𝘮𝘸𝘢𝘳𝘦, 𝘢𝘯𝘥 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘢𝘵𝘪𝘰𝘯) 𝘵𝘩𝘳𝘰𝘶𝘨𝘩𝘰𝘶𝘵 𝘵𝘩𝘦 𝘳𝘦𝘴𝘱𝘦𝘤𝘵𝘪𝘷𝘦 𝘴𝘺𝘴𝘵𝘦𝘮 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘮𝘦𝘯𝘵 𝘭𝘪𝘧𝘦 𝘤𝘺𝘤𝘭𝘦𝘴.

Most people will read the requirement to “include hardware, software, firmware, and documentation” as part of the INVENTORY half of this requirement. But the assessment objectives require this for BOTH baselines and inventories.

Determine if:
[a] a baseline configuration is established;
[𝐛] 𝐭𝐡𝐞 𝐛𝐚𝐬𝐞𝐥𝐢𝐧𝐞 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧 𝐢𝐧𝐜𝐥𝐮𝐝𝐞𝐬 𝐡𝐚𝐫𝐝𝐰𝐚𝐫𝐞, 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞, 𝐟𝐢𝐫𝐦𝐰𝐚𝐫𝐞, 𝐚𝐧𝐝 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧; 
[c] the baseline configuration is maintained (reviewed and updated) throughout the system development life cycle;

Notice the “and” part of [b]? Plain English reading makes this sound like your baseline captures need to include all of the above: hardware, software, firmware, AND documentation, or they fail this assessment objective.

In the real world, baselines are meant to achieve the root purpose of 1) allowing you to identify if, when, and how, a system has been maliciously modified, and 2) helping you to replace or add systems in a known secure state.

Capturing manuals or sales slips (documentation?) for any product, firmware details for your cloud, or software details for your switch, generally don’t help you achieve the above root purpose of baselines.

But to pass this assessment objective [b], you need to show that you have that list accounted for.

Fun fact: Failing assessment objective 3.4.1 [b] would cause you to instantly fail your entire CMMC Level 2 assessment because it is not eligible for POA&M according to the CMMC Assessment Process, draft 1.0!

So capture 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 for each category somewhere in your baselines to show to your assessor. Hopefully you can find stuff that makes sense (identifying required firmware versions for a server, written build instructions for a SAN).

Would love to hear everyone’s thoughts on this. What documentation do you capture as part of your baseline? How do you prove [b]? Do you think the original writers meant for that list to only apply to inventories?


Time to talk about the inventory half of this requirement!

3.4.1 𝐄𝐬𝐭𝐚𝐛𝐥𝐢𝐬𝐡/𝐦𝐚𝐢𝐧𝐭𝐚𝐢𝐧 𝐛𝐚𝐬𝐞𝐥𝐢𝐧𝐞 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧𝐬 –

[d] a system inventory is established;
[e] the system inventory includes hardware, software, firmware, and documentation; and
[f] the inventory is maintained (reviewed and updated) throughout the system development life cycle

Be careful of [e] 𝘵𝘩𝘦 𝘴𝘺𝘴𝘵𝘦𝘮 𝘪𝘯𝘷𝘦𝘯𝘵𝘰𝘳𝘺 𝘪𝘯𝘤𝘭𝘶𝘥𝘦𝘴 𝘩𝘢𝘳𝘥𝘸𝘢𝘳𝘦, 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦, 𝘧𝘪𝘳𝘮𝘸𝘢𝘳𝘦, 𝘢𝘯𝘥 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘢𝘵𝘪𝘰𝘯.

📓 It is even more awkward to include documentation in your inventory list than it is for baselines. Consider linking to the completed build checklist for that system.

Firmware is also often missed. For appliances like firewalls, switches, and SANs, the firmware version is very important. The firmware version is roughly equivalent to the difference between Windows XP or Windows 10.
💻 For desktops and laptops, most assessors want to see the BIOS firmware version tracked and don’t look much further.
💿 For servers, you may choose to track versions of the iLO / iDRAC firmware, RAID controller firmware, hard drive firmware, and network card firmware. Again, most assessors won’t look much further than BIOS firmware for this requirement.

Next, ensure you have records showing the inventory is 𝘮𝘢𝘪𝘯𝘵𝘢𝘪𝘯𝘦𝘥 (𝘳𝘦𝘷𝘪𝘦𝘸𝘦𝘥 𝘢𝘯𝘥 𝘶𝘱𝘥𝘢𝘵𝘦𝘥) 𝘵𝘩𝘳𝘰𝘶𝘨𝘩𝘰𝘶𝘵 𝘵𝘩𝘦 𝘴𝘺𝘴𝘵𝘦𝘮 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘮𝘦𝘯𝘵 𝘭𝘪𝘧𝘦 𝘤𝘺𝘤𝘭𝘦. How do you do this? You could include prompts during your change management procedure to update the inventory.

If your inventory is automated (such as via a network scanning tool), changes should be time-stamped or reported regularly, so that you can show changes over time.

The main idea of [f] is that your inventory doesn’t get out of date as you add and remove components. This can be manual or automatic, just whatever you do, make sure the inventory stays accurate over ⏳.  A mean assessor may test you by selecting an in-scope device at random and asking to see if the inventory includes accurate information for it. 😱

The best implementation I’ve seen included all laptops, desktops, mobile phones, servers, network components, the list of authorized software, the list of authorized clouds, and virtual machines, in a series of inventory lists.

Would love to hear everyone’s comments about inventories.
Do you think the inventory part of this practice can be completely automated using a tool, or is there manual maintenance that needs to be performed?
What documentation would you capture in the inventory for a switch? A laptop?

Leave a Reply

Your email address will not be published. Required fields are marked *