Windows 10: Security baseline FINAL for Windows 10 version 21H1

Brink · May 18, 2021

We are pleased to announce the final release of the Windows 10, version 21H1 (a.k.a. May 2021 Update) security baseline package! Please download the content from the Microsoft Security Compliance Toolkit, test the recommended configurations, and customize / implement as appropriate.

This Windows 10 feature update brings very few new policy settings. At this point, no new 21H1 policy settings meet the criteria for inclusion in the security baseline. We are, however, refreshing the package to ensure the latest content is available to you. The refresh contains an updated administrative template for SecGuide.admx/l (that we released with Microsoft 365 Apps for Enterprise baseline), new spreadsheets, .PolicyRules file, along with a script change (commented out the Windows Server options in the Baseline-LocalInstall.ps1 script)

Windows 10, version 21H1 is a client only release. Windows Server, version 20H2 is the current Windows Server Semi-Annual Channel release and per our lifecycle policy is supported until May 10, 2022.

As a reminder, our security baselines for the endpoint also include Microsoft 365 Apps for Enterprise, which we recently released, as well as Microsoft Edge and Windows Update.

Please let us know your thoughts by commenting on this post or via the Security Baseline Community.

Source: https://techcommunity.microsoft.com/...1/ba-p/2362353

:)

Brink · May 18, 2021

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

We are pleased to announce the final release of the for Windows 10 and Windows Server, version 20H2 (a.k.a. October 2020 Update) security baseline package!

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. At this point, no new 20H2 policy settings meet the criteria for inclusion in the security baseline, but there are a few policies we are going to be making changes to, which we highlight below along with our recommendations.

Tip: If you read the Draft release, we will save you another read. There are no changes since the draft to the actual settings. There were two small changes to the package though; the Baseline-LocalInstall.ps1 script has a change to error handling (thanks to a community member’s suggestion) and second, we neglected to include the custom ADMX/L files in the GP Reports so they showed up as additional registry keys which is now fixed also.

Block at first sight

Enable or Disable Microsoft Defender Antivirus Block at First Sight

We started the journey for cloud protection several years ago. Based on our analysis of the security value versus the cost of implementation, we feel it’s time to add Microsoft Defender Antivirus’ Block At First Sight (BAFS) feature to the security baseline. BAFS was first introduced in Windows 10, version 1607 and allows new malware to be detected and blocked within seconds by leveraging various machine learning techniques and the power of our cloud.

BAFS currently requires 6 settings to be configured. Our baseline already sets 2 of them, Join Microsoft MAPS and Send file sample when further analysis is required. We are now recommending the addition of the following settings to enable BAFS:

Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MAPS\Configure the ‘Block at first sight’ feature set to Enabled

Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Scan all downloaded files and attachments set to Enabled

Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Turn off real-time protection set to Disabled

Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MPEngine\Select cloud protection level set to High blocking level

These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.

Additional details on BAFS can be found here.

Attack Surface Reduction Rules
We routinely evaluate our Attack Surface Reduction configuration, and based on telemetry and customer feedback we are now recommending configuring two additional Attack Surface Reduction controls: Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Microsoft Defender Exploit Guard\Attack Surface Reduction\Configure Attack Surface Reduction rules: Use advanced protection against ransomware and Block persistence through WMI event subscription.

Introduced in Windows 10, version 1709 the Use advanced protection against ransomware rule will scan any executable files and determine, using advanced cloud analytics, if the file looks malicious . If so, it will be blocked unless that file is added to an exclusion list. This rule does have a cloud dependency, so you must have Join Microsoft MAPS also configured (which is already part of the security baseline).

Block persistence through WMI event subscription is a rule that was released in Windows 10, version 1903. This rule attempts to ensure WMI persistence is not achieved - a common technique adversaries use to evade detection. Unlike many of the other ASR rules, this rule does not allow any sort of exclusions since it is solely based on the WMI repository.

A friendly reminder that the security baselines set all ASR rules to block mode. We recommend first configuring them to audit mode, then testing to ensure you understand the impacts these rules will have in your environment, and then configuring them to block mode. Microsoft Defender for Endpoints (formally Microsoft Defender Advanced Threat Protection, MDATP) will greatly enhance the experience of testing, deployment, and operation of ASR rules. We would encourage you to look at evaluating, monitoring and customizing links to better prepare your environment.

These new settings have been added to the MSFT Windows 10 20H2 and Server 20H2 – Defender Antivirus group policy.

UEFI MAT
You might recall in the draft release of our security baseline for Windows 10, version 1809 we enabled UEFI Memory Attributes Tables, but based on your feedback we removed that recommendation from the final version. After further testing and discussions, we are recommending that you enable Computer Configuration\Administrative Templates\System\Device Guard\Turn on Virtualization Based Security\Require UEFI Memory Attributes Table.

Microsoft Edge
Starting with Windows 10, version 20H2 the new Microsoft Edge (based on Chromium) is now installed as part of the operating system. Please ensure you are applying the security baseline for Microsoft Edge to your Windows 10, version 20H2 machines. We have gotten questions about including it on the Windows security baseline, but since Microsoft Edge is a cross platform product and has a different release cadence, we are going to keep it a separate security baseline.

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

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

Brink · May 18, 2021

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

Microsoft is pleased to announce the enterprise-ready release of the recommended security configuration baseline settings for the next version of Microsoft Edge based on Chromium, version 79. The settings recommended in this baseline are identical to the ones we recommended in the version 79 draft, minus one setting that we have removed and that we discuss below. We continue to welcome feedback through the Baselines Discussion site.

The baseline package is now available as part of the Security Compliance Toolkit. Like all our baseline packages, the downloadable baseline package includes importable GPOs, a script to apply the GPOs to local policy, a script to import the GPOs into Active Directory Group Policy, and all the recommended settings in spreadsheet form, as Policy Analyzer rules, and as GP Reports.

Microsoft Edge is being rebuilt with the open-source Chromium project, and many of its security configuration options are inherited from that project. These Group Policy settings are entirely distinct from those for the original version of Microsoft Edge built into Windows 10: they are in different folders in the Group Policy editor and they reference different registry keys. The Group Policy settings that control the new version of Microsoft Edge are located under “Administrative Templates\Microsoft Edge,” while those that control the current version of Microsoft Edge remain located under “Administrative Templates\Windows Components\Microsoft Edge.” You can download the latest policy templates for the new version of Microsoft Edge from the Microsoft Edge Enterprise landing page. To learn more about managing the new version of Microsoft Edge, see Configure Microsoft Edge for Windows.

As with our current Windows and Office security baselines, our recommendations for Microsoft Edge configuration 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 explanation, see the “Why aren’t we enforcing more defaults?” section in this blog post.)

Version 79 of the Chromium-based version of Microsoft Edge has 216 enforceable Computer Configuration policy settings and another 200 User Configuration policy settings. Following our streamlined approach, our recommended baseline configures a grand total of eleven Group Policy settings. You can find full documentation in the download package’s Documentation subdirectory.

The one difference between this baseline and the version 79 draft is that we have removed the recommendation to disable “Force Microsoft Defender SmartScreen checks on downloads from trusted sources.” By default, SmartScreen will perform these checks. While performing checks on files from trusted sources increases the likelihood of false positives – particularly from intranet sources that host files that are seldom if ever seen in the outside world – we have decided not to apply that decision to all customers adopting our baseline. Depending on who can store files in locations that are considered “trusted sources” and the rigor they apply to restricting what gets stored there, internal sites might in fact end up hosting untrustworthy content that should be checked. Our baseline therefore neither enables nor disables the setting. Organizations choosing to disable this setting can therefore do so without contradicting our baseline recommendations.
Click to expand...

Source: https://techcommunity.microsoft.com/...e/ba-p/1111863

Brink · May 18, 2021

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

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

Windows 10: Security baseline FINAL for Windows 10 version 21H1

Security baseline FINAL for Windows 10 version 21H1

Security baseline FINAL for Windows 10 version 21H1

Security baseline FINAL for Windows 10 version 21H1

Security baseline FINAL for Windows 10 version 21H1 - Similar Threads - Security baseline FINAL

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

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

Security baseline released for Microsoft Edge version 85

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

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

Users found this page by searching for:

security analyzer 21h1