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.
(Note: the final version of this baseline was published 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 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.