Windows Server 2016 comes reasonably secure “out of the box”. But it’s important to remember that while the server is reasonably secure, not every security control that is can be configured for Windows Server 2016 (and the more recently released Windows Server 2019) is enabled on the operating system when you deploy it using default settings.
In a series of blog posts I am going to discuss things that you can do to harden your Windows Server deployment, focusing mainly on the steps that you can take to harden both Windows Server 2016 and Windows Server 2019. I’ll be going through the technologies and security controls that are available in Windows Server 2016 and Windows Server 2019. One of the primary reasons that you should be running these versions of the Windows Server operating system is that they are far more secure and far better able to be made even more secure than prior version of Windows Server.
In this specific post I want to talk about third party security configuration baselines, which are guides published by organizations such as the Defense Information System Agency (DISA) and Center for Internet Security (CIS).
Third party security configuration baselines are exhaustive lists of the security controls that can be applied to a specific product. At present there are security configuration baselines published by DISA and CIS that describe the security controls that can be applied to Windows Server 2016 and Windows Server 2019.
The two most influential security baselines for Windows Server 2016 and Windows Server 2019 are:
The baselines are documents that consist of a list of security controls that you can apply to your servers. Security controls listed in baselines vary depending on the nature of the control. For example, some controls offer explicit recommendations such as that a specific service that should be configured as to be in a disabled state, such as the XBOX Live service on Windows Server, or a protocol that should be disabled, such as NTLM or SMB1. Other security controls are recommendations such as ensuring that any local Administrator accounts have their passwords updated every 60 days. Sometimes there are associated bits of PowerShell code that would allow an auditor to check whether the control is implemented.
The DISA STIG baseline provides some group policy templates that allow you to apply some of the recommended configuration. There are also people in the security community, including Microsoft MVPs, who provide Desired State Configuration configurations that implement some of the security controls listed in the DISA STIG and CIS baselines.
For those interested in starting the process of hardening Windows Server, I recommend getting copies of both the DISA STIG for Windows Server as well as the CIS security benchmark for Windows Server 2016 and performing an initial read through of what recommendations are made. Such a read through will give you a high level understanding of the lengths that you can go to when it comes to hardening Windows Server.
What you should definitely not do is try to apply each security control in a baseline such as DISA STIG for CIS to a production server right away. As you’re likely aware, Windows Server ships with many of these security controls disabled. The reason for this is that when you enable a security control, you may also disable some functionality that takes advantage of the configuration setting that the security control hardens. A good example of this is SMB1. SMB1 is an insecure storage protocol that’s enabled by default on the RTM version of Windows Server 2016 because a large number of customers still have other services on their network that require access to SMB1. Organizations that have deployed Windows Server 2016 have been encouraged to disable SMB1. Some were able to do so without problems, others found that disabling SMB1 on Windows Server caused issues elsewhere in their environment.
Baselines won’t tell you is where implementing a specific security control will break something on your network. Sometimes you’ll be able to predict whether implementing a security control will have an adverse impact on an existing workload, other times you’ll enable the security control and have to wait to see if anything happens. The only real way of being sure that implementing a security control doesn’t cause an adverse reaction is to implement it.
While optimally you’d be able to make a determination by implementing the security control in a test environment, you’ll only really know what the impact is when you turn it on in production. Simply because most test environments aren’t full and accurate representations of the ecology of a production environment. Also, be aware that any issues that might be caused by implementing a security control may not be immediately apparent. This is why you’ll need to take a gradual approach.
In a later post, I’ll go into how you can do a phased rollout of security controls in your environment. I’ll also cover how to use the Security Compliance Toolkit to assess the security configuration of Windows Server.
