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?