In January 2020 the Department of Defense (DoD) published the Cyber Maturity Model Certification (CMMC) framework to assess and enhance the cybersecurity posture of the Defense Industrial Base (DIB). According to the DoD, every prime and subcontractor on a supply chain must be audited and certified by the CMMC model. This requires special adjustments made by the companies involved in this supply chain but will help the DoD to avoid future loss due to cyber breaches.
NIST 800-171 provides federal agencies with a set of security controls for protecting Controlled Unclassified Information (CUI). This set of controls aims to govern CUI in nonfederal information systems and organizations. In other words, NIST 800-171 contains a set of standards that defines how to protect and distribute information that is sensitive, but not classified.
Originally, when NIST 800-171 was launched, the DoD did not accept any kind of 3rd-party evidence for compliance. But now that the CMMC is out, that is basically what they demand. The CMMC was created to treat the issue of non-NIST 800-171 compliance.
In this article, we aim to compare CMMC and NIST 800-171 controls that have to do with server hardening. We'll present the control according to NIST 800-171, CMMC level that is required to comply with this control, and examples for hardening actions that must be performed to address it. We provide this information since hardening can be a time and effort-demanding task with the potential to cost a lot both in Dollars and in damage to the organization’s infrastructure. CalCom offers a fully automated solution for hardening, saving the need to perform lab testing and minimizing the chances for production damage. Click here to learn more about our solution.
The following are the relevant controls from the NIST recommendations:
- Establish and maintain baseline configurations
- Employ the principle of least functionality
- Establish and enforce security configuration settings
- Limit system access
- Monitor and control remote access sessions
- Employ cryptographic mechanisms
- Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
CMMC Baseline Hardening Requirements Compared to the CIS Controls
| Control Number | CMMC Level That Must Comply |
| 3.4.1 | 2-5 |
| 3.4.6 | 2-5 |
| 3.4.2 | 2-5 |
| 3.1.2 | 1-5 |
| 3.1.12 | 2-5 |
| 3.1.13 | 3-5 |
| 3.4.7 | 3-5 |
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.
CMMC levels required to comply: Level 2-5
Control description:
This requirement establishes baseline configurations for systems and system components including communications and connectivity aspects of systems. Baseline configurations are documented, formally reviewed, and agreed-upon sets of specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, servers, network components, etc; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture.
Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration.
Example:
This control can be divided into two main parts: establishing baseline configurations and maintaining baseline configurations.
Establishing baseline configurations:
You must determine what is your hardening policy. Your hardening policy will determine how your servers will be configured, according to their role, version, and environment. Finding the balance between security and functionality is the main challenge of this issue, as they are often incompatible. The hardening process requires a delicate balance between them.
A firm security policy may sound like a good idea, but it must take into consideration the means available to apply it. Setting a policy that is impossible to implement will lead the project to a dead end.
Maintaining baseline configurations:
Investing efforts in proper hardening is not enough. Ongoing monitoring and maintenance are required as the production environment constantly changes and new vulnerabilities are discovered.
To properly maintain a hardened infrastructure, you'll need to implement structured procedures for:
- Policy updates- which usually occur once a year, according to best practices updates and new vulnerabilities being discovered.
- Change management- There should be a formal process when hardening actions are being performed, from authorization to documentation. Limiting the number of users that are privileged to perform such changes is a key factor in preventing configuration drifts.
- Compliance checks- Compliance posture must be tracked. Any change can indicate new exposures to vulnerabilities or attacks that are currently taking place in your organization.
- Knowledge management- Conserving information about what changes were made, where, and when, is crucial. Most organizations using GPOs for hardening don't do this. As a result, all relevant knowledge is possessed by the IT staff member who is responsible for this matter. Once that staff member leaves the organization, no one knows what actually happened in the system and why certain decisions were made.
CMMC Baseline Hardening Requirements Compared to the CIS Controls
3.4.6 - Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities
CMMC levels required to comply: Level 2-5
Control description:
Systems can provide a wide variety of functions and services. When used with 'out of the box' configurations, some of the functions and services may not be necessary to support essential organizational missions, functions, or operations.
Using these system's properties may allow high functionality of the system component, but doing so increases the risk for those components being leverages in an attack.
Where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services provided by systems or components of systems, to determine which functions and services are candidates for elimination.
CMMC Baseline Hardening Requirements Compared to the CIS Controls
Organizations must disable unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of devices, transfer of information, and tunneling. Organizations can utilize network scanning tools, intrusion detection, and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services.
Example:
When determining the least functionality policy to a system component, you must address three issues:
- Determining the right policy according to the component's role– as mentioned above, the organization should espier to limit component functionality to a single function. For example, the mail server will have different configurations than the web server. Although established on the same operating system (OS), each OS must configure according to the expected functions of the server.
- Determining the right policy according to the component's environment– a server in a Dev environment will need different functionalities and will be exposed to different risks than a server in a production environment.
- Determining the right policy according to the component's version– Windows Server 2012 has different properties than Windows Server 2019 and may contain different vulnerabilities.
Before implementing the different policies, you must perform impact analysis to make sure the security measures you've decided to take, won't harm your production. In order to do so, you must test the policies in a test environment that illustrates your production as accurately as possible. This process is long, complex and prone to mistakes.
After testing your policies' impact, you need to implement the right policy on the right component. It is usually done by using manual tools (such as GPOs), which also makes it prone to mistakes.
We recommend using professional help when setting the policies and automated tools for testing and implementing the policies. Since this process is tangled, relying on manual work will make this process long and costly.
3.4.2- Establish and enforce security configuration settings for information technology products employed in organizational systems
Level required to comply: Level 2-5
Control description:
Security configuration settings are parameters impacting the security state of system components such as servers, workstations, firewalls, operating systems, etc. security parameters include, for example, registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. The established security settings become part of the systems configuration baseline.
Example:
Rule Name:
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.
Rule Description:
This policy setting allows administrators to enable the more precise auditing capabilities present in Windows Vista or later.
The Audit Policy settings available in Windows Server 2003 Active Directory do not yet contain settings for managing the new auditing subcategories.
Default Value in WS 2008-2019:
Not Defined
CalCom's Recommended Value:
Enabled
Why?
Prior to the introduction of auditing subcategories in Windows Vista, it was difficult to track events at a per-system or per-user level. The larger event categories created too many events and the key information that needed to be audited was difficult to find.
The individual audit policy subcategories that are available in Windows Vista are not exposed in the interface of Group Policy tools. Administrators can deploy a custom audit policy that applies detailed security auditing settings to Windows Vista-based client computers in a Windows Server 2003 domain or in a Windows 2000 domain. If after enabling this setting, you attempt to modify an auditing setting by using Group Policy, the Group Policy auditing setting will be ignored in favor of the customs policy setting. To modify auditing settings by using Group Policy, you must first disable this key.
Note: Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable either success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events generated can make it difficult to find other types of entries in the Security log. Such a configuration could also have a significant impact on system performance.
3.1.2- Limit system access to the types of transactions and functions that authorized users are permitted to execute
Level required to comply: Level 1-5
Control description:
Organizations should define access privileges or other attributes by either account, type of account, or combination of both. For example, privileges may be defined by individuals, groups, system, guest / anonymous, temporary, etc.
Attributes that require authorized access include time-of-day, day-of-week, and point-of-origin. In addition, organizations may consider defining account attributes by system-related requirements (system maintenance and updates), and mission or business requirements (time zone difference, customer requirements, etc.).
Example
Rule name:
Deny log on as a service
Rule Description:
This security setting determines which service accounts are prevented from registering a process as a service. Note: This security setting does not apply to the System, Local Service, or Network Service accounts.
Default value for MS 2008, 2012, 2019:
No One
CalCom's recommended policy:
Guests; Anonymous Logon
Why?
Accounts that can log on as a service could be used to configure and start new unauthorized services, such as a keylogger or other malicious software. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative privileges can install and configure services, and an attacker who has already attained that level of access could configure the service to run with the System account.
3.1.12- Monitor and control remote access sessions
Level required to comply: Level 2-5
Control description:
Remote access allows access to organizational systems by users communicating through external networks (e.g., the internet). Automated monitoring and control of remote access sessions allow organizations to detect attacks and maintain compliance with remote access policies. Auditing and controlling connection activities of remote users is required on a variety of system components such as servers, work stations, etc.).
Example:
Rule name:
Allow Remote Shell Access
Rule Description:
This policy setting allows you to manage the configuration of remote access to all supported shells to execute scripts and commands.
Note: On Server 2012 (non-R2) and newer, due to design changes in the OS after Server 2008 R2, configuring this setting as prescribed will prevent the ability to add or remove Roles and Features (even locally) via the GUI. We, therefore, recommend that the necessary Roles and Features be installed prior to configuring this setting on a Level 2 server. Alternatively, Roles and Features can still be added or removed using the PowerShell commands Add-WindowsFeature or Remove-WindowsFeature in the Server Manager module, even with this setting configured.
The default value for WS 2019:
Enabled. (New Remote Shell connections are allowed)
CalCom's recommended value:
Disabled
Why?
Any feature is a potential avenue of attack, those that enable inbound network connections are particularly risky. Only enable the use of the Windows Remote Shell on trusted networks and when feasible employ additional controls such as IPsec.
CMMC Baseline Hardening Requirements Compared to the CIS Controls
3.1.13- Employ cryptographic mechanisms to protect the confidentiality of remote access sessions
Level required to comply: Level 3-5
Control description:
Implement cryptographic standards that include FIPS-validated cryptography and NSA approved cryptography.
Example:
Rule Name:
Allow unencrypted traffic- WinRM Client
Rule Description:
This policy setting allows you to manage whether the Windows Remote Management (WinRM) client sends and receives unencrypted messages over the network.
Default Value in WS 2019:
Disabled (The WinRM client sends or receives only encrypted messages over the network).
CalCom's Recommended Value:
Disabled
Why?
Encrypting WinRM network traffic reduces the risk of an attacker viewing or modifying WinRM messages as they transit the network.
3.4.7- Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.
Level required to comply: Level 3-5
Control description:
Restricting the use of nonessential software (programs), prohibiting auto-execute, program blacklisting and whitelisting, or restricting the number of program instances executed at the same time. The organization makes a security-based determination which functions, ports, protocols, and/or services are restricted.
Example:
Service Display Name:
Telnet
Service Name:
TlntSvr
Default Value in WS 2008-2012:
Not Defined
Default Value in WS 2006:
Disabled
CalCom's Recommended Value:
Disabled
Why?
The Telnet service supports connections from various TCP/IP Telnet clients, including UNIX-based and Windows-based computers. Telnet Server for Windows provides ASCII terminal sessions to Telnet clients. Telnet Server supports two types of authentication and supports four types of terminals: ANSI, VT 100, VT 52, and VTNT.
Telnet also allows a remote user to log on to the system and run console programs by using the command line.
Any service or application is a potential point of attack. Therefore, you should disable or remove any unneeded services or executable files in your environment. The Telnet service in WS 2008 is vulnerable to buffer overflow attacks, which could allow attackers to execute arbitrary code remotely via crafted packets (CVE-2015-0014)
Important: If you enable additional services, they may depend on other services. Add all of the services that are needed for a specific server role to the policy for the server role that it performs in your organization.
