Microsoft is pleased to announce the release of the security configuration baseline settings for Windows 10 version 1607, also known as “Anniversary edition” and internally as “Redstone 1”. The downloadable attachment to this blog post includes importable GPOs, tools for applying the GPOs, custom ADMX files for “pass the hash” mitigation and legacy MSS settings, and all the settings in spreadsheet form. It also includes spreadsheets generated from Policy Analyzer that show differences from past baselines and brief descriptions of the reasons for the differences, and a similar spreadsheet listing the differences between the Member Server and Domain Controller baselines.

Download the content here: Windows 10 RS1 and Server 2016 Security Baseline

The .CAB files corresponding to these baselines for the Security Compliance Manager (SCM) are being worked on and should be available for download through SCM by the end of October. In the meantime, the downloadable materials on this blog post should provide most everything you need to move forward. We are also preparing an updated version of Policy Analyzer and hope to publish it soon. [Update, 17-Nov-2016: the SCM CAB files corresponding to these baselines are now published. Install and start SCM v4.0 on an internet-connected system: it will notify you that the new baselines are available if it is configured to check for updates automatically, or you can select “Check for updates” from the File menu.]

The main changes in the Windows 10 v1607 baseline since that for Windows 10 v1511 include:

• Windows Defender is recommended for enterprise use and important Defender settings are now part of the Windows baseline.
• Enforcing the blocking of use of SSL 3.0 and out-of-date ActiveX controls in Internet Explorer.
• Disabling the Mobile Hotspot feature, which non-admins could otherwise enable.
• Improvements in auditing settings.
• Change in User Rights Assignment so that administrators can choose to enable Remote Desktop.
• Continued removing unnecessary enforcement of defaults, consistent with our previously-documented philosophy.

In addition to those, the Windows Server 2016 Member Server baseline removes settings for the Microsoft Edge browser that were in the Windows Server 2016 Technical Preview 5 baseline, as Microsoft Edge is no longer present in Windows Server.

To assist with evaluation, we have built spreadsheets listing differences between the latest baselines and previous baselines, along with explanations for the differences. Download here. The spreadsheets with “Raw” in the file name includes detailed information about the differences; the ones with “Explanation” in the file name removes detailed columns such as raw registry value and data type, and adds a “Reason for difference” column. The differences captured are between:

• Windows 10 v1511 (TH2) to Windows 10 v1607 (RS1)
• Windows Server 2012 R2 to Windows Server 2016 – Member Server
• Windows Server 2012 R2 to Windows Server 2016 – Domain Controller
• Windows Server 2016 TP5 to Windows Server 2016 RTM – Member Server
• Windows Server 2016 Member Server to Domain Controller

For those who have used the Local_Script tools in the download packages for previous baselines, we’ve changed its implementation. We used to copy GPO artifacts such as registry.pol files into the Local_Script directory and rename them. This time, the scripts reference the GPO files in their original locations. Because all GPO backup directory names are GUIDs, it can be difficult to identify which GUID is associated with which GPO. To help, we have added a simple PowerShell script that maps the GUIDs in a GPO backup directory hierarchy to the corresponding GPO names. This screenshot demonstrates:

Lots of updates to Policy Analyzer in this unsigned, pre-release preview build — please post comments here to let me know how well it addresses your needs and what else it could add.

Download here: PolicyAnalyzer.zip

Please see the description of the original Policy Analyzer here for context.

Partial list of improvements:

• Uses localized text correctly in most instances instead of US English.
• Option to specify different directory for Policy Definition (ADMX) files.
• Option to display explanation text with settings.
• PowerShell scripts to split or merge Policy Rules files.
• Better mapping to policy paths.
• Option to show GPO names without GPO file paths.
• Added support for REG_QWORD values.
• Cleaner, less-noisy output.

[Primary authors: Dan Simon and Nir Ben Zvi]

The Windows operating system includes many system services that provide important functionality.  Different services have different default startup policies:  some are started by default (automatic), some when needed (manual) and some are disabled by default and must be explicitly enabled before they can run.  These defaults were chosen carefully for each service to balance performance, functionality and security for typical customers.

However, some enterprise customers may prefer a more security-focused balance for their Windows PCs and servers—one that reduces their attack surface to the absolute minimum—and may therefore wish to fully disable all services that are not needed in their specific environments.  For those customers, Microsoft is providing the accompanying guidance regarding which services can safely be disabled for this purpose.

The guidance is for Windows Server 2016 with Desktop Experience (unless used as a desktop replacement for end users). Each service on the system is categorized as follows:

• Should Disable: A security-focused enterprise will most likely prefer to disable this service and forgo its functionality (see additional details below).
• OK to Disable: This service provides functionality that is useful to some but not all enterprises, and security-focused enterprises that don’t use it can safely disable it.
• Do Not Disable: Disabling this service will impact essential functionality or prevent specific roles/features from functioning correctly. It therefore should not be disabled.
• (No guidance): These services should not be disabled.

Customers can configure their Windows PCs and servers to disable selected services using the Security Templates in their Group Policies or using PowerShell automation.  In some cases, the guidance includes specific Group Policy settings that disable the service’s functionality directly, as an alternative to disabling the service itself.

We recommend that customers disable the following services and their respective scheduled tasks on Windows Server 2016 with Desktop Experience:

Services:

1. Xbox Live Auth Manager
2. Xbox Live Game Save

Scheduled tasks:

1. \Microsoft\XblGameSave\XblGameSaveTask
2. \Microsoft\XblGameSave\XblGameSaveTaskLogon

See the attached spreadsheet for more information: Service-management-WS2016

Microsoft is pleased to announce the beta release of the recommended security configuration baseline settings for Windows 10 “Creators Update,” also known as version 1703, “Redstone 2,” or RS2. Please evaluate this proposed baseline and send us your feedback via blog comments below.

Download the content here: Windows-10-RS2-Security-Baseline

Microsoft is also announcing changes to the tool sets and URLs for managing Windows security configuration baselines. Those changes are described here.

The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, and all the recommended settings in spreadsheet form. New in this release, the spreadsheet also includes the corresponding settings for configuring through Windows’ Mobile Device Management (MDM).

The most significant differences between this baseline and that for Windows 10 v1607 (a.k.a., “Anniversary Update,” “Redstone 1”, RS1) are:

• Disabling the Server Message Block version 1 (SMBv1) protocol, using a custom “MS Security Guide” ADMX file so that the settings can be exposed through the Group Policy editor. Please read the caveats in the explanation text carefully. We have posted a separate blog article on that subject here.
• Removing the “Untrusted Font Blocking” setting. We discuss the reasons for this change here.
• Disabling VBScript in Internet Explorer when browsing sites in the Internet or Restricted Sites security zones.
• Removing the “Network access: Do not allow storage of passwords and credentials for network authentication” setting. Configuring this setting makes it impossible to configure a scheduled task that needs authenticated network access with a username and password.
• Disabling TLS 1.0 support for HTTPS sites in Internet Explorer, allowing only TLS 1.1 and TLS 1.2.
• Disabling default HomeGroup and Xbox services that are not needed on managed enterprise computers, conforming to the Server guidance we recently published.
• Exposing two more settings through the custom “MS Security Guide” ADMX to enforce protections for 32-bit processes and to “Turn on Windows Defender protection against Potentially Unwanted Applications.”

The Documentation subfolder in the downloadable zip-file attachment includes a spreadsheet showing the full set of differences between the RS1 and RS2 baselines. The spreadsheet was produced using Policy Analyzer.

As mentioned above, we invite and appreciate your feedback on this draft baseline. We will try to publish the final baseline within two weeks.

Microsoft reluctantly announces the retirement of the Security Compliance Manager (SCM) tool. At the same time, we are reaffirming our commitment to delivering robust and useful security guidance for Windows, and tools to manage that guidance.

Microsoft first released the Security Compliance Manager (SCM) in 2010. It was a mammoth program that combined GPO-based security configuration recommendations; Threats & Countermeasures text for each setting; automatic downloading of new baselines as they are published; creating and editing custom baselines; comparing baselines; and importing and exporting, including export to GPO backup, SCCM DCM, SCAP v1.0, and Excel. However, the program’s design is incredibly complex, with an entirely separate (and incredibly complex) authoring tool to create and edit baselines in SCM’s proprietary format. The SCM tool itself needed to be updated for every Windows release, to be able to represent baselines for newer operating systems correctly even when SCM was installed on an earlier Windows version. Otherwise, baselines would not accurately represent new advanced auditing policies or new security entities such as “Local account” and “NT SERVICE” accounts, and couldn’t recognize operating system versions correctly for import and export. In addition, SCM is designed for GPO management and would require a massive overhaul to be able to handle Desired State Configuration (DSC) or Mobile Device Management (MDM). In short, SCM has become too inflexible and unwieldy to continue investing in it, particularly with other alternatives at hand. We will continue to publish security baselines, but not in the .cab file format used by SCM.

Beginning with the baselines for Windows 8.1, Windows Server 2012R2, and Internet Explorer 11, we have been publishing baselines through this blog site in lightweight .zip files containing GPO backups, GPO reports, Excel spreadsheets, WMI filters, and scripts to apply the settings to local policy. We will continue to deliver security configuration guidance in that format. The GPO backups can be imported directly into Active Directory Group Policy along with corresponding WMI filters to apply policies to the correct machines. To take the place of SCM’s offline GPO-editing abilities, consider standing up an otherwise non-functional domain controller, importing Group Policy (.ADMX) templates as needed. To compare GPOs or to export to Excel, take a look at Policy Analyzer, which has much richer abilities in both areas than SCM had. We had previously retired the LocalGPO.wsf tool that had shipped with SCM and replaced it with the more-functional LGPO. Note that both tools have recently been updated and are now part of the new “Security Compliance Toolkit” which you can download here.

We recognize that the new tool set does not currently include support for DCM or SCAP and we will try to fill that gap. Meanwhile, though, the PowerShell-based Desired State Configuration (DSC) is rapidly gaining popularity, and more DSC tools are coming online to convert GPOs to DSC and to validate system configuration. Examples:

• BaselineManagement module: https://github.com/Microsoft/BaselineManagement
• DSC Environment Analyzer (DSCEA) announcement: https://blogs.technet.microsoft.com/ralphkyttle/2017/03/21/introducing-dscea/
• DSCEA repository: https://github.com/Microsoft/DSCEA

Continue monitoring this blog site for additional announcements (https://blogs.technet.microsoft.com/secguide/).

With the Windows 10 v1703 security configuration baseline, Microsoft is removing the recommendation to enable the “Untrusted Font Blocking” Group Policy setting in Computer Configuration | Administrative Templates | System | Mitigation Options. Windows 10 includes additional mitigations that make this setting far less important, while blocking untrusted fonts breaks several legitimate scenarios unnecessarily.

Parsing and rendering font data involves significant complexity, so it is not surprising that font-rendering engines have had bugs – particularly when handling font data that does not conform to expected formats. Nor is it surprising that malicious actors target these bugs with malformed font data to deliver exploit code through web pages and document files that support embedded or downloaded fonts. On versions of Windows prior to Windows 10 and Windows Server 2016, that problem has been compounded for programs that use Windows’ graphics device interface (GDI) APIs to load and render fonts. In addition to the threat of remote code execution in a compromised user-mode process, a GDI font-rendering bug can also result in kernel-mode execution and local elevation of privilege because most of GDI’s font logic was in Win32k.sys which runs in kernel mode.

The first release of Windows 10 introduced a new Group Policy setting, “Untrusted Font Blocking,” that offers a powerful mitigation against attacks on GDI’s font logic. Our prior security baseline configuration recommendations for Windows 10 have included the enforcement of this setting. The setting enables IT admins to disallow all programs from using GDI to load and render font data from any location outside of the %windir%\Fonts directory. Only administrators can put files into the Fonts directory, so this setting keeps standard user programs from using GDI to handle fonts downloaded through web pages, embedded in Office or PDF documents, or downloaded by users. Note that this block applies only to font-rendering through GDI and not to other user-mode font-rendering engines such as DirectWrite which is used by the Microsoft Edge and Google Chrome web browsers.

It turns out that at the same time, Windows 10 introduced a separate, always-on mitigation against GDI font-rendering bugs. However, Microsoft didn’t publicly discuss it until an August 2016 BlackHat presentation, Windows 10 Mitigation Improvements (see p. 34), and in a January 2017 blog post, Hardening Windows 10 with zero-day exploit mitigations (see the “Mitigating font exploits with AppContainer” section).

With Windows 10, GDI font parsing is no longer performed in kernel mode. Instead, it is performed in a sandboxed user-mode process, fontdrvhost.exe, which executes in a highly-restricted, per-session AppContainer process under a limited-scope, system-generated virtual account. The AppContainer process is granted no Capabilities and minimal privileges. (When a process in an AppContainer requests access to a resource, the Windows security access check applies tighter rules than it does for traditional, non-AppContainer processes, granting access only if the resource explicitly grants access to it.)

One of the most visible downsides of blocking downloaded and embedded fonts is that many web sites rely on them, and blocking them can substantially diminish usability. For example, here is the MSN home page’s banner rendered in Microsoft Edge, which is not affected by the Untrusted Font Blocking setting:

And here is the same banner rendered in Internet Explorer with font-blocking enabled:

As you can see, the MSN and Bing logos are represented using downloaded fonts, as are most of the Microsoft application logos. In addition to app logos, Microsoft’s Office 365 also makes liberal use of downloaded fonts for web application graphics such as navigation aids and actions such as “delete” and “flag this message.” These screenshots show the differences: the first shows Microsoft Edge without font blocking; the second shows Internet Explorer with font blocking enforced:

With GDI font parsing performed in a restrictive AppContainer, the risk of handling untrusted fonts in GDI is now acceptably low enough that we feel confident that the costs of font-blocking exceed its benefits. Therefore, we are removing our previous recommendation to enable untrusted font blocking.

Version 1 of the Server Message Block (SMB) protocol was developed in the early days of personal computer networking, and as Ned Pyle describes in his blog post, Stop using SMB1 there are many reasons to cease using it on your networks. We have added that recommendation to our baseline, and have exposed a way to do so through Group Policy editors for local or domain GPOs by adding to the custom “MS Security Guide” ADMX. That said, the settings that need to be manipulated are not a natural fit for GPO management, so you need to be careful while using it. Applying settings incorrectly can cause serious problems.

We wanted these custom settings to work for all supported versions of Windows and to be reversible so that SMBv1 could be re-enabled if necessary. Due to the limitations of the ADMX syntax, we ended up implementing it through three separate settings:

• Configure SMB v1 server, to disable or enable server-side processing of the SMBv1 protocol. This is a simple Enabled/Disabled/Not Configured setting that controls the “SMB1” registry value in HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.
• Configure SMB v1 client driver, to configure the startup mode for the kernel mode driver that implements client-side SMBv1 processing (MrxSmb10). This setting includes a dropdown that is activated when the Enabled radio button is selected and that controls the “Start” registry value in HKLM\SYSTEM\CurrentControlSet\Services\MrxSmb10. Note that choosing the “Disabled” radio button deletes the “Start” value, so don’t do that! See the explain text shown in the table below if you need to restore default behavior. Note that the “Disabled” radio button is not the same thing as the dropdown value, “Disable driver (recommended).”
• Configure SMB v1 client (extra setting…), which is needed only for older Windows versions. This setting controls the “DependOnService” REG_MULTI_SZ value in HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation, which represents the service and driver dependencies of the Workstation service (internal name: LanmanWorkstation). Older versions of Windows configure LanmanWorkstation with a dependency on the SMBv1 client driver (MrxSmb10) running, which can be problematic if MrxSmb10 is disabled. So this setting enables you to configure the LanmanWorkstation service’s dependencies directly. The setting’s Explain text describes exactly what to enter into the text box. Unfortunately, there is no way for the ADMX to offer a choice of predefined REG_MULTI_SZ values. You have to type – or copy/paste – the text yourself. And here again, choosing the “Disabled” radio button deletes the DependOnService value, which would be very bad, so don’t do that!

This table lists the settings and corresponding explain text from the Group Policy editor:

You can obtain the "MS Security Guide" ADMX template in the download associated with the draft baseline for Windows 10 v1703 here. Copy SecGuide.admx into your %windir%\PolicyDefinitions directory, and copy SecGuide.adml into the en-us subdirectory.

Microsoft is pleased to announce the final release of the recommended security configuration baseline settings for Windows 10 “Creators Update,” also known as version 1703, “Redstone 2,” or RS2. The downloadable attachment to this blog post includes importable GPOs, tools for applying the GPOs, custom ADMX files for Group Policy settings, and all the settings in spreadsheet form.

Download the content here: Windows-10-RS2-Security-Baseline-FINAL.zip

This updated content will be incorporated into the Security Compliance Toolkit shortly. (Note that the Security Compliance Manager tool has been retired.)

The differences in this baseline from the v1703 draft version are:

• The security settings that disallowed Internet Explorer from using downloaded fonts in the Internet and Restricted Sites zones have been removed. This change in IE11 recommendations applies only to Windows 10, and is possible because of Windows 10's additional mitigations as described in the blog post, Dropping the "Untrusted Font Blocking" setting.
• The enforcement of the default for the User Rights Assignment, Generate security audits (SeAuditPrivilege), has been removed. Enforcing the default does not mitigate contemporary security threats, and hampers the functionality of programs such as System Center Operations Manager (SCOM) that need to change the default.
• We are enabling the setting, "Do not suggest third-party content in Windows spotlight" in User Configuration\Administrative Templates\Windows Components\Cloud Content. Enabling this setting is consistent with our having previously enabled "Turn off Microsoft consumer experiences."

Thank you to the Center for Internet Security (CIS) and to everyone else who gave us feedback.

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for Windows 10 “Fall Creators Update,” also known as version 1709, “Redstone 3,” or RS3. Please evaluate this proposed baseline and send us your feedback via blog comments below.

Download the content here: Windows-10-RS3-Security-Baseline-DRAFT

The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, and all the recommended settings in spreadsheet form. The spreadsheet also includes the corresponding settings for configuring through Windows’ Mobile Device Management (MDM).

The differences between this baseline and that for Windows 10 v1703 (a.k.a., “Creators Update,” “Redstone 2”, RS2) are:

• Implementing Attack Surface Reduction rules within Windows Defender Exploit Guard. Exploit Guard is a new feature of v1709 that helps prevent a variety of actions often used by malware. You can read more about Exploit Guard here: Reduce attack surfaces with Windows Defender Exploit Guard. Note that for this draft, we are enabling “block” mode for all of these settings. We are taking a particularly careful look at the “Block office applications from injecting into other process;” if it creates compatibility problems then we might change the baseline recommendation to “audit” mode for that setting. Please let us know what you observe with this draft baseline.
• Enabling Exploit Guard’s Network Protection feature to prevent any application from accessing web sites identified as dangerous, including those hosting phishing scams and malware. This extends the type of protection offered by SmartScreen to all programs, including third-party browsers.
• Enabling a new setting that prevents users from making changes to the Exploit protection settings area in the Windows Defender Security Center.

We also recommend enabling Windows Defender Application Guard. Our testing has proven it to be a powerful defense. We would have included it in this baseline, but its configuration settings are organization-specific.

The old Enhanced Mitigation Experience Toolkit (EMET) add-on is not supported on Windows 10 v1709. Instead, we offer Windows Defender Exploit Guard’s Exploit Protection, which is now a built-in, fully-configurable feature of Windows 10. Exploit Protection brings the granular control you remember from EMET into a new, modern feature. Our download package includes a pre-configured, customizable XML file to help you add exploit mitigations to many common applications. You can use it as-is, or customize it for your own needs. Note that you configure the corresponding Group Policy setting by specifying the full local or server file path to the XML file. Because our baseline cannot specify a path that works for everyone, it is not included in the baseline packages GPOs – you must add it yourself.

As mentioned above, we invite and appreciate your feedback on this draft baseline. We plan to publish the final baseline for v1709 within two weeks.

Microsoft is pleased to announce the final release of the recommended security configuration baseline settings for Windows 10 “Fall Creators Update,” also known as version 1709, “Redstone 3,” or RS3. There are no changes from the draft release we published a few weeks ago.

The 1709 baseline package has been added to the Microsoft Security Compliance Toolkit. On that page, click the Download button, then select "Windows 10 Version 1709 Security Baseline.zip" and any other content you want to download.

The 1709 baseline package includes GPOs that can be imported in Active Directory, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, and all the recommended settings in spreadsheet form. The spreadsheet also includes the corresponding settings for configuring through Windows’ Mobile Device Management (MDM).

We're also happy to announce the revamping of the Windows Security Baselines landing page.

The differences between the 1709 baseline and that for Windows 10 v1703 (a.k.a., “Creators Update,” “Redstone 2”, RS2) are:

• Implementing Attack Surface Reduction rules within Windows Defender Exploit Guard. Exploit Guard is a new feature of v1709 that helps prevent a variety of actions often used by malware. You can read more about Exploit Guard here: Reduce attack surfaces with Windows Defender Exploit Guard. Note that we have enabled “block” mode for all of these settings. We are continuing to watch the “Block office applications from injecting into other process” setting; if it creates compatibility problems then we might change the baseline recommendation to “audit” mode for that setting. Please let us know what you observe.
• Enabling Exploit Guard’s Network Protection feature to prevent any application from accessing web sites identified as dangerous, including those hosting phishing scams and malware. This extends the type of protection offered by SmartScreen to all programs, including third-party browsers.
• Enabling a new setting that prevents users from making changes to the Exploit protection settings area in the Windows Defender Security Center.

We also recommend enabling Windows Defender Application Guard. Our testing has proven it to be a powerful defense. We would have included it in this baseline, but its configuration settings are organization-specific.

The old Enhanced Mitigation Experience Toolkit (EMET) add-on is not supported on Windows 10 v1709. Instead, we offer Windows Defender Exploit Guard’s Exploit Protection, which is now a built-in, fully-configurable feature of Windows 10. Exploit Protection brings the granular control you remember from EMET into a new, modern feature. Our download package includes a pre-configured, customizable XML file to help you add exploit mitigations to many common applications. You can use it as-is, or customize it for your own needs. Note that you configure the corresponding Group Policy setting by specifying the full local or server file path to the XML file. Because our baseline cannot specify a path that works for everyone, it is not included in the baseline packages GPOs – you must add it yourself.

Thank you to the Center for Internet Security (CIS) and to everyone else who gave us feedback.

Customers that deployed Microsoft’s security baseline for Windows 10 v1709 might have experienced device and component failures. The BitLocker GPO settings recommended in the Windows security configuration baselines for Windows 10 include enabling “Disable new DMA devices when this computer is locked” to defend against Direct Memory Access (DMA) attacks. That setting was first introduced in Windows 10 v1703 (also known as “Creators Update,” “Redstone 2,” or “RS2”) and is in our recommended baselines both for v1703 and Windows 10 v1709 (a.k.a., “Fall Creators Update,” “Redstone 3,” or “RS3”). Windows’ internal implementation underlying that Group Policy setting was modified for v1709 to strengthen its enforcement. However, the change inadvertently led to some device and component failures on v1709 that are described in KB article 4057300, including potential problems with network adapters, audio devices, and pointing devices.

The Group Policy setting is designed to improve the defense of BitLocker-protected systems from DMA-based attacks bypassing memory protections. It is intended to protect against external devices plugged into DMA ports, but a side effect of the current implementation affects device drivers controlling internal devices. Microsoft is aware of this issue and is actively working to address this via a Windows update.

While Microsoft is working on a solution, Windows 10 v1709 customers who are affected may revert the Group Policy setting to “Not Configured” or configure it to “Disabled” to alleviate this issue. This should be a temporary workaround until this issue is addressed in a Windows update.

Note: Removing this setting will not negatively impact systems that do not have external DMA ports (such as Thunderbolt™) including the Microsoft Surface Pro and a range of other OEM devices.  Please check with your OEM directly for specific details.

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for Microsoft Office Professional Plus 2016 and Office 365 ProPlus 2016 apps. Please evaluate this proposed baseline and send us your feedback via blog comments below.

Download the content here: Office-2016-baseline-DRAFT

The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, a custom administrative template (ADMX) file for Group Policy settings, all the recommended settings in spreadsheet form and as Policy Analyzer rules. The recommended settings correspond with the Office 2016 administrative templates version 4639 released on December 15, 2017 that can be downloaded here.

Instead of retaining the entire Office 2013 baseline and simply adding settings that were newly introduced in the Office 2016 GPOs, we have conducted a thorough review of all available configuration settings – as we did beginning with the Windows 10 baselines – including in the baseline only those settings that address contemporary security threats. In the process we removed over eight dozen settings that had been in previous baselines but that were determined not to advance security posture in a meaningful way, and added a handful of new settings. The result is a more streamlined, purposeful baseline that is easier to configure, deploy, and validate.

Macro security

Office’s support for macros remains a vital tool for enterprise automation and at the same time a vector for attack, so macro security remains an important consideration. Office 2016 introduced a new GPO setting, “Block macros from running in Office files from the Internet” that was also later backported to Office 2013. Enabling the setting disables macros embedded in Office documents that came from the internet, including through email from an external sender. Office displays a notification that does not give the user an option to enable the macros. This baseline enables the setting for all apps that offer it: Excel, PowerPoint, Visio, and Word. Because this setting affects only Office documents received from the Internet that contain embedded macros, we anticipate that enabling this setting should rarely if ever cause operational problems for enterprises. The settings do not affect documents that are received from the enterprise’s Intranet or Trusted Sites zones.

The baseline also retains the “VBA Macro Notification Settings” options from our previous baselines that require that macros embedded in Office documents be signed by a trusted publisher. We recognize that some organizations have had workflows and processes relying on such macros for a long time, and that enforcing these particular settings can cause operational issues. It can also be challenging to identify all the documents and VBA projects that need to be signed. We are considering moving these settings into a separate GPO to make it easier to switch the settings on or off without affecting the rest of the baseline. Please let us know via the comments on this post what you think of that idea.

Blocking Flash activation

We have also added a setting to the custom “MS Security Guide” ADMX that prevents the Adobe Flash ActiveX control from being loaded by Office applications. Vulnerabilities in Adobe Flash are often exploited by sending the victim a Microsoft Office document that contains malformed Flash data and an OLE reference that activates Flash and passes it the malformed data, which triggers the exploit code. This setting allows you to either (1) block all activation of Flash from within Office or (2) only block activation of Flash when it is directly embedded or linked in an Office document. The baseline recommends that you block all activation as it is the safest option available but note that it can impact productivity scenarios (e.g. consuming embedded videos in PowerPoint) within your enterprise. Please test this setting within your environment to identify the appropriate level of protection that balances your security and productivity requirements.

Office has long included a “kill-bit” feature similar to Windows’ that enables administrators to block specific controls from being activated within Office processes. Enabling the new setting in “MS Security Guide” configures Flash kill-bit registry values to block Flash activation in Office processes, reducing your security exposure.

Other changes

Although we have removed many settings from the baseline, there are a few changes to which we would like to call attention. All of these are under User Configuration\Administrative Templates.

• Microsoft Outlook 2016\Account Settings\Exchange, Authentication with Exchange Server: we are keeping this setting enabled, but changing its configuration from “Kerberos/NTLM Password Authentication” to “Kerberos Password Authentication.” We do not anticipate operational issues from strengthening this setting. Please test this change in your environments and let us know what you observe.
• Microsoft Office 2016\Manage Restricted Permissions, Always require users to connect to verify permission: we are removing this setting from the baseline, but there is a security and usability tradeoff, and our finding is that the security benefit is too small for the usability degradation. The setting ensures that if someone’s access to a rights-managed document or email is revoked after they have received it, they will be blocked from opening it the next time they try. The downside is that this blocks all offline access. In our experience, this kind of revocation is far less common than the need to open rights-managed items when in airplane mode.
• We have dropped the “Disable all trusted locations” Trust Center settings, but disabled two additional “Allow Trusted Locations on the network” settings that had been overlooked in past baselines for Project and Visio.

We look forward to your feedback on this beta so that the final version strikes the correct balance between security and usability. Thank you.

Microsoft is pleased to announce the final release of the recommended security configuration baseline settings for Microsoft Office Professional Plus 2016 and Office 365 ProPlus 2016 apps. There are no changes from the draft release we published a few weeks ago, other than minor corrections within the spreadsheet.

Highlights of this baseline:

• Streamlined baseline
• Stronger macro security
• Defending against malware by blocking Flash ActiveX activation within Office documents

Download the content here: Office-2016-baseline

The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, a custom administrative template (ADMX) file for Group Policy settings, all the recommended settings in spreadsheet form and as Policy Analyzer rules. The recommended settings correspond with the Office 2016 administrative templates version 4639 released on December 15, 2017; we have included those ADMX and ADML files in a zip file in the package's Templates subdirectory.

Instead of retaining the entire Office 2013 baseline and simply adding settings that were newly introduced in the Office 2016 GPOs, we have conducted a thorough review of all available configuration settings – as we did beginning with the Windows 10 baselines – including in the baseline only those settings that address contemporary security threats. In the process we removed over eight dozen settings that had been in previous baselines but that were determined not to advance security posture in a meaningful way, and added a handful of new settings. The result is a more streamlined, purposeful baseline that is easier to configure, deploy, and validate.

Macro security

Office’s support for macros remains a vital tool for enterprise automation and at the same time a vector for attack, so macro security remains an important consideration. Office 2016 introduced a new GPO setting, “Block macros from running in Office files from the Internet” that was also later backported to Office 2013. Enabling the setting disables macros embedded in Office documents that came from the internet, including through email from an external sender. Office displays a notification that does not give the user an option to enable the macros. This baseline enables the setting for all apps that offer it: Excel, PowerPoint, Visio, and Word. Because this setting affects only Office documents received from the Internet that contain embedded macros, we anticipate that enabling this setting should rarely if ever cause operational problems for enterprises. The settings do not affect documents that are received from the enterprise’s Intranet or Trusted Sites zones.

The baseline also retains the “VBA Macro Notification Settings” options from our previous baselines that require that macros embedded in Office documents be signed by a trusted publisher. We recognize that some organizations have had workflows and processes relying on such macros for a long time, and that enforcing these particular settings can cause operational issues. It can also be challenging to identify all the documents and VBA projects that need to be signed. We will continue considering moving these settings into a separate GPO to make it easier to switch the settings on or off without affecting the rest of the baseline. Please let us know via the comments on this post what you think of that idea.

Blocking Flash activation

We have also added a setting to the custom “MS Security Guide” ADMX that prevents the Adobe Flash ActiveX control from being loaded by Office applications. Vulnerabilities in Adobe Flash are often exploited by sending the victim a Microsoft Office document that contains malformed Flash data and an OLE reference that activates Flash and passes it the malformed data, which triggers the exploit code. This setting allows you to either (1) block all activation of Flash from within Office or (2) only block activation of Flash when it is directly embedded or linked in an Office document. The baseline recommends that you block all activation as it is the safest option available but note that it can impact productivity scenarios (e.g. consuming embedded videos in PowerPoint) within your enterprise. Please test this setting within your environment to identify the appropriate level of protection that balances your security and productivity requirements.

Office has long included a “kill-bit” feature similar to Windows’ that enables administrators to block specific controls from being activated within Office processes. Enabling the new setting in “MS Security Guide” configures Flash kill-bit registry values to block Flash activation in Office processes, reducing your security exposure.

Other changes

Although we have removed many settings from the baseline, there are a few changes to which we would like to call attention. All of these are under User Configuration\Administrative Templates.

• Microsoft Outlook 2016\Account Settings\Exchange, Authentication with Exchange Server: we are keeping this setting enabled, but changing its configuration from “Kerberos/NTLM Password Authentication” to “Kerberos Password Authentication.” We do not anticipate operational issues from strengthening this setting. Please test this change in your environments and let us know what you observe.
• Microsoft Office 2016\Manage Restricted Permissions, Always require users to connect to verify permission: we are removing this setting from the baseline, but there is a security and usability tradeoff, and our finding is that the security benefit is too small for the usability degradation. The setting ensures that if someone’s access to a rights-managed document or email is revoked after they have received it, they will be blocked from opening it the next time they try. The downside is that this blocks all offline access. In our experience, this kind of revocation is far less common than the need to open rights-managed items when in airplane mode.
• We have dropped the “Disable all trusted locations” Trust Center settings, but disabled two additional “Allow Trusted Locations on the network” settings that had been overlooked in past baselines for Project and Visio.

We believe that this baseline strikes the correct balance between security and usability, but as always we welcome your feedback for opportunities to improve it. Thank you.

Microsoft is pleased to announce the draft release of the security configuration baseline settings for the upcoming Windows 10 version 1803, codenamed “Redstone 4.” Please evaluate this proposed baseline and send us your feedback via blog comments below.

Download the content here: DRAFT-Windows-10-v1803-RS4

The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, and all the recommended settings in spreadsheet form and as a Policy Analyzer file (DRAFT-MSFT-Win10-RS4.PolicyRules).

The differences between this baseline package and that for Windows 10 v1709 (a.k.a., “Fall Creators Update,” “Redstone 3”, RS3) include:

• Two scripts to apply settings to local policy: one for domain-joined systems and a separate one that removes the prohibitions on remote access for local accounts, which is particularly helpful for non-domain-joined systems, and for remote administration using LAPS-managed accounts.
• Increased alignment with the Advanced Auditing recommendations in the Windows 10 and Windows Server 2016 security auditing and monitoring reference document (also reflected here).
• Updated Windows Defender Exploit Guard Exploit Protection settings (separate EP.xml file).
• New Windows Defender Exploit Guard Attack Surface Reduction (ASR) mitigations.
• Removed numerous settings that were determined no longer to provide mitigations against contemporary security threats. The GPO differences are listed in a spreadsheet in the package’s Documentation folder.

We’d like feedback regarding an Advanced Auditing setting that we have considered adding to the baseline but haven’t so far. The auditing and monitoring reference, mentioned above, recommends auditing failure events for Filtering Platform Connection. This is somewhat redundant because the Windows client baseline’s firewall configuration logs dropped packets. The Advanced Auditing setting collects richer data, but can add large numbers of events to the Security event log. The reference recommends against auditing successful connections. So, should the baseline:

• Stay as it is, with firewall logging only and no Advanced Auditing for Filtering Platform Connection?
• Keep firewall logging as it is, and add Failure auditing for Filtering Platform Connection? (This creates duplication between dropped packet logging and failure audit events.)
• Keep firewall successful-connection logging only, and replace the recommendation for dropped-packet logging with Failure auditing for Filtering Platform Connection? (An obvious disadvantage is that admins have to look in two places for firewall-related events.)
• Another alternative?

Please let us know in the comments below.

Thanks.

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 “April 2018 Update,” also known as version 1803, “Redstone 4,” or RS4.

Download the content here: Windows-10-RS4-Security-Baseline-FINAL

The downloadable attachment to this blog post (which will be incorporated into the Security Compliance Toolkit shortly) includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, all the recommended settings in spreadsheet form and as a Policy Analyzer file (MSFT-Win10-v1803-RS4-FINAL.PolicyRules), and a Policy Analyzer-generated spreadsheet showing the differences from the RS3/v1709 baseline.

The only change from the draft version of this baseline is that after discussion we have removed the recommendation to configure the “Microsoft network server: Amount of idle time required before suspending session” security option. Enforcing that setting does not mitigate a contemporary security threat.

The differences between this baseline package and that for Windows 10 v1709 (a.k.a., “Fall Creators Update,” “Redstone 3”, RS3) include:

• Two scripts to apply settings to local policy: one for domain-joined systems and a separate one that removes the prohibitions on remote access for local accounts, which is particularly helpful for non-domain-joined systems, and for remote administration using LAPS-managed accounts.
• Increased alignment with the Advanced Auditing recommendations in the Windows 10 and Windows Server 2016 security auditing and monitoring reference document (also reflected here).
• Updated Windows Defender Exploit Guard Exploit Protection settings (separate EP.xml file).
• New Windows Defender Exploit Guard Attack Surface Reduction (ASR) mitigations.
• Removed numerous settings that were determined no longer to provide mitigations against contemporary security threats. The GPO differences are listed in the “Delta RS3 to RS4 baseline.xlsx” spreadsheet in the package’s Documentation folder. (Since the draft release of the RS4 baseline, we removed one more setting: “Microsoft network server: Amount of idle time required before suspending session.”)

After the draft baseline was released, Windows added another GPO setting that we considered adding to the baseline but ultimately decided not to configure at this time. The GPO path is Computer Configuration\Administrative Templates\System\Credentials Delegation\Encryption Oracle Remediation. You can read information about the setting here and here. (Note that the term “Oracle” here refers to a cryptographic concept and not to anything having to do with Oracle Corporation or its products.) While we recommend patching systems and incorporating this setting as soon as possible, we opted not to include it in the baseline for broad use in the short term because if all servers and clients aren’t patched in a timely fashion the setting will block remote desktop connections. We anticipate incorporating this setting in the next baseline that we publish.

When we published the draft baseline for RS4, we requested feedback about replacing the firewall’s logging facility with Advanced Auditing, such as by auditing failure events for Filtering Platform Connection. At this time, we’re going to keep the baseline as it is rather than introduce more changes. But remember that the baseline is just that: a starting point. If monitoring security events works better for you than monitoring firewall logs, do so. Or if you want to use both, do so.

Windows 10 v1803 (RS4) has greatly expanded its manageability using Mobile Device Management (MDM). However, our mapping from the baseline’s GPO settings to MDM is not ready to publish at this time. We will publish the baseline in MDM form as soon as it is ready.

Policy Analyzer is a utility in the Security Compliance Toolkit for analyzing and comparing sets of Group Policy Objects (GPOs). We have just posted a minor update that resolves a localization bug reading some non-English advanced auditing settings files (audit.csv), and another bug that would cause Policy Analyzer to crash when reading an invalid GPO backup XML file. Policy Analyzer should be completely bug free now.

The download package also adds PolicyRules files for the four Windows and Office baselines we have published since Policy Analyzer was last updated.

Microsoft is pleased to announce the draft release of the security configuration baseline settings for Windows 10 version 1809 (a.k.a., “Redstone 5” or “RS5”), and for Windows Server 2019. Please evaluate these proposed baselines and send us your feedback via blog comments below.

Download the content here: Windows-10-1809-Security-Baseline-DRAFT.zip

The downloadable attachment to this blog post includes importable GPOs, a PowerShell script for applying the GPOs to local policy, custom ADMX files for Group Policy settings, documentation in spreadsheet form and as a Policy Analyzer file (MSFT-Win10-v1809-RS5-WS2019-DRAFT.PolicyRules). In this release, we have changed the documentation layout in a few ways:

• MS Security Baseline Windows 10 v1809 and Server 2019.xlsx – multi-tabbed workbook listing all Group Policy settings that ship in-box with Windows 10 v1809 or Windows Server 2019. Columns for “Windows 10 v1809,” “WS2019 Member Server,” and “WS2019 DC” show the recommended settings for those three scenarios. A small number of cells are color-coded to indicate that the settings should not be applied to systems that are not joined to an Active Directory domain. Cells in the “WS2019 DC” columns are also highlighted when they differ from the corresponding cells in the “WS2019 Member Server” column. Another change from past spreadsheets is that we have combined tabs that used to be separate. Specifically, we are no longer breaking out Internet Explorer and Windows Defender AV settings into separate tabs, nor the settings for LAPS, MS Security Guide, and MSS (Legacy). All these settings are now in the Computer and User tabs.
• BaselineDiffs-to-v1809-RS5-DRAFT.xlsx – This Policy Analyzer-generated workbook lists the differences in Microsoft security configuration baselines between the new baselines and the corresponding previous baselines. The Windows 10 v1809 settings are compared against those for Windows 10 v1803, and the Windows Server 2019 baselines are compared against those for Windows Server 2016.
• Windows 10 1803 to 1809 New Settings.xlsx – Lists all the settings that are available in Windows 10 v1809 that were added since Windows 10 v1803. (We used to highlight these settings in the big all-settings spreadsheets.)
• Server 2016 to 2019 New Settings.xlsx – Lists all the settings that are available in Windows Server 2019 that were added since Windows Server 2016. (We used to highlight these settings in the big all-settings spreadsheets.)

Highlights of the differences from past baselines, which are listed in BaselineDiffs-to-v1809-RS5-DRAFT.xlsx:

• The MS Security Guide custom setting protecting against potentially unwanted applications (PUA) has been deprecated, and is now implemented with a new setting under Computer Configuration\...\Windows Defender Antivirus.
• We have enabled the “Encryption Oracle Remediation” setting we had considered for v1803. At the time we were concerned that enabling the newly-introduced setting would break too many not-yet-patched systems. We assume that systems have since been brought up to date. (You can read information about the setting hereand here.)
• Changes to Virtualization-Based Security settings (used by Credential Guard and Code Integrity):
  • “Platform Security Level” changed from “Secure Boot and DMA Protection” to “Secure Boot.” If system hardware doesn’t support DMA protection, selecting “Secure Boot and DMA Protection” prevents Credential Guard from operating. If you can affirm that your systems support the DMA protection feature, choose the stronger option. We have opted for “Secure Boot” (only) in the baseline to reduce the likelihood that Credential Guard fails to run.
  • Enabled the new System Guard Secure Launch setting which will enable Secure Launch on new capable hardware. Secure Launch changes the way windows boots to use Intel Trusted Execution Technology (TXT) and Runtime BIOS Resilience features to prevent firmware exploits from being able to impact the security of the Windows Virtualization Based Security environment.
  • Enabled the “Require UEFI Memory Attributes Table” option.
• Enabled the new Kernel DMA Protection feature described here. The “External device enumeration” policy controls whether to enumerate external devices that are not compatible with DMA-remapping. Devices that are compatible with DMA-remapping are always enumerated.
• Removed the BitLocker setting, “Allow Secure Boot for integrity validation,” as it merely enforced a default that was unlikely to be modified even by a misguided administrator.
• Removed the BitLocker setting, “Configure minimum PIN length for startup,” as new hardware features reduce the need for a startup PIN, and the setting increased Windows’ minimum by only one character.
• Enabled the new Microsoft Edge setting to prevent users from bypassing certificate error messages, bringing Edge in line with a similar setting for Internet Explorer.
• Removed the block against handling PKU2U authentication requests, as the feature is increasingly necessary.
• Removed the configuration of the “Create symbolic links” user rights assignment, as it merely enforced a default, was unlikely to be modified by a misguided administrator or for malicious purposes, and needs to be changed to a different value when Hyper-V is enabled.
• Removed the deny-logon restrictions against the Guests group as unnecessary: by default, the Guest account is the only member of the Guests group, and the Guest account is disabled. Only an administrator can enable the Guest account or add members to the Guests group.
• Removed the disabling of the xbgm (“Xbox Game Monitoring”) service, as it is not present in Windows 10 v1809. (By the way, consumer services such as the Xbox services have been removed from Windows Server 2019 with Desktop Experience!)
• Removed Credential Guard from the Domain Controller baseline. (Credential Guard is not useful on domain controllers and is not supported there.)
• Created and enabled a new custom MS Security Guide setting for the domain controller baseline, “Extended Protection for LDAP Authentication (Domain Controllers only),” which configures the LdapEnforceChannelBinding registry value described here.
• The Server 2019 baselines pick up all the changes accumulated in the four Windows 10 releases since Windows Server 2016.

We have replaced the collection of .cmd batch files for applying the baselines to local policy with a single PowerShell script that takes one of these five command-line switches to indicate which baseline you want to apply:

.\BaselineLocalInstall.ps1 -Win10DomainJoined      - for Windows 10 v1809, domain-joined
.\BaselineLocalInstall.ps1 -Win10NonDomainJoined   - for Windows 10 v1809, non-domain-joined
.\BaselineLocalInstall.ps1 -WS2019Member           - for Windows Server 2019, domain-joined
.\BaselineLocalInstall.ps1 -WS2019NonDomainJoined  - for Windows Server 2019, non-domain-joined
.\BaselineLocalInstall.ps1 -WS2019DomainController - for Windows Server 2019, domain controller

A couple of important notes about using the BaselineLocalInstall.ps1 script:

• PowerShell execution policy must be configured to allow script execution. You can configure this with a command line such as the following:
  Set-ExecutionPolicy RemoteSigned
• LGPO.exe must be in the Tools subdirectory or somewhere in the Path. LGPO.exe is part of the Security Compliance Toolkit and can be downloaded from this URL:
  https://www.microsoft.com/download/details.aspx?id=55319

Windows 10 v1809 has greatly expanded its manageability using Mobile Device Management (MDM). The Intune team is preparing documentation about the Microsoft Windows MDM security baseline and how to use Intune to implement the baseline, and will publish it very soon. We will post information to this blog when that happens.

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 October 2018 Update (a.k.a., version 1809, “Redstone 5” or “RS5”), and for Windows Server 2019.

For now, download the content here: Windows-10-1809-Security-Baseline-FINAL. It will be posted to the Security Compliance Toolkit download site very soon.

The downloadable attachment to this blog post includes importable GPOs, a PowerShell script for applying the GPOs to local policy, custom ADMX files for Group Policy settings, documentation in spreadsheet form and as a set of Policy Analyzer files. In this release, we have changed the documentation layout in a few ways:

• MS Security Baseline Windows 10 v1809 and Server 2019.xlsx – multi-tabbed workbook listing all Group Policy settings that ship in-box with Windows 10 v1809 or Windows Server 2019. Columns for “Windows 10 v1809,” “WS2019 Member Server,” and “WS2019 DC” show the recommended settings for those three scenarios. A small number of cells are color-coded to indicate that the settings should not be applied to systems that are not joined to an Active Directory domain. Cells in the “WS2019 DC” columns are also highlighted when they differ from the corresponding cells in the “WS2019 Member Server” column. Another change from past spreadsheets is that we have combined tabs that used to be separate. Specifically, we are no longer breaking out Internet Explorer and Windows Defender AV settings into separate tabs, nor the settings for LAPS, MS Security Guide, and MSS (Legacy). All these settings are now in the Computer and User tabs.
• A set of Policy Analyzer files:
  • MSFT-Win10-v1809-RS5-WS2019-FINAL.PolicyRules – a Policy Analyzer file representing all the GPOs in the combined Windows 10 and Server 2019 baselines.
  • MSFT-Win10-v1809-RS5-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows 10 v1809.
  • MSFT-WS2019-MemberServer-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Member Server.
  • MSFT-WS2019-DomainController-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Domain Controller.
• BaselineDiffs-to-v1809-RS5-FINAL.xlsx – This Policy Analyzer-generated workbook lists the differences in Microsoft security configuration baselines between the new baselines and the corresponding previous baselines. The Windows 10 v1809 settings are compared against those for Windows 10 v1803, and the Windows Server 2019 baselines are compared against those for Windows Server 2016.
• Windows 10 1803 to 1809 New Settings.xlsx – Lists all the settings that are available in Windows 10 v1809 that were added since Windows 10 v1803. (We used to highlight these settings in the big all-settings spreadsheets.)
• Server 2016 to 2019 New Settings.xlsx – Lists all the settings that are available in Windows Server 2019 that were added since Windows Server 2016. (We used to highlight these settings in the big all-settings spreadsheets.)

Highlights of the differences from past baselines, which are listed in BaselineDiffs-to-v1809-RS5-FINAL.xlsx:

• Added two new Attack Surface Reduction rules in Windows Defender Exploit Guard: “Block Office communication applications from creating child processes” (which includes Outlook), and “Block Adobe Reader from creating child processes.” Note that these were added since the draft release of these baselines.
• Since the draft baseline, we removed the “Turn off printing over HTTP” setting in “Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings.” This setting had been in our baselines at least as far back as Windows XP because of the mistaken belief that it distinguished between HTTP and HTTPS. Enabling this setting also disables printing over HTTPS, which breaks legitimate and necessary functionality for no security benefit.
• The MS Security Guide custom setting protecting against potentially unwanted applications (PUA) has been deprecated, and is now implemented with a new setting under Computer Configuration\...\Windows Defender Antivirus.
• We have enabled the “Encryption Oracle Remediation” setting we had considered for v1803. At the time we were concerned that enabling the newly-introduced setting would break too many not-yet-patched systems. We assume that systems have since been brought up to date. (You can read information about the setting here and here.)
• Changes to Virtualization-Based Security settings (used by Credential Guard and Code Integrity):
  • “Platform Security Level” changed from “Secure Boot and DMA Protection” to “Secure Boot.” If system hardware doesn’t support DMA protection, selecting “Secure Boot and DMA Protection” prevents Credential Guard from operating. If you can affirm that your systems support the DMA protection feature, choose the stronger option. We have opted for “Secure Boot” (only) in the baseline to reduce the likelihood that Credential Guard fails to run.
  • Enabled the new System Guard Secure Launch setting which will enable Secure Launch on new capable hardware. Secure Launch changes the way windows boots to use Intel Trusted Execution Technology (TXT) and Runtime BIOS Resilience features to prevent firmware exploits from being able to impact the security of the Windows Virtualization Based Security environment.
  • Disabled the “Require UEFI Memory Attributes Table” option. This is a change from the draft release, and is intended to increase compatibility.
  • Removed Credential Guard from the Domain Controller baseline, while retaining the rest of the VBS settings. This is implemented in a new DC-only GPO named “MSFT Windows Server 2019 - Domain Controller Virtualization Based Security.” Note that this is a change from the draft baseline in which we had removed all VBS settings from the DC baseline. (Credential Guard is not useful on domain controllers and is not supported there.)
• Enabled the new Kernel DMA Protection feature described here. The “External device enumeration” policy controls whether to enumerate external devices that are not compatible with DMA-remapping. Devices that are compatible with DMA-remapping are always enumerated.
• Removed the BitLocker setting, “Allow Secure Boot for integrity validation,” as it merely enforced a default that was unlikely to be modified even by a misguided administrator.
• Removed the BitLocker setting, “Configure minimum PIN length for startup,” as new hardware features reduce the need for a startup PIN, and the setting increased Windows’ minimum by only one character.
• Since the draft release, we removed “Prevent users from modifying settings” from “Computer Configuration\Administrative Templates\Windows Components\Windows Security\App and browser protection,” as it merely enforced a default that non-admins could not override.
• Enabled the new Microsoft Edge setting to prevent users from bypassing certificate error messages, bringing Edge in line with a similar setting for Internet Explorer.
• Removed the block against handling PKU2U authentication requests, as the feature is increasingly necessary.
• Removed the configuration of the “Create symbolic links” user rights assignment, as it merely enforced a default, was unlikely to be modified by a misguided administrator or for malicious purposes, and needs to be changed to a different value when Hyper-V is enabled.
• Removed the deny-logon restrictions against the Guests group as unnecessary: by default, the Guest account is the only member of the Guests group, and the Guest account is disabled. Only an administrator can enable the Guest account or add members to the Guests group.
• Removed the disabling of the xbgm (“Xbox Game Monitoring”) service, as it is not present in Windows 10 v1809. (By the way, consumer services such as the Xbox services have been removed from Windows Server 2019 with Desktop Experience!)
• Created and enabled a new custom MS Security Guide setting for the domain controller baseline, “Extended Protection for LDAP Authentication (Domain Controllers only),” which configures the LdapEnforceChannelBinding registry value described here.
• The Server 2019 baselines pick up all the changes accumulated in the four Windows 10 releases since Windows Server 2016.

We received and have been evaluating recommendations for more extensive changes to the baselines that we are continuing to evaluate for future releases.

We have replaced the collection of .cmd batch files for applying the baselines to local policy with a single PowerShell script that takes one of these five command-line switches to indicate which baseline you want to apply:

.\BaselineLocalInstall.ps1 -Win10DomainJoined      - for Windows 10 v1809, domain-joined

.\BaselineLocalInstall.ps1 -Win10NonDomainJoined   - for Windows 10 v1809, non-domain-joined

.\BaselineLocalInstall.ps1 -WS2019Member           - for Windows Server 2019, domain-joined

.\BaselineLocalInstall.ps1 -WS2019NonDomainJoined  - for Windows Server 2019, non-domain-joined

.\BaselineLocalInstall.ps1 -WS2019DomainController - for Windows Server 2019, domain controller

A couple of important notes about using the BaselineLocalInstall.ps1 script:

• PowerShell execution policy must be configured to allow script execution. You can configure this with a command line such as the following:
  Set-ExecutionPolicy RemoteSigned
• exe must be in the Tools subdirectory or somewhere in the Path. LGPO.exe is part of the Security Compliance Toolkit and can be downloaded from this URL:
  https://www.microsoft.com/download/details.aspx?id=55319

Windows 10 v1809 has greatly expanded its manageability using Mobile Device Management (MDM). The Intune team is preparing documentation about the Microsoft Windows MDM security baseline and how to use Intune to implement the baseline, and will publish it very soon. We will post information to this blog when that happens.

Long overdue post revisiting the question about whether and when to block the use of local accounts, particularly for remote administration.

Customers that deployed Microsoft’s security baseline for Windows 10 v1809 and Windows Server 2019 on systems with UEFI secure boot enabled might experience device boot failures. The Device Guard GPO setting to enable Virtualization Based Security in the Windows security configuration baselines includes enabling the System Guard Secure Launch (“ConfigureSystemGuardLaunch”) setting which on supported hardware protects the Virtualization Based Security environment from exploited vulnerabilities in device firmware. That setting was newly introduced in Windows 10 v1809 (also known as “Redstone 5” or “RS5”) and thus is only included in our recommended baselines for Windows 10 v1809 and Windows Server 2019. Microsoft discovered a boot issue that could affect systems with the System Guard Secure Launch set to enabled regardless of whether the underlying hardware support for the feature is present. The issue manifests itself after taking an update whereupon the device reboots into a blank screen. The issue has been root caused to a problem with catalog file validation and whether it shows up is highly dependent on set and order of signed components in the boot path so it is not predictable when or whether a system will hit this issue.

Microsoft is currently actively working to release a fix for this issue via a Windows update.

While Microsoft is working on a solution, Windows 10 v1809 and Windows Server 2019 customers who are affected may revert the “ConfigureSystemGuardLaunch” Group Policy setting to “Not Configured” or configure it to “Disabled” to alleviate this issue. This should be a temporary workaround until this issue is addressed in a Windows update.

Note: Removing this setting will not negatively impact systems that do not have the hardware support for System Guard Secure Launch. At the time of this blog post no devices have yet shipped that include hardware support for Secure Launch including all Microsoft Surface devices and any other OEM devices.  The first devices with this support included are not expected to be available on the market until the 2^nd quarter of calendar year 2019.