The Complete Guide for Server Hardening

By Keren Pollack, on January 13th, 2020

Windows Server ships with a default configuration that is designed to strike a balance between security and compatibility, allowing most applications to work without any changes to server security settings. But while Windows Server is designed to be secure out-of-the-box, it requires further hardening to protect against today’s advanced threats.


Microsoft recognizes the need to harden Windows Server and provides a set of security best practice recommendations for different platforms, like Windows 10 and Windows Server.


The process of server hardening for achieving a good security posture of your servers is complex and highly prone to mistakes. Therefore, we believe that implementing automation in the hardening process is essential. 

This blog post will first cover basic practices for securing a Windows server:

  1. Using the CIS Benchmarks
  2. Auditing CIS benchmarks in Windows Server
  3. Best practices for setting remediations
  4. Monitoring configuration changes
  5. Generating reports showing the security status of your servers

When necessary, you’ll see how the popular scripting language PowerShell can help with some of these tasks.


Using the CIS Benchmarks

The Center for Internet Security (CIS) also provides its own security benchmarks for Windows Server to help safeguard systems, software, and networks against today’s evolving cyberthreats. Each CIS recommendation references one or more controls that were developed to help organizations improve protection against cyberthreats. CIS controls map to frameworks like PCI DSS, HIPPA, ISO 27000, and others.


The CIS benchmarks are divided into Level 1 and Level 2 security settings to help organizations implement them. Level 1 settings are considered the minimum requirements to which every system should be configured, and they aren’t likely to cause application compatibility issues or interrupt service. Level 2 settings are recommended for systems that need better protection and where some reduction in functionality might be accepted.


CIS Level 1 and Level 2 hardened images for Windows Server are available in the Microsoft Azure Marketplace, Amazon AWS Marketplace, Google Cloud Platform, and Oracle Cloud Marketplace. You can try to apply CIS benchmark settings to Windows Server in your own environment or to an existing image by using CIS Build Kits. They are available to buy and contain Group Policy Objects (GPOs).

Alternatively, you can download the settings for Windows Server in PDF format from CIS here and create your own GPOs.


CIS Benchmarks -What are They and How to Use Them

Auditing Windows Server Security Settings

Understanding how your servers are configured is the first step in making sure that they are appropriately secured. A common tool server configuration discovery is PowerShell. But using PowerShell alone won’t work well because not all settings are registry-based. Furthermore, automating a ‘gap analysis’ comparison of the current configuration of your servers with the CIS benchmarks requires more complicated code.


Account Policies

The first set of recommendations in the CIS benchmarks for Windows Server are settings for account policies, like Enforce password history and Maximum password age. If you have an Active Directory domain, these settings are configured in the Default Domain GPO and are propagated to all domain-joined devices, assuming an out-of-the-box domain configuration. The Get-ADDefaultDomainPasswordPolicy PowerShell cmdlet can be used to audit domain password settings but it does not audit the setting configured on each endpoint.

Similarly, there is no documented registry key to set Enforce password history or other account policy settings. Using the secedit tool in Windows is the only simple way to programmatically audit account policy settings.


Auditing Registry-Based Settings

Settings that are backed by a registry key are easier to audit. For example, the Allow indexing of encrypted files setting for Windows Search is set in the HKLM hive of the system registry using the AllowIndexingEncryptedStoresOrItems value. HKEY_LOCAL_MACHINESearch:AllowIndexingEncryptedStoresOrItems.

By default, the Allow indexing of encrypted files setting is disabled and the AllowIndexingEncryptedStoresOrItems value doesn’t exist in the registry. Disabled is the recommended CIS benchmark setting for Windows Server.


If the value of AllowIndexingEncryptedStoresOrItems is 1 (true), then indexing of encrypted files has been enabled. A zero value (false), indicates that indexing has been explicitly disabled. If the value doesn’t exist in the registry, PowerShell will return an error.


All settings backed by a documented registry key can be audited in the same way. For example, AllowCloudSearch is backed by the following value in the registry:



The policy should be set to Enabled: DisableCloud Search and results in the AllowCloudSearch value being set to zero. The default setting in Windows Server is Enabled: Enable Cloud Search but there is no registry value present out-of-the-box because it isn’t required.


Remediating Windows Server Security Settings

Using the previous code examples, you will need to manually compare existing server settings with the CIS benchmarks. A fully-automated solution could be used to continually monitor servers to ensure that they are in compliance with the CIS benchmarks.


Before remediating a setting, make sure that you have a record of the current value and have tested reverting it. Some settings require a reboot before they take effect and Microsoft usually documents this information as part of the related Group Policy setting.


Whenever you change settings on a production system there is the potential to cause outages or compatibility issues with line-of-business applications. Any changes should be tested in a pre-production environment and made with a rollback plan. This can be a time-consuming process and is best automated using a product that can determine whether configuration changes might introduce operational issues on production systems.


Monitoring Changes to Windows Server Configuration

Using PowerShell, the best you can hope for is to audit settings and then automate comparison with the CIS benchmarks. This could be triggered on a daily or hourly basis. But a product that is able to monitor changes in real-time and automatically remediate settings provides a more secure solution.


Regardless of whether an organization has implemented a change control process, unwanted changes can still occur to server configuration. If security best practices for managing Active Directory are not followed, it’s easy for unwanted changes to occur either intentionally or accidentally. Malware can also be responsible for modifications to server settings.


Where there is no change control procedure in place, configuration drift happens over time. Configuration drift leads to servers that deviate from their intended configuration, leaving them in an unknown state. Unknown configurations make support harder and the risk of compromise greater.


Mitigating risk Microsoft server

Risk mitigation should be your first choice in your Microsoft server cybersecurity strategy


Auditing and the Windows Event Log

Because there isn’t a uniform way of auditing settings configured by the CIS benchmarks for Windows Server, monitoring changes can be challenging. Windows Server auditing, the built-in technology in Windows Server for monitoring changes to server configuration, can be configured to monitor registry keys.


Global Object Access Auditing is a way to configure Windows Server auditing that makes it easier to set up auditing. You can use Global Object Access Auditing to set security access control lists (SACL) per server rather than on each part of the registry that you want to audit. But you still need to know what to look for in the Event Log, extract events that indicate a change to specific registry values, and then alert someone to the change.


Alerting features in the Windows Event Log are basic. It is possible to trigger a script when a new event is received in a custom view. But beyond that, the Windows Event Log doesn’t provide the comprehensive alerting capabilities found in third-party SIEM products.


Real-Time Monitoring

There are free tools for monitoring the registry. The most well-known is Microsoft’s Process Monitor. But like the Windows Event Log, setting up Process Monitor to effectively track changes to CIS benchmarks is difficult and it doesn’t scale well in enterprise environments.


Tracking changes to settings that don’t have documented registry settings can be done by exporting the local security database using secedit and then comparing before and after values. You can use PowerShell to create objects from the text files exported by secedit and then use arrays to compare the information. For more information on how to compare data in PowerShell arrays, read Comparing arrays with PowerShell. Alternatively, an automated tool that tracks before and after values would be needed to monitor changes to these settings.

CIS controls and how to approach them

Generating Reports on Windows Server Configuration

Regardless of how you decide to monitor server configuration, that information needs to be analyzed. While PowerShell can be used to generate reports, it requires some expertise to make them readable and useful.


Generating reports from text-based files isn’t always straightforward, like from files generated by secedit. Although it’s worth noting that you can process information with PowerShell using theImport-Csv cmdlet, and files that use delimiters other than a comma by adding the Delimiter parameter.


Third-party products can help you to generate reports without needing to code and to compare data to see what has changed over time.


Formatting reports making them easy to read is also important. For example, you could export Windows Event Log security events to an HTML file by piping the results of Get-EventLog into ConvertTo-HTML like this:

Get-EventLog -LogName “Security” | ConvertTo-Html > c:\temp\securityevents.html


PowerShell also has some filtering capabilities, making it possible to display only specific information in your reports. The code below uses Get-EventLog to extract events from the Application log that were generated by Outlook. The results are piped to the Where-Object cmdlet to further filter the results by including only events where the EventID is 63.


Finally, Select-Object is used to format the results in a table displaying only the Source, EventID, InstanceId, and Message properties for each event.

Get-EventLog -LogName Application -Source Outlook | Where-Object {$_.EventID -eq 63} | Select-Object -Property Source, EventID, InstanceId, Message


Using PowerShell to generate HTML reports is possible but to have complete control over how your reports look, some experience in working with HTML and Cascading Style Sheets (CSS) would be required.

Do you need to automate report generation using built-in Windows components? If so, you’ll need to set up scheduled tasks. You could set up an automated task to run a PowerShell script on a schedule. But managing scheduled tasks centrally can be a challenge and ensuring that tasks run successfully also needs to be monitored.



Using the CIS benchmarks to secure Windows Server can significantly improve security posture. But to ensure that servers remain secure, you need to constantly audit configuration and automate the remediation of changed settings.

PowerShell is a handy and free tool to audit and remediate settings and produce reports on server configuration. But PowerShell requires a level of expertise and time commitment to implement an end-to-end solution to secure Windows Server. If you want the “easy button”, a third-party tool specifically designed for this purpose may be a better option.