Windows 10: Security baseline (FINAL): Windows 10 and Windows Server, version 2004

Brink · Aug 4, 2020

We are pleased to announce the final release of the security configuration baseline settings for Windows 10 and Windows Server version 2004.

Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize and implement as appropriate. If you have questions or issues, please let us know via the Security Baseline Community.

This Windows 10 feature update brings very few new policy settings, which we list in the accompanying documentation. Only one new policy meets the criteria for inclusion in the security baseline (described below), and we are removing one setting from the baseline. There are two additional policies we are not including in the baseline because of compatibility concerns, but which you may want to consider for your organization.

LDAP Channel Binding Requirements (Policy updated)

In the Windows Server version 1809 Domain Controller baseline we created and enabled a new custom MS Security Guide setting called Extended Protection for LDAP Authentication (Domain Controllers only) based on the values provided here. This setting is now provided as part of Windows and no longer requires a custom ADMX. An announcement was made in March of this year and now all supported Active Directory domain controllers can configure this policy. The value will remain the same in our baseline, but the setting has moved to the new location. We are deprecating our custom setting. The new setting location is: Security Settings\Local Policies\Security Options\Domain controller: LDAP server channel binding token requirements.

Note: this new policy requires the March 10, 2020 security update. (We assume that, as security conscious baselines users, you are patching!) Details of that patch are here.

Microsoft Defender Antivirus File Hash (Worth considering)

Microsoft Defender Antivirus continues to enable new features to better protect consumers and enterprises alike. As part of this journey Windows has a new setting to compute file hashes for every executable file that is scanned, if it wasnât previously computed. You can find this new setting here: Computer Configurations\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MpEngine\Enable file hash computation feature.

You should consider using this feature to improve blocking for custom indicators in Microsoft Defender Advanced Threat Protection (MDATP). This new feature forces the engine to compute the full file hash for all executable files that are scanned. This can have a performance cost, which we minimize by only generating hashes on first sight. The scenarios where you may want to test more thoroughly for performance include devices where you frequently create new executable content (for example, developers) or where you install or update applications extremely frequently.

Because this setting is less helpful for customers who are not using MDATP, we have not added it to the baseline, but we felt it was potentially impactful enough to call out. If you chose to enable this setting, we recommend throttling the deployment to ensure you measure the impact on your usersâ machines.

Account Password Length (Worth considering)

In the Windows 10 1903 security baselines we announced the removal of the account password expiration policy. We continue to invest in improving this experience. With Windows 10 2004, two new security settings have been added for password policies: âMinimum password length auditâ and âRelax minimum password length limitsâ. These new settings can be found under Account Policies\Password Policy.

Previously, you could not require passwords/phrases greater than 14 characters. Now you can! Being able to require a length of more than 14 characters (maximum of 128) can help better secure your environment until you can fully implement a multi-factor authentication strategy. Our vision remains unchanged in achieving a password-less future, but we also recognize that this takes time to fully implement across both your users and your existing applications and systems.

You should be cautious with this new setting because it can potentially cause compatibility issues with existing systems and processes. Thatâs why we introduced the âMinimum password length auditâ setting, so you can see what will happen if you increase your password/phrase length. With auditing you can set your limit anywhere between 1 and 128. Three new events are also created as part of this setting and will be logged as new SAM events in the System event log: one event for awareness, one for configuration, and one for error.

This setting will not be added to the baseline as the minimum password length should be audited before broad enforcement due to the risk of application compatibility issues. However, we urge organizations to consider these two settings. Additional details about these new settings will be found here, once the new article get published in the coming days.

(NOTE: As of the today the link is not yet live, we are actively working to ensure it gets posted soon!)

As a reminder, length alone is not always the best predictor of password strength, so we strongly recommend considering solutions such as the on-premise Azure Active Directory Password Protection which does sub-string matching using a dictionary of known weak terms, and rejects passwords that donât meet a certain score.

Turn on Behavior Monitoring (Policy removed)

In keeping with our principals of criteria for baseline inclusion we have found that the following setting does not need to be enforced; there is no UI path to the setting, you must be a privileged account to make the change, lastly we do not feel a mis-informed Admin would change this setting. Based on these principals we are removing Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Turn on behavior monitoring

Tooling updates

Finally, we do have some enhancements for LGPO and Policy Analyzer coming very shortly after this release! We will go into more details on these enhancements in a future blog post!

Baseline criteria

We follow a streamlined and efficient approach to baseline definition when compared with the baselines we published before Windows 10. The foundation of that approach is essentially:

The baselines are designed for well-managed, security-conscious organizations in which standard end users do not have administrative rights.

A baseline enforces a setting only if it mitigates a contemporary security threat and does not cause operational issues that are worse than the risks they mitigate.

A baseline enforces a default only if it is otherwise likely to be set to an insecure state by an authorized user:

If a non-administrator can set an insecure state, enforce the default.

If setting an insecure state requires administrative rights, enforce the default only if it is likely that a misinformed administrator will otherwise choose poorly.

For further illustration, see the âWhy arenât we enforcing more defaults?â section in this blog post.

As always, please let us know your thoughts by commenting on this post.
Click to expand...

Source: https://techcommunity.microsoft.com/...n/ba-p/1543631

:)

Brink · Aug 4, 2020

Security baseline (DRAFT) for Windows 10 v1809 and Windows Server 2019

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 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.

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/d....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.
Click to expand...

Source: Security baseline (DRAFT) for Windows 10 v1809 and Windows Server 2019 Microsoft Security Guidance blog

Download: Windows-10-1809-Security-Baseline-DRAFT.zip

Brink · Aug 4, 2020

Security baseline (FINAL) for Windows 10 and Windows Server v1909 19H2

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 version 1909 (a.k.a., “19H2”), and for Windows Server version 1909. Note that Windows Server version 1909 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option.

Download the content from the Microsoft Security Compliance Toolkit (click Download and select “Windows 10 Version 1909 and Windows Server Version 1909 Security Baseline.zip”).

This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. None of them meet the criteria for inclusion in the baseline (which are reiterated below), but customers interested in controlling the use of USB drives and other devices should be interested in the new and very granular device installation restrictions. More about that later in this post.

The few changes we are making in the baseline since the September update to the version 1903 baselines are to remove a few settings that we have reevaluated: the restrictions on Thunderbolt devices in the BitLocker GPO, the enforcement of the default machine account password expiration for domain-joined systems, and the removal of the previously-recommended Exploit Protection settings.

Baseline criteria

To reiterate, we follow a streamlined and efficient approach to baseline definition when compared with the baselines we published before Windows 10. The foundation of that approach is essentially this:

The baselines are designed for well-managed, security-conscious organizations in which standard end users do not have administrative rights.

A baseline enforces a setting only if it mitigates a contemporary security threat and does not cause operational issues that are worse than the risks they mitigate.

A baseline enforces a default only if it is otherwise likely to be set to an insecure state by an authorized user:

If a non-administrator can set an insecure state, enforce the default.

If setting an insecure state requires administrative rights, enforce the default only if it is likely that a misinformed administrator will otherwise choose poorly.

For further illustration, see the “Why aren’t we enforcing more defaults?” section in this blog post.

Thunderbolt devices

First published in 2011, Microsoft Knowledge Base article 2516445 describes device installation restrictions for certain types of devices to mitigate DMA threats to BitLocker, including Thunderbolt devices. The BitLocker GPOs in our baselines have included these restrictions. Because Thunderbolt is popular, and newer computers can now mitigate that threat with kernel DMA protection – also in our baseline – we are removing the Thunderbolt restriction from our baseline. Customers on platforms that do not support kernel DMA protection can choose to continue blocking Thunderbolt, but we are no longer including it in our broad recommendations for all customers. For more information, see the KB article linked above and the articles to which it links.

Machine account password expiration

In Active Directory, each domain-joined computer has an Active Directory account with a strong, randomly-generated password. By default, these machine account passwords have a 30-day expiration, and computers automatically change their own passwords without any user involvement. Our baselines have always enforced these defaults. Note that reducing the expiration period will result in additional replication traffic. Also note that unlike with user account passwords, AD doesn’t actually enforce password expiration for computer accounts. Password expiration and change is driven entirely by client systems. The password remains valid until it gets changed, irrespective of how “Domain member: Maximum machine account password age” is configured.

A problem that occasionally crops up is that when a domain-joined virtual machine is reverted to an earlier state that is prior to its most recent password change, the older password is no longer recognized by the domain controller, the computer has no way to authenticate to the domain, and it thus loses domain trust. Domain accounts cannot authenticate to it remotely, and interactive logon with a domain account works only if the computer has a cached credential verifier for the account and the person logging in remembers which password was used when its verifier was cached. Typically when this happens, a LAPS-managed local account cannot be used either, as the local account password will also have been reverted and not match the newer one stored in Active Directory.

Non-persistent VDI implementations and devices with write filters that disallow permanent changes to the OS volume are also examples of scenarios where machine account password expiration is problematic. When such systems change their passwords in Active Directory and then revert to their previous passwords, they can no longer authenticate.

In the absence of issues such as these, we recommend leaving the default 30-day expiration in place. But following the baseline criteria stated above, we are removing the explicit enforcement of those defaults from our baselines. Situations that necessitate disabling machine account password expiration can now be handled without being out of compliance with our baselines.

The risks of turning off machine account password expiration are relatively low. To steal a computer account password, you must first have already gained full administrative control of the computer. Having a computer account’s password gives you only the ability to act as that computer on the network from other systems. For example, if Mary gets administrative control of CONTOSO\COMPUTER_ONE and extracts its domain account password (which is stored as an LSA secret), she can then connect to domain resources from CONTOSO\COMPUTER_TEN but pretending to be CONTOSO\COMPUTER_ONE. Default password expiration policy would limit her ability to do so to a maximum of 30 days. However, given that she had full control of COMPUTER_ONE, she could presumably go back in and retrieve its new password, or have applied nefarious techniques to disable password change, keeping the password valid indefinitely.

Exploit Protection

Because of reported compatibility issues with the Exploit Protection settings that we began incorporating with the Windows 10 v1709 baselines, we have elected to remove the settings from the baseline and to provide a script for removing the settings from machines that have had those settings applied. (See Remove-EPBaselineSettings.ps1 in the download package’s Scripts folder.)

New device installation restrictions available

For many years, Windows has enabled administrators to allow or block devices such as external USB drives based on attributes such as vendor and product IDs. Windows now also enables control at a far more granular level: device instance IDs. For example, you could have ten identical thumb drives of the same brand, model, and capacity, pick two of them, and create a policy that allows just those to be mounted; the others would be blocked.

Because the way these settings would be configured are always specific to each customer’s situation, we don’t configure them in our baselines. But we wanted to highlight their availability as a major improvement in Windows’ device control.

You can configure the new “Allow installation of devices that match any of these device instance IDs” and “Prevent installation of devices that match any of these device instance IDs” Group Policy settings in Computer Configuration\Administrative Templates\System\Device Installation\Device Installation Restrictions. For more information, also see How to control USB devices and other removable media using Microsoft Defender ATP.
Click to expand...

Source: https://techcommunity.microsoft.com/...r/ba-p/1023093

Brink · Aug 4, 2020

Security baseline (DRAFT) for Windows 10 and Windows Server v2004

Microsoft is pleased to announce the draft release of the security configuration baseline settings for Windows 10 and Windows Server version 2004.

Please download the draft baseline (attached to this post), evaluate the proposed baselines, and leave us your comments/feedback below.

This Windows 10 feature update brings very few new policy settings, which we list in the accompanying documentation. Only one new policy meets the criteria for inclusion in the security baseline (described below), but there are two other policies we want to highlight for your consideration.

In the Windows Server version 1809 Domain Controller baseline we created and enabled a new custom MS Security Guide setting called Extended Protection for LDAP Authentication (Domain Controllers only) based on the values provided here. This setting is now provided as part of Windows and no longer requires a custom ADMX. An announcement was made in March of this year and now all supported Active Directory domain controllers can configure this policy. The value will remain the same in our baseline, but the setting has moved to the new location. We are deprecating our custom setting. The new setting location is: Security Settings\Local Policies\Security Options\Domain controller: LDAP server channel binding token requirements.

Note: this new policy requires the March 10, 2020 security update. (We assume that, as security conscious baselines users, you are patching!) Details of that patch are here.

Microsoft Defender Antivirus continues to enable new features to better protect consumers and enterprises alike. As part of this journey we have added a new setting to compute file hashes for every executable file that is scanned, if it wasn’t previously computed. You can find this new setting here: Computer Configurations\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MpEngine\Enable file hash computation feature.

You should consider using this feature to improve blocking for custom indicators in Microsoft Defender Advanced Threat Protection (MDATP). This new feature forces the engine to compute the full file hash for all executable files that are scanned. This can have a performance cost but we are trying to keep it to a minimum by only generating hashes on first sight. The scenarios where performance might be impacted would be new executable content being generated (for example, developers) or where you frequently install or update applications.

Because this setting is less helpful for customers who are not using MDATP, we have not added it to the baseline, but we felt it was potentially impactful enough to call out. If you chose to enable this setting, we recommend throttling the deployment to ensure you measure the impact on your users’ machines.

In the Windows 10 1903 security baselines we announced the removal of the account password expiration policy. We continue to invest in improving this experience. With Windows 10 2004, two new security settings have been added for password policies: ‘Minimum password length audit’ and ‘Relax minimum password length limits’. These new settings can be found under Account Policies\Password Policy.

Previously, you could not require passwords/phrase greater than 14 characters. Now you can! Being able to require a length of more than 14 characters (maximum of 128) can help better secure your environment until you can fully implement a multi-factor authentication strategy. Our vision remains unchanged in achieving a password-less future, but we also recognize that this takes time to fully implement across both your users and your existing applications and systems.

You should be cautious with this new setting because it can potentially cause compatibility issues with existing systems and processes. That’s why we introduced the ‘Minimum password length audit’ setting, so you can see what will happen if you increase your password/phrase length. With auditing you can set your limit anywhere between 1 and 128. Three new events are also created as part of this setting and will be logged as new SAM events in the System event log: one event for awareness, one for configuration, and one for error.

This setting will not be added to the baseline as the minimum password length should be audited before broad enforcement due to the risk of application compatibility issues. However, we urge organizations to consider these two settings. Additional details about these new settings will be found here, once the new article get published in the coming days.

As a reminder, length alone is not always the best predictor of password strength, so we strongly recommend considering solutions such as the on-premise Azure Active Directory Password Protection which does sub-string matching using a dictionary of known weak terms, and rejects passwords that don’t meet a certain score.

Finally, we do have some enhancements for LGPO and Policy Analyzer coming. We will go into more details on these enhancements in a future blog post!

We follow a streamlined and efficient approach to baseline definition when compared with the baselines we published before Windows 10. The foundation of that approach is essentially:

The baselines are designed for well-managed, security-conscious organizations in which standard end users do not have administrative rights.

A baseline enforces a setting only if it mitigates a contemporary security threat and does not cause operational issues that are worse than the risks they mitigate.

A baseline enforces a default only if it is otherwise likely to be set to an insecure state by an authorized user:

If a non-administrator can set an insecure state, enforce the default.

If setting an insecure state requires administrative rights, enforce the default only if it is likely that a misinformed administrator will otherwise choose poorly.

For further illustration, see the “Why aren’t we enforcing more defaults?” section in this blog post.

As always, please let us know your thoughts by commenting on this post.

Windows-10-Windows Server-v2004-Security-Baseline-DRAFT.zip

Download
Click to expand...

Source: https://techcommunity.microsoft.com/...4/ba-p/1419213

Windows 10: Security baseline (FINAL): Windows 10 and Windows Server, version 2004

Security baseline (FINAL): Windows 10 and Windows Server, version 2004

Security baseline (FINAL): Windows 10 and Windows Server, version 2004

Security baseline (FINAL): Windows 10 and Windows Server, version 2004

Security baseline (FINAL): Windows 10 and Windows Server, version 2004 - Similar Threads - Security baseline FINAL

Security baseline FINAL for Windows 10 version 21H1

Security baseline (FINAL) Windows 10 and Windows Server version 20H2

Security baseline (DRAFT): Windows 10 and Windows Server version 20H2

Security baseline (DRAFT) for Windows 10 and Windows Server v2004

Security baseline (FINAL) for Chromium-based Microsoft Edge, version 7

Security baseline (FINAL) for Windows 10 and Windows Server v1909 19H2

Security baseline (Sept2019Update) for Windows 10 version 1903

[sandbox] loss of connectivity after deployment of Security baseline (FINAL) for Windows 10...

Security baseline (FINAL) for Windows 10 v1903 & Windows Server v1903