Those working in the US DoD Industrial Base (DIB) who also handle Controlled Unclassified Information (CUI) are required, via DFARS clause 252.204-7012, to implement the 110 cybersecurity safeguards outlined in NIST SP 800-171. As DIB members look to implement NIST SP 800-171 and prepare to receive a Cybersecurity Maturity Model Certification (CMMC), they likely encounter safeguard requirements – aka “controls” – that require additional interpretation to implement correctly. One control of note that has been the source of confusion for Totem clients requires implementing “security configuration settings”. In this post, we explore the security configuration settings requirements and offer recommendations for you to consider as you build your CMMC-compliant cybersecurity program. We also provide a downloadable checklist your organization can adopt to help you manage security configuration settings on your devices.
A closer look at the security configuration settings in NIST and CMMC
The single requirement for implementing “security configuration settings” is found in the Configuration Management family, NIST control 3.4.2 (CMMC practice CM.L2-3.4.2):
“Establish and enforce security configuration settings for information technology products employed in organizational systems.”
Security configuration settings are associated with the concept of system “hardening”, which NIST defines as “a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services.” In other words, removing services or capabilities that a device may not need reduces that device’s “attack surface” – i.e. adversarial points of entry or compromise. As indicated in our Totem Top 10, we consider system hardening to be a “basic” cybersecurity safeguard. By this we mean hardening should be part of any organization’s cybersecurity program, regardless of industry or size. And we use “hardening” in a figurative sense; we’re not saying you need to invest in ruggedized computers built for classified military missions in austere conditions. (Although we admit, those computers are way cool!).
However, the NIST definition of hardening we presented above doesn’t quite capture the spirit of what NIST is asking for in control 3.4.2. So let’s look at another NIST definition, this time for “configuration settings”:
“The set of parameters that can be changed in hardware, software, or firmware that affect the security posture and/or functionality of the information system.”
This is more like what NIST is asking DoD contractors to do when it comes to hardening: configure hardware, software, and firmware parameters in such a way to create a better security posture. An example of a security parameter is password length – we all know the longer the password, the better. So why not force the use of long passwords to gain access to a device? An administrator can configure, for instance, a WiFi router to require long passwords prior to a device being allowed on the WiFi network.
Any IT component – whether it be a WiFi router, a laptop, a server, a firewall, whatever – will offer at least half a dozen configurable security-related parameters. Some components – such as a laptop running the latest version of Windows – will have hundreds of configurable parameters. The bad news is that most vendor products do not come hardened “out of the box”. Take Windows 10 for example. The default installation of Windows 10 needs to be as flexible, or “loose” as possible, so it may operate in multiple operating scenarios and across several workstations and laptop platforms. Thus, many of the configurable security parameters are not set by Microsoft.
Most technology vendors take this same approach to the default security configurations of their products. This is understandable as vendors want to make their product as easy to use as possible, and some security configurations can affect functionality. So, it is up to us to set the security configurations as we implement the technology. Therefore, you can think of security configuration settings as a sort of checklist of things to do to make a given IT component more secure (and comply with CMMC).
So how do you know which devices you should harden? Read on!
Which devices require security configuration settings?
For compliance purposes, the answer to this question is pretty easy – all “in-scope” components should be hardened. This means that if an IT component is used to support the processing, storing, transmission, or protection of your organization’s sensitive information, like CUI, it is in-scope and should be hardened. Unsure what sensitive information you are handling? You’ll need to determine this before you begin hardening your systems so you know what’s in scope.
When it comes to DoD contracting and CMMC, there are two types of sensitive information: Federal Contract Information (FCI) and the aforementioned CUI. (CUI is actually a subset of FCI.) For FCI, the law requires us to implement a set of basic cybersecurity protections. Those protections (controls) make up the CMMC Level 1 requirements and are included in the NIST 800-171 standard. One of those NIST controls – 3.14.1 – requires us to “Identify, report, and correct information system flaws in a timely manner.“ Totem Technologies contends that an IT component that has not had some basic security parameters configured has not been hardened, and is therefore “flawed”. Following this logic then, all your IT components that handle or protect FCI must have security configuration settings applied or be considered flawed. Flawed means not compliant with CMMC Level 1. And since CUI is a subset of FCI, this means all components that handle or protect CUI must also be hardened.
“Ok,” you say, “then as a DoD contractor basically all my IT network devices must be hardened. But you tell me some components can have hundreds of security parameters…how am I to know which parameters I must configure, and which are optional?” Great question, and the answer, unfortunately, is: it depends. Luckily, however, we can rely on trusted sources to provide guidance. In the next section we discuss how to determine which security configuration settings your organization should establish.
Which security configuration settings should my organization implement for CMMC?
So, you’ve identified your organization’s IT components that require hardening, and now you’re ready to start configuring those security parameters. But how do you know what parameters to configure? As we stated above, it depends, but luckily many IT vendors as well as several industry groups provide publish guidance on this topic. There is a sort of hierarchy to this guidance, so we present to you, in order of precedence, which sources you should look to when putting together hardening checklists for your organization:
- Vendor hardening guides
- CIS Benchmarks or DISA SRG / STIG
- “Roll your own” hardening checklist
In the following subsections we’ll elaborate on each of these sources for hardening guidance.
Vendor hardening guides
Many technology vendors publish guides or checklists that instruct administrators in how to securely configure (and use) a product once it has been installed. For example, here are some vendor hardening guides for well-known firewall/router products:
- FortiNet FortiGate firewalls
- SonicWall Advanced setup guide
- Meraki MX Best Practices guide
Importantly, these products also frequently have checklists to engage “FIPS mode” in a product, which is crucial for those of us using encryption technology to protect CUI at rest or in transit. For example, here’s SonicWall’s FIPS Mode checklist: https://www.sonicwall.com/support/knowledge-base/how-to-enable-the-fips-mode-checklist/210701195557547/.
Probably the most ubiquitous IT components are Microsoft Windows endpoints – desktops, laptops, and servers (both virtual and physical). Microsoft knows its products have been widely adopted, and so has established security “baselines” to provide organizations with more granular control of their security configurations. These baselines are provided in the form of Windows Group Policy Objects (GPO), which are essentially big spreadsheets containing configuration settings for Windows. Microsoft bundles these hardening GPOs with some analysis and automation tools in its Security Compliance Toolkit. Using the Security Compliance Toolkit, a small business IT administrator can do the following:
- Compare their current security configuration states with Microsoft-recommended GPO baselines.
- Manually edit the recommended GPO baseline to match their operational need.
- Store their restructured baseline to a GPO backup.
- Apply them organization-wide through Active Directory or individually through local policy.
The Security Compliance Toolkit consists of the following:
- Baselines for the following products:
- Windows 11
- Windows 10
- Windows Servers
- Microsoft Office
- Microsoft Edge
- Various Tools, including
- Policy Analyzer tool that can be used evaluate the current security configuration settings
- Local Group Policy Object (LGPO) executable that can be used to apply GPOs directly to an endpoint
The image below shows the Policy Analyzer used to compare a Windows 10 laptop’s current configuration settings to those in the Microsoft Baseline and the DISA STIG (more on STIGs below):
Hardening a Windows endpoint with a GPO baseline can be done very efficiently as opposed to executing a manual checklist. Furthermore, these baseline security configuration settings can be tailored to specific operational needs and conditions, including changing CMMC requirements. Check out our Knowledge Base post for more on using the Security Compliance Toolkit to harden Windows.
It’s quite easy to get carried away hardening a device and adversely affect functionality. In some cases, you can lock a device down so tightly that it essentially becomes useless. You’ll want to start your hardening activities by searching online for vendor hardening guides. Vendors know best what security settings to configure on their products, and which settings could adversely affect performance.
Unfortunately, however, some vendors don’t provide hardening guides. In those cases, we’ll look to third parties to provide guidance. The two most well-respected hardening guide providers are the Center for Internet Security (CIS) and the Defense Information Systems Agency (DISA). Let’s briefly explore what they have to offer.
CIS Benchmarks and DISA SRG / STIG
CIS provides hardening guides — which it calls “Benchmarks” — for various technologies. Benchmarks exist for the following technology categories:
- Operating Systems,
- Server Software,
- Cloud Providers,
- Mobile Devices,
- Network Devices,
- Desktop Software,
- Multifunction Printers/Copiers/Scanners, and
- DevSecOps Tools
These Benchmarks, provided free of charge, can be downloaded in PDF format. An organization can manually convert the PDF guides into a checklist format – perhaps a spreadsheet or table. Or the organization can pay for a CIS SecureSuite® membership, which provides access to a whole suite of tools and services for analyzing and automatically applying the Benchmarks; similar to, but much more extensive than the Microsoft Security Compliance Toolkit.
DISA provides its own technology hardening guides, which it calls Security Requirements Guides (SRG, for general technology categories, such as Layer 2 Switches) or Security Technical Implementation Guides (STIG, for specific products, such as Cisco IOS). SRG / STIGs are required to be applied to US DoD-owned IT system components in Unclassified and Classified environments alike. But DISA makes these guides available for download, for free, to the general public. Note, however, that the guides are quite comprehensive and are published in an obscure XML format only viewable by specialized tools, such as the DISA-provided STIG Viewer. The STIG Viewer is nice in that it can be used to create and execute a hardening checklist.
DISA also provides Benchmarks that can be used with Security Content Automation Protocol (SCAP) compliant tools to automatically analyze the security configuration settings of a device against the STIG. Kindly, DISA also provides a SCAP tool, aptly name the SCAP Compliance Checker (SCC).
In general, even though they’re free, due to the complexity of DISA products, we don’t recommend small businesses in a DFARS / CMMC compliance environment look to STIGs as security configuration settings guides. SRG / STIGs also tend to be “overkill”, locking down the environment so tightly that performance can be affected.
If your business depends on a technology product whose vendor doesn’t provide a hardening guide, and for which CIS or DISA don’t provide third-party guidance, you can “roll your own” security configuration settings checklists and still comply with CMMC. You’ll just need to be very thorough in documenting how you derived your hardening guide. Let’s explore some general best practices you’ll want your guide to address.
"Roll your own" hardening guides
Let’s say you have an IT component for which there just isn’t any vendor or trustworthy-third-party hardening guidance. A common example of such a technology is a residential-grade router. Many small businesses operate out of a home or small office environment where a residential-grade router is used to provide access to the Internet. (Often these routers are connected directly to an Internet Service Provider (ISP) modem, and they often provide Wi-Fi access as well).
Although there are likely security configurations that can be applied to the device, the router vendor probably hasn’t taken the time to publish a hardening guide. CIS has no guidance for small routers such as these at all. DISA does publish a general Router SRG, but the guidance contained therein will look like Greek to most small business IT administrators. (For instance, one of the SRG’s suggested configurations is as follows: “The MPLS router with RSVP-TE enabled must be configured with message pacing or refresh reduction to adjust maximum number of RSVP messages to an output queue based on the link speed and input queue size of adjacent core routers.” lolwut?) In this case, if we are going to use this router securely, we must make our own hardening guide.
What follows are some minimum best security configuration practices for any IT component. Some of these options may not be available for all IT components, but we’re suggesting you should at least check if they are, and if so, make the change. Many of these settings will be applicable even on a residential-grade router. Click each item to read more about it. To illustrate why these configurations are important, we provide an analogy: actions you’d take to secure your home. In cases where the security configuration setting also satisfies another NIST 800-171 and CMMC requirement, we indicate so. We’ve also developed a checklist with these hardening suggestions, which you can download here.
In many cases, the first login to a device uses a username and password supplied by the manufacturer. If you can’t change the default username, at least change its password. And while you’re at it, make the password loooooong…
Anyone in the world can find these credentials on the Internet, so if you don’t change them, it’s like leaving a key to your house under the front porch mat. That’s the first place an intruder is going to look.
(Helps to satisfy NIST 800-171 control 3.5.9)
This feature should be available on any IT component, whether it’s a simple residential grade router, or a complex server operating system. The first thing you should do after you login to a network connected component (after changing the default credentials, of course!) is trigger it to update itself.
Not doing so would be like living in an apartment with a broken front door lock—you’d ask the landlord to fix that lock, wouldn’t you?
(Helps to satisfy NIST 800-171 controls 3.11.2 and 3.11.3)
The default account in most IT components has the highest privileges possible, to allow you to setup the device as you see fit. Once the setup is done, you should create a second, non-privileged account for the day-to-day activities.
Otherwise, it would be like only having one master key that opens everything in your home—front door, back door, garage, bedroom, bathroom, closets, safe, you name it. Most of us have different keys for different areas of our homes, depending on the sensitivity of that area.
(Helps to satisfy NIST 800-171 controls 3.1.5, 3.1.6, and 3.1.7)
Services like telnet, HTTP, FTP, and RDP either don’t require credentials, or the credentials are transmitted across the network in plaintext (unencrypted). Another example is the misleadingly named Wi-Fi Protected Setup (WPS) “push button” feature available on Wi-Fi routers. Turn this “feature” off.
Leaving these services running is like adding additional unlockable doors and windows to your home; just more unnecessary points for intrusion.
(Helps to satisfy NIST 800-171 controls 3.4.6 and 3.4.7)
For the very few services you must leave open on a device – such as HTTPS for a web interface into a router, or remote access protocols for your IT maintenance technicians – make sure only authorized devices in authorized locations can access them. Furthermore, don’t allow Internet-based devices access to internal hosts. For example, if your router has a web-based management interface, be sure to check that this interface is only available to devices inside your network, not those on the outside, i.e. the Internet. Same with Windows Remote Desktop Protocol (RDP).
Not controlling access to services is like allowing doors to open in weird and potentially dangerous locations — like having a door to the bathroom open directly to the backyard. Or even worse, like living in a rough part of town and leaving your front door wide open.
(Helps to satisfy NIST 800-171 controls 3.4.7, 3.13.6, and 3.14.6)
MFA, which requires you to prove who you are in two (or more) different ways, is one of the most powerful cybersecurity practices available. Here’s a post with an example of how to do this in a Windows environment. Not all IT components will support MFA, but you should enable it where you can.
Most of us have both a handle lock and a deadbolt on our outside doors, each requiring a separate key. We do this for a reason. MFA is the same concept applied to IT.
(Helps to satisfy NIST 800-171 controls 3.5.3 and 3.7.5)
Whitelists are preferred as they only allow authorized software to execute and deny all others; blacklists, a less effective secondary method, deny specific software and allow all others. Either way, you’re exerting some sort of control over what software is allowed to run on the device, instead of making it a free-for-all.
It’s the same with your home when you’re hosting a party – you may use a peephole in the front door to check before opening the door to allow in an expected guest (whitelisting). And you’d certainly kick out any unwanted guests if you discovered them in your home (blacklisting). It should be apparent that using the peephole is easier in the long run than leaving the door open and kicking out the riffraff later.
(Helps to satisfy NIST 800-171 control 3.4.8)
Network time synchronization not only facilitates proper device and network function, it also allows you to correlate the actions of an intruder over time. NIST offers a free time synchronization source.
Imagine if your home alarm system kept the wrong time – it may not trigger an alert to the authorities if it can’t properly connect to the Internet or cell phone system. And if you came home from vacation to find your home broken into, you wouldn’t know where to start looking on the camera recordings.
(Helps to satisfy NIST 800-171 control 3.3.7)
Where encryption is used to protect information, disable weak encryption algorithms such as DES, MD5, and WEP, and use stronger ones such as AES, SHA-256, and WPA2.
Weak encryption is like not putting shades or blinds on your bedroom windows — anyone outside can easily see what’s going on inside!
(Helps to satisfy NIST 800-171 controls 3.1.13, 3.1.17, 3.1.19, 3.5.10, 3.8.6, 3.13.8, 3.13.10, and 3.13.11)
If your laptop, mobile phone, or backup USB stick gets lost or stolen, and your drive isn’t encrypted, anyone (including the bad guys) can access the sensitive data stored thereon. So you should encrypt the drive. Windows has a free native tool for this: BitLocker.
Imagine you’re on a road trip vacation and you leave your RV unlocked at a busy national park campground while you go on a long hike. The bored teenagers from the next campsite over will have a field day in your camper. You don’t want that.
(Helps to satisfy NIST 800-171 controls 3.8.6, and 3.13.11)
Segmentation refers to the process of dividing a network or device into multiple parts, to make it more difficult for an adversary to move “laterally” throughout if they gain a foothold. One of the simplest ways to achieve this is by configuring a guest network through your home/business router, and to restrict guest network access only to the Internet. When a visitor is on-site, have them connect to your guest network instead of your corporate network.
On a workstation, you can partition the hard drive, and allocate separate spaces to the operating system vs. the data. You can also ensure the logical separation of different user account folders and files (Windows does this automatically, in fact). In this way, if the operating system or a user account is compromised, it’s more challenging for the intruder to get to the juicy data they’re looking for.
When your in-laws are in town, you probably have them stay in a guest room. (Maybe you even have them stay in a local hotel.) You love them, but it’s good to have some buffer space between them and you, right?
(Helps to satisfy NIST 800-171 controls 3.13.1, 3.13.3, and 3.13.5)
Endpoint protection is important in its own right, but it should be considered as part of the hardening process. If the device supports (or comes with) an antivirus software, ensure that it is enabled and regularly scanning for threats. The antivirus vendor may also have a hardening guide of their own.
Endpoint protection is like installing an alarm system within your home. When a bad guy is trying to break in, you need to 1) know about it, and 2) take action to keep them out!
(Helps to satisfy NIST 800-171 controls 3.14.2 and 3.14.5.)
Continuously Monitoring the security configuration settings
So now that you know about some security baseline sources, you’re ready to start building checklists and hardening your system components. Once you’ve applied the security configuration settings, you’ll also need to periodically review that the security configuration settings are still intact. Doing so will ensure the bad guys stay out of your important stuff.
As you can imagine, hardening even a small business’ small set of IT components is time-consuming. So for a small business, checking the settings monthly is probably not feasible. Shoot for quarterly, or annually at the outside. This is all part of the “care and feeding” of an effective cybersecurity program, or what’s known in the industry as “continuous monitoring”.
CMMC demands that you document your continuous monitoring activities. At Totem, we track our hardening activities in our IT ticket tracking system. We also maintain a Continuous Monitoring Plan so that we know who is responsible for each activity and can plan a schedule. Check out our Continuous Monitoring post if you need more information on documenting your organization’s hardening activities. You can download a Continuous Monitoring Plan template as well.
Wrapping Up
This post touches on the basics of implementing security configuration settings for CMMC compliance. Unfortunately, there isn’t a single plug-and-play device to effectively harden even one Windows workstation, let alone an entire organization’s infrastructure. Instead, satisfying the NIST controls requires a comprehensive strategy of cataloging in-scope components, identifying hardening guides for those components, and using analysis tools and/or checklists to apply the security configuration settings.
If you need help hardening IT systems to protect your organization and comply with CMMC, we can help. If you’d like to know more about how security configuration settings relate to CMMC compliance, grab a seat in one of our Workshops! Or, drop us a line, we’re happy to chat about this stuff.* And don’t forget to download our Hardening Checklist below.
Good Hunting!
–Adam
* By the way, if your organization handles Classified Information under the National Industrial Security Program (NISP) we also offer a Classified System Hardening service. We’ll harden your Classified workstations, printers, and backup media for you, and provide an Administration guide so you can keep the devices in good standing with the DoD. Ask us about this service!
