Changes from the Windows 8.1 baseline to the Windows 10 (TH1/1507) baseline

[Aaron Margosis]

First published on TechNet on Nov 18, 2015

In collaboration with Windows security experts from US and UK government organizations and from the Center for Internet Security, we conducted a thorough review not just of the new settings introduced in Windows 10 but of all the accumulated settings inherited from past security baselines. Two goals of the review were to remove settings that do not address contemporary threats, and to remove the enforcement of Windows default settings that require administrative control to change and that are unlikely to be changed by an authorized administrator. The result is that we have removed 122 settings that had been enforced in the Windows 8.1 baseline that aren’t needed. We have added only 38 new settings, and have changed 9. The spreadsheet attached to this blog post lists all the changes from the Windows 8.1 and IE11 baseline to the Windows 10 (Threshold 1, a.k.a, version 1507) baseline , including updated IE11 settings.

Why aren’t we enforcing more defaults?

As mentioned, we’re enforcing defaults only for security-sensitive settings that are otherwise likely to be set to an insecure state by an authorized user. So, for example, on Windows client the User Rights Assignment, “Change the time zone” (SeTimeZonePrivilege) is granted to Administrators, Users, and Local Service. In the past we enforced that through the security baseline. Changing that setting requires administrative rights, and it’s unlikely that an authorized administrator would change it to a less-secure value. On the other hand, administrators are known to disable User Account Control, so we enforce that default.

Another reason not to enforce defaults in some cases is that it makes it harder for an organization to use a valuable Windows feature that is not enabled by default. “Offer Remote Assistance” is one such feature. It is not inherently insecure, but like many features – especially those involving network communication – it is disabled and should be disabled if it’s not used. But when security guidance says to disable it and that guidance is enforced through mandatory Group Policy settings, an enterprise choosing to use the feature often has to fight compliance auditors, Group Policy administrators, and other security experts and bureaucracies to enable it. Many will misinterpret the purpose of that element in the guidance to infer that “Offer Remote Assistance” opens a gaping hole and that if you enable it you may as well outsource your entire IT management to the criminals.

Including more settings in the baseline also increases cost of configuration, testing, validation, and maintenance. The security baselines aren’t intended to defend all secure default settings against compromise by a malicious actor that has already gained administrative rights. There are approximately 3.71 bajillion values in the registry that should never be messed with and that would cause havoc if messed with. While it may be worth monitoring them to ensure that they haven’t been altered, it’s not practical to enforce them all with a configuration baseline, and not really what the configuration baseline is for. As an example, someone could modify the registry value HKLM \ System \ CurrentControlSet \ Services \ LanmanServer \ DefaultSecurity ! SrvsvcShareAdminConnect and grant Everyone “full control” through the administrative shares (e.g., C$, ADMIN$). We could add that registry value to the baseline and ensure that Group Policy sets it back to its default, and using a similar mechanism, periodically verify that it hasn’t been altered. But if we go down that path, the baseline will quickly become unmanageable as we enforce defaults throughout much of HKLM\Software, HKLM\System, and the file system.

Removed settings

This section summarizes some of the 122 settings that went from a configured value to “Not Configured.” For many of these settings, such as Windows Update settings, specific configuration is best left to the organization. For others, organizations can continue enforcing settings, but we do not consider their enforcement to be necessary.

• 
  

  Windows Firewall, “Allow location connection security rules” and “Allow local firewall rules” for the Domain and Private profiles.

  
  


• 
  

  The MSS settings, AutoAdminLogon, SafeDllSearchMode, ScreenSaverGracePeriod, and WarningLevel. (We also redefined the ancient MSS settings from Security Options to a custom ADMX for supportability reasons.)

  
  


• 
  

  “Configure Offer Remote Assistance”

  
  


• 
  

  BitLocker: removed the requirement for smart cards and the prohibition on passwords, enforcements of defaults on hardware encryption, enforcement of specific recovery options, and disallowing use of BitLocker in the absence of a TPM.

  
  


• 
  

  Internet Explorer settings requiring ActiveX Filtering, disabling geolocation and AutoComplete for forms, control of browser history and proxy settings, unneeded settings in the “Locked Down” security zones, and a couple of settings that became not-applicable after Windows XP but survived past purges of old controls.

  
  


• 
  

  Specific Windows Update settings.

  
  


• 
  

  The security option, “Accounts: Block Microsoft accounts.” If this setting is enforced, Cortana won’t work.

  
  


• 
  

  Security options to shut down the system if a security audit fails to log, control who can “format and eject removable media,” display of last user name at logon, password-change notifications, and numerous others.

  
  


• 
  

  Enforcement of Ctrl+Alt+Del at logon to protect credentials from theft. This is not particularly strong protection. First, it depends on a user that’s looking at a spoofed logon screen remembering that he or she hadn’t pressed Ctrl+Alt+Del before typing a password. Second, so many apps prompt the user for the same credentials on the user’s desktop that the credentials can easily be stolen there. Third, if the adversary has gained administrative control of the computer, the “secure desktop” is no longer a protected space. Finally, with devices offering more keyboard-free logon experiences such as facial recognition, Ctrl+Alt+Del becomes an annoying interference.

  
  


• 
  

  The UAC setting to switch to the secure desktop is redundant with the recommended UAC settings for elevation prompt behavior.

  
  


• 
  

  Explicitly denying batch and service logon to the Guests group.

  
  

New settings

This section summarizes the 38 net-new settings that were added to the Windows 10 baseline that weren’t in the Windows 8.1 baseline.

• 
  

  Two new Advanced Auditing settings that were introduced in Windows 10, and auditing removable storage events.

  
  


• 
  

  Enabling local password management through the Local Administrator Password Solution (LAPS). Note that LAPS requires an Active Directory schema extension.

  
  


• 
  

  Two MSS settings that were not configured before. (They are probably both very low risk.)

  
  


• 
  

  Hardened UNC paths for the default shares on domain controllers.

  
  


• 
  

  Prohibit connecting to non-domain and domain networks at the same time.

  
  


• 
  

  Disable Wi-Fi Sense.

  
  


• 
  

  Enable Credential Guard.

  
  


• 
  

  Block another type of DMA device that can be used to bypass BitLocker protections.

  
  


• 
  

  Block GDI from handling untrusted fonts. GDI’s font parser executes in kernel mode.

  
  


• 
  

  Disallowing AutoPlay and AutoRun.

  
  


• 
  

  Additional EMET protections ( EMET 5.5 , currently in beta)

  
  


• 
  

  More consistent and complete enforcement for SmartScreen in IE and Edge.

  
  


• 
  

  Disallow password manager in Edge (to be consistent with IE settings)

  
  


• 
  

  Encrypt RPC traffic.

  
  


• 
  

  Do not store domain passwords in credential manager.

  
  

Changed settings

This section summarizes the 9 existing settings that have changed since our Windows 8.1 baseline:

• 
  

  Advanced auditing setting for “Security State Change” was “Success and Failure.” The default is just “Success,” and it turns out there is no code path in Windows that can log a Failure event for a security state change, so we are now enforcing “Success”.

  
  


• 
  

  Disabling display of firewall notifications for the Domain and Private profiles. It’s generally not useful to display complex and confusing error messages to users, particularly when they can’t do anything with them. Leaving the default in place for the Public profile – if a user sees a firewall notification there, they should probably contact an administrator.

  
  


• 
  

  Disallowing custom, per-computer firewall rules for the Public profile.

  
  


• 
  

  Continuing to deny write access to removable drives not protected by BitLocker, but no longer disallowing write access to devices configured in another organization.

  
  


• 
  

  Fixed minor misconfiguration in “Show security warning for potentially unsafe files” in the Internet and Restricted Sites zones.

  
  


• 
  

  Allowing only Administrators to authenticate to the computer’s network interfaces such as SMB shares and RPC. Note that this does not apply to Remote Desktop.

  
  

Win81-to-Win10TH1-Diffs.xlsx