NIST 800-53 Server Hardening perspective

Many organizations approach us with the request to be NIST 800-53 compliant, not fully understanding what that really means. Well, it is not their fault, as it is really easy to get lost in the NIST 800-53 recommendations and not fully understand their bottom line. But do they even have a bottom line? This article should give you a clue on what does it mean to harden your servers according to NIST 800-53.

This article summarizes NIST 800-53 controls that deal with server hardening. This summary is adjusted to only present recommended actions to achieve hardened servers. Not all controls will appear, as not all of them are relevant to server hardening.

We'll take a deep dive inside NIST 800-53 3.5 section: Configuration Management. This section contains 12 different controls (CM) dealing with the configuration management of your entire system.

We'll investigate the following CM that relates to server hardening and how:

1. CM-1 configuration management policy and procedure
2. CM-2 baseline configuration
3. CM-3 Configuration Change Control
4. CM-4 Security and Privacy Impact Analysis
5. CM-5 Access Restrictions for Change
6. CM-6 Configuration Settings
7. CM-7 Least Functionality
8. CM-9 Configuration Management Plan

NIST server hardening: Guide for NIST 800-123

CM-1 configuration management policy and procedures:

This control refers to the implementation of the rest of the controls. It is basically instructing you to establish a formal procedure for the effective implementation of the rest of the controls. You might need to develop a system-specific policy, as not all procedures are required for all systems.

 According to CM-1, you'll need to:

1. Develop, document, and distribute configuration management policy that will address and differentiate roles, responsibilities and management commitment among the organizational entities. In addition, it should consist of laws, executive orders, regulations, policies, standards, and guidelines.
2. Develop procedures to facilitate the policy and the rest of the configuration management controls.
3. Designate human resources to manage the configuration management policy and procedures.
4. Review and update both the policy and procedures on a defined frequency.
5. Ensure that procedures are done for configuration management indeed implement the policy and controls.
6. Develop, document, and implement remediation actions in case of violation of the policy.

CM-2 baseline configuration:

This control establishes a baseline configuration for each component in the system, including servers. Although it is instructed to have different configurations for each type of component, there are no specifications on what should be the desired configurations, like established in the CIS Benchmarks or DISA STIG. NIST only instructs to use documented, formally reviewed and agreed-upon set of configurations. Note also that part of maintaining baseline configuration requires creating a new baseline, as systems change over time.

According to CM-2 you'll need to:

1. Develop, document, and maintain configuration control a baseline configuration to each component type in the system, meaning that each type of server OS will need to have its own baseline. We highly recommend using known best practices such as CIS Benchmarks or DISA STIG as a base for your baseline.
2. Review and update baseline configuration at a defined frequency, when circumstances require and when servers are installed or upgraded.
3. Employ automated mechanisms to maintain an up-to-date, complete, accurate, and readable baseline configuration.
4. Establish procedures that will allow the rollback of changes in case of need.
5. Maintain different baselines for test and development environments and differentiate it from the production baseline.

The Complete System Hardening Guide

CM-3 Configuration Change Control:

Configuration change control refers to changes in the server's baseline configuration, that can be either unscheduled and unauthorized, or for vulnerability remediation purposes. Each authorized change must be reviewed and approved by authorized entities in the organization. Changes must be audited.

According to CM-3 you'll need to:

1. Determine the kind of changes to the server that are configuration controlled.
2. Proposed changes must be approved or disapproved after reviewing their impact on the server's security.
3. Document changes in server configurations.
4. After being approved, changes must be implemented in the servers.
5. The time period that changes records must be saved needs to be set by the organization.
6. Monitor and review any activity of the server that associates with the change after implementing it.
7. Use automation in order to:
8. Document proposed changes in the server's configuration
9. Notify and request approval on proposed changes from authorized entities in the organization.
10. Highlight changes that aren't yet approved or disapproved.
11. Prevent changes until they are authorized.
12. Document all changes in the system (proposed and not proposed).
13. Notify the responsible entity in your organization when an approved change in server configuration is fully implemented.
14. Test and validate changes in the server's configuration before fully implemented in production. This is especially important in the context of both the server's security and servers' outages.
15. Use automation to implement the desired changes on the servers in production.
16. Ensure that cryptographic mechanisms are also under configuration management.

CM-4 Security and Privacy Impact Analysis:

The person responsible for conducting an impact analysis should have the necessary skills and technical expertise to analyze the impact of any configuration change on your server's security and functionality. This is a very complex task as the system structure is usually very complex and in order to perform a thorough impact analysis, you should understand the dependencies in the system. Doing it manually can be prone to mistakes.

 According to CM-4 you'll need to:

1. Analyze desired changes to the server to determine potential security and privacy impact before you implement the changes.
2. Analyze the potential impact in a separate test environment before implementing the change to production. The test environment should be completely separated from the production environment.
3. Check the security and privacy functions after the changes in the server's configuration, to make sure that the functions implemented correctly, functioning as intended, and producing the desired functionality while meeting the security and privacy requirements.

Server Hardening Steps and Guide to Secure Your Server

CM-5 Access Restrictions for Change:

Unwanted changes to the server's configuration can be a result of malicious activity or un-intended everyday actions that can lead to configuration drifts. Every un-intended and malicious change can lead to potentially have significant effects on the overall security of the systems. Therefore, organizations should permit only qualified and authorized individuals to have the right privileges for initiating changes. The organization should also espier to privilege the minimal number of users to initiate changes.

According to CM-5 you'll need to:

1. Define, document, approve and enforce physical and logical access restrictions associated with changes to servers' configuration.
2. Enforce access restrictions and generate audit records for enforcement actions.
3. Review system changes in a defined frequency and defines specifications to determine whether unauthorized changes have occurred.
4. Prevent installations on the server without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.
5. Enforce dual authorization for implementing changes to server configuration.
6. Limit privileges to change configuration settings in the production environment. Review and reevaluate the privileges at the organization's defined frequency.

CM-6 Configuration Settings:

The server's Operating System 'out of the box' configurations are usually aimed for the maximum functionality of the server. That's often doesn't comply with security standards and often leaves the server open to vulnerabilities. Server configurations will establish the server's security posture and functionality. Organizations should establish a specific configuration baseline for each server OS type. For example, Windows 10 baseline will be different from Windows 16 any kind of Linux OS.

There are common configuration checklists and benchmarks developed by public institutes (such as the CIS Benchmarks) that provide recognized, standardized, and established benchmarks for specific platforms and instructions for configuring those systems components to meet operational requirements. Organizations can also develop their own policies for their servers.

Implementing a specific common benchmark may be mandated for the organization in order to stand in regulatory requirements.

According to CM-6 you'll need to:

1. Establish and document configuration settings for the server's OS using common secure configuration benchmarks that reflect the most restrictive and secure mode possible with the operational requirements.
2. Implement the configuration settings. This may sound easy, but infect implementing the configuration settings is a complex labor demanding task. As mentioned in CM-4, every change in configuration should go under impact analysis before implemented in a separate testing environment. Even after performing an impact analysis, each change in configuration can lead to damage to production and servers' outages. An automatic approach to this process can solve the majority of the pains in this issue.
3. Identify, document, and approve any deviations from the established baseline.
4. Monitor and control changes.
5. Employ automated mechanisms to centrally manage, apply and verify configuration baseline.
6. Establish and employ security measures to respond to unauthorized changes to servers' configuration settings.

CM-7 Least Functionality:

Servers' OS is provided by the manufacturer with a wide variety of functions and services. Some may not be necessary to provide servers' functionality. Using the server OS with out-of-the-box configuration settings increases the attack surface of the server. Organizations should review functions and services provided by the server, to determine which functions and services are candidates for elimination. Organizations should also employ network scanning tools, intrusion detection, and prevention systems such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, protocols, ports, and services.

According to CM-7 you'll need to:

1. Configure server OS to provide only essential capabilities and prohibit the use of unnecessary functions, ports, and services.
2. Review the system at a determined frequency to identify unnecessary and non-secure functions, ports, protocols, and services.
3. Disable any unnecessary and non-secure functions, ports, protocols, and services.
4. Ensure compliance with the organization's policy.
5. Use blacklisting to prevent the usage of unauthorized software. Make sure you review and update this list.
6. Use whitelisting to allow the usage of only authorized software. Make sure you review and update this list.

CM-9 Configuration Management Plan:

Configuration management plans should define processes and procedures for how configuration management is used to support server development life cycle activities. They are usually developed during the development and acquisition phase of the server's life cycle. The plan will establish procedures such as moving changes through change management processes, updating configuration settings and baseline, and controlling the development of test and operational environment.

According to CM-9 you'll need to:

Develop, document, and implement a configuration management plan for the server that will:

1. Address server roles, responsibilities, and configuration management processes and procedures.
2. Establish a process for identifying configuration items throughout the server development life cycle.
3. Define the configuration items for the server and places the configuration items under configuration management.
4. Be reviewed and approved by an authorized individual in the organization.
5. Protect the configuration management plan from unauthorized disclosure and modification.
6. You should assign responsibility for developing the configuration management process to organizational personnel that is not directly involved in system development.

CMMC Compliance

As mentioned in the begging, NIST 800-53 only presents 'high-level' recommendations. This is a good place to start your hardening project. In order to get more practical, it is recommended to assist in server hardening benchmarks, such as the CIS Benchmarks. Implementing automation into this process can make the difference between an endless project that is almost designed for failure in a complex enterprise IT environment, to a successful project that will help you protect your organization from common server vulnerabilities.