Windows Server 101: Understanding Third Party Security Configuration Baselines
Published Jan 15 2019 12:01 AM 26.1K Views
Microsoft

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.

9 Comments
Silver Contributor

Can someone from MS provide reasoning behind including XBOX Live service in Windows Server SKU? Or even leaving it enabled?

Microsoft

It's not present in Server 2019 with Desktop Experience. I don't know any official reason, but if I was going to unjustifiably and wildly speculate, I'd imagine that there were some dependencies for VDI and RDS scenarios that have since been untangled.

Copper Contributor

Orin, 

Could you point me (us?) to information regarding the best methods for deploying baselines to stand alone installations? 

To clarify what I am looking for, I currently build out the settings based on reading the recommended settings from CIS and such and put them into a blank non-domain joined Windows 2016 VM.  I have then been using LGPO.exe to export these settings so I can capture them.  I can then use these as a portable method to apply these settings to VM or Physical servers. 

 

There is, however, a small notable issue with Firewall Settings.  While there is a section of the gpedit.msc that can be used to identify these settings when using LGPO.exe to backup the local GPO settings this information is missed in the LGPO backup.  I noticed this when doing an import of the settings using the same tool that these settings are not present.  I did find that I could Export manually the Firewall settings within the gpedit.msc snap-in and then import them to another machine and the enforcement would work.  Using a manual GUI process this is less than ideal.  While there is a command for importing with netsh, "netsh advfirewall import FWpolicy.wfw", this only adds settings to the current Firewall settings and does not add them as enforced Local Group Policy rules.

 

Do you know of a method to address this? Or is there a better way to have Local Group Policy configurations exported to a file that can be used to import into new builds.  I'm looking to avoid Domain-based deployments as we have multi-domain and DMZ targets that will have this applied.  I would like a command line approach so it can be scripted as a part of onboarding tasks so the deployment engineers have things as automated as possible.

-Marty 

Copper Contributor
Nevermind. It appears that an earlier version of the Windows Server 2016 RTM ISO caused this issue. I was able to get it to work now. Strange.....
Copper Contributor

Hi just an update the link https://iase.disa.mil/stigs/os/windows/Pages/2016.aspx is no longer valid

Copper Contributor

The STIGs are now available here (Windows specifically, you can unfilter to find others):

 

https://public.cyber.mil/stigs/downloads/?_dl_facet_stigs=operating-systems%2Cwindows

Microsoft

Excellent - thanks Manaz! Updated the article!

Copper Contributor

I have a 2016 Windows server that logs in with a domain account. Every few days or so it seems like it looses its connection to the Domain even though it is still connected. If you pull up computer management you see SIDs in the “Administrators Group” along with user names for domain accounts

 While this is happening I cannot RDP or C$ share into this server until I do the following

To fix this all I do is “log the user off and then back on” then everything is OK for a few days or so

 

the domain is running windows 2012 r2

 

I am not sure if this is a STIG issue or not so I have posted to here and Technet forums

Microsoft

Does it resolve the problem itself, or do you have to manually resolve it?

Version history
Last update:
‎Jul 03 2019 08:42 PM
Updated by: