The missing settings in DSC Security Baseline Configuration

Microsoft has created a DSC config for Windows Server 2016 but there are 19 settings missing, read this post for an overview of those settings

by | Nov 11, 2018 | Automation, General, Security

Introduction

In my previous post I explained that Desired State Config is a great way to get your (Azure) workloads compliant. During the last weeks I found out that Microsoft has introduced a new option to get Windows workloads compliant. In the operations section in the virtual machine pane there is a new option named ‘Configuration management (Preview)’. If you select this option on a Windows server, Microsoft provides the ability to deploy the ‘Windows Server security best practices’. On the information box there is a warning. “If you select the option, recommended Windows server security settings will be assigned to virtual machine. This may impact applications served by this virtual machine”. So use this option with care on existing servers. When I deployed this, I was convinced that this baseline deployed the settings that Azure Security Center checks. These settings can be found here. I found out that it indeed sets many settings that the ASC baseline expects, but not all the settings. In fact there are 19 settings missing in the DSC config that Microsoft provides. In this blog post I will explain the missing settings and how I fixed all these settings so ASC gives the expected green light on the recommendation ‘Remediate vulnerabilities in security configuration on your machines’

Configuration management

As stated before there is a new option called Configuration management (preview) in the virtual machine blade (see screenshot). After deployment of a Windows Server you can enable desired state configuration with this option. All it needs is an automation account, a log analytics work space and your preferred agent settings. Within the Desired State Configuration Management there is a option to Apply a configuration from Microsoft. This is the part were we will focus on in the blog post. After enabling the DSC it creates a log analytics work space or configures a existing work space and it links the work space to the automation account.

Default configurations

After enabling Microsoft automatically creates 5 configurations to be enabled on virtual machines with different Windows operation systems. They support:

  • Windows server 2008 service pack 1
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows server 2016

To start with I have reviewed the Windows Server 2016 baseline and created a improved version which you can upload to the automation account to get your workload compliant to the Azure Security Center baseline.

Missing settings

After a day or some Azure Security Center knows the existence of the newly deployed virtual machine and check it for the compliance of the baseline. I found out that there were 19 settings incorrect or not there in the Security Confiuration the Microsoft provides. The query to find these settings is:

 SecurityBaseline
| where Computer contains “[computername]”
| where AnalyzeResult == ‘Failed’
| summarize arg_max(TimeGenerated, *) by BaselineRuleId, Computer
| summarize count() by BaselineRuleId, Description

These settings can easily be extracted to a CSV file by using the export button in log analytics.

Ensure ‘Audit Group Membership’ is set to ‘Success’

This setting was missing in the configuration. In log analytics this setting is referred to as:  AZ-WIN-00026. Actually this line is even not in the version 4 of the MS Baseline from technet. To get compliant I have added a extra setting in the ‘AuditPolicySubcategory’ called ‘Group Membership’.

Ensure ‘Audit PNP Activity’ is set to ‘Success’

This setting was incorrect in the DSC config, it did not have the Ensure = ‘Present’. I added this setting.

Ensure ‘Audit Account Lockout’ is set to ‘Success and Failure’

This setting was missing in the configuration. This setting is referred to as: CCE-37133-6. Because it needs two settings, succcess and failure, there are two parts of settings in the DSC module needed. One for success and one for failure.

Ensure ‘Audit Other Logon/Logoff Events’ is set to ‘Success and Failure’

This setting was missing in the configuration. This setting is referred to as: CCE-36322-6. This also needs a setting for success and failure, so again two parts to be created.

Audit Other Object Access Events

This setting was missing in the configuration. This setting is referred to as: AZ-WIN-00113. This setting needs the success and failure part, just like the previous one. So two parts in there.

Audit MPSSVC Rule-Level Policy Change

This setting was missing in the configuration. This setting is referred to as: AZ-WIN-00111. Just like the previous setting it is not clear from the description what settings log analytics expects in the baseline. By expanding the result of rule ‘show more’ there is a line with the expected result. In the screenshot you can see the ‘show more’ option in the search result. 

Ensure ‘Audit Sensitive Privilege Use’ is set to ‘Success and Failure’

This setting was missing in the configuration. This setting is referred to as: CCE-36267-3. I added this settings in the baseline.

Ensure ‘Audit Security System Extension’ is set to ‘Success’

This setting was missing in the baseline. It is referred to as: CCE-36144-4. I just create the setting, just like the screenshot.

Ensure ‘Audit Process Creation’ is set to ‘Success and Failure’

This setting is incomplete in the configuration. The setting that Azure Security Center checks is Success and Failure, but the provided baseline of Microsoft only holds Success. I adjusted the settings to the correct one.

Ensure ‘Allow Telemetry’ is set to ‘Enabled: 0 – Security [Enterprise Only]’

The previous settings were all audit settings, The setting is enabled by editing the registry. The provided DSC config of Microsoft had the incorrect setting in ‘ValueDate’, it had ‘2’ but the baseline expected ‘0’. I changed this, so that was very easy.

Bypass traverse checking

When checking this setting I found out that none of the UserRightsAssignment settings where getting through in the virtual machine. After some local configuration testing I found that the ‘Force = $True’ was enabling the right settings. I adjusted all the UserRightsAssignment settings.

Ensure ‘Replace a process level token’ is set to ‘LOCAL SERVICE, NETWORK SERVICE’

The setting with CCE ID 37430-6 was incorrect, it had ‘BUILTIN\\Administrators’ in the identity settings instead of the expected result ‘NT AUTHORITY\\LOCAL SERVICE’, ‘NT AUTHORITY\\NETWORK SERVICE’ so I changed it.

Ensure ‘Shut down the system’ is set to ‘Administrators’

This setting was easily fixed by adding the force parameter.

Configure ‘Allow log on locally’

The CCE-37659-0 was missing in the Microsoft DSC config so I added this.

Configure ‘Access this computer from the network’

The setting ‘Access this computer from the network’ had the same issue as the ‘Shut down  the system’ setting the Force parameter brought the answer.

Increase a process working set

The setting ‘Increase a process working set’ also did not have the Force parameter.

PAssword settings

The last missing or incomplete settings where the password settings. The DSC module that Microsoft uses has a AccountPolicy part where you can set the prefeereed settings that Azure Security Center checks for.

onclusion

There are some settings missing or incomplete in the provided baseline by Microsoft. I have found them and corrected them. My baseline can be found on my GitHub on this URL. I hope by providing the correct baseline everyone can get their workloads compliant and secure by default.