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.
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.
The following are three controls from the NIST recommendations. The rest will be presented in the second part of this article.
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
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.
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 change 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.
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
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 to 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.
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.
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
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.
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.
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:
CalCom’s Recommended Value:
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.
To continue reading: