By Keren Pollack, on September 2nd, 2020

In January 2020 the Department of Defense (DoD) published the Cyber Maturity Model Certification (CMMC) framework into asses 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.

 

CMMC, NIST 800-171, and server hardening- Part 1

 

In this second part of the article, we aim to continue the comparison between CMMC and NIST 800-171 controls that have to do with server hardening:

 

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.