Archive

Author Archive

Security baseline for Microsoft Edge v80

March 17th, 2020 No comments

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 80. The settings recommended in this baseline are the same as the ones we recommended in version 79, with the additional of one new setting that we have added and that will discuss. We continue to welcome feedback through the Baselines Discussion site.


 


The one addition to this baseline since version 79 is that we have added the recommendation to enforce a new setting “Configure Microsoft Defender SmartScreen to block potentially unwanted apps”.  Potentially Unwanted Apps (PUA) was first introduced with our Microsoft Defender Antivirus (MDAV) baseline as part of Windows 10.  PUA are not considered viruses, malware, or other types of threats, but they might perform actions on endpoints which adversely affect endpoint performance or use (such as adware or other low-reputation applications, you can see more PUA criteria here).  Starting with Microsoft Edge 80, you can now block PUA downloads and associated resource URLs.  By default, PUA is an opt-in setting, meaning a user must deliberately configure this.  Well-managed enterprises should ensure positive control of necessary security settings, and therefore we have enabled this setting as part of the baseline (as we have with the MDAV recommendation).


 


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


 


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.

Categories: Uncategorized Tags:

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

January 15th, 2020 No comments

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.

Categories: Uncategorized Tags:

Security baseline (DRAFT) for Chromium-based Microsoft Edge, version 79

December 13th, 2019 No comments

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for the next version of Microsoft Edge based on Chromium, version 79. Please evaluate this proposed baseline and send us your feedback through the Baselines Discussion site.


 


The settings recommended in this baseline are identical to the ones we recommended in the version 78 draft. None of the settings introduced in the version 79 policies meet the bar for inclusion in the baseline for broad use. We are republishing the baseline package because the names of several of the recommended settings were changed (for example, references to “SSL” were replaced with “HTTPS” or “TLS”).


 


Like all our baseline packages, the downloadable draft baseline package (attached to this blog post) 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. It also includes a spreadsheet showing the changes in the available GPO settings between versions 78 and 79.


 


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 217 enforceable Computer Configuration policy settings and another 201 User Configuration policy settings. Following our streamlined approach, our recommended baseline configures a grand total of twelve Group Policy settings. You can find full documentation in the download package’s Documentation subdirectory.


 

Categories: Uncategorized Tags:

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

November 20th, 2019 No comments

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.

Categories: Uncategorized Tags:

Security baseline (DRAFT) for Chromium-based Microsoft Edge, version 78

October 24th, 2019 No comments

Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for the next version of Microsoft Edge based on Chromium, version 78. Please evaluate this proposed baseline and send us your feedback through the Baselines Discussion site.


 


Like all our baseline packages, the downloadable draft baseline package (attached to this blog post) 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 78 of the Chromium-based version of Microsoft Edge has 205 enforceable Computer Configuration policy settings and another 190 User Configuration policy settings. Following our streamlined approach, our recommended baseline configures a grand total of twelve Group Policy settings. You can find full documentation in the download package’s Documentation subdirectory.


 

Categories: Uncategorized Tags:

Security baseline (Sept2019Update) for Windows 10 v1903 and Windows Server v1903

October 3rd, 2019 No comments

We have updated our Windows 10 v1903 and Windows Server v1903 security configuration baseline recommendations to address some issues:



  • The first and most important change is that we are removing the Computer Configuration setting, “Enable svchost.exe mitigation options” (in System\Service Control Manager Settings\Security Settings) from the Windows 10 and Windows Server baselines at this time because of reports that in its current implementation it causes more compatibility issues than we had anticipated.

  • We have also adjusted a few auditing settings in the Domain Controller baseline to align more closely with recommendations in the Windows 10 and Windows Server 2016 security auditing and monitoring reference document (also reflected here). Those changes are:




































Audit category Audit subcategory Was Now
Audit Policy\Account Logon Credential Validation Success and Failure Failure
Audit Policy\Account Logon Kerberos Service Ticket Operations   Failure
Audit Policy\DS Access Directory Service Access Success and Failure Failure
Audit Policy\DS Access Directory Service Changes Success and Failure Success


 


We have also added a Baseline-ADImport.ps1 PowerShell script to import all the baseline’s GPOs into Active Directory Group Policy, and improved other scripts, including preventing the local-policy script from running on Domain Controllers.

Categories: Uncategorized Tags:

Security baseline for Office 365 ProPlus (v1908, Sept 2019) – FINAL

September 24th, 2019 No comments

Microsoft is pleased to announce the final release of the recommended security configuration baseline settings for Microsoft Office 365 ProPlus, version 1908. Please evaluate this proposed baseline and send us your feedback through the Baselines Discussion site.


This baseline builds on the overhauled Office baseline we released in early 2018. The highlights of this baseline include:



  • Componentization of GPOs so that “challenging” settings can be added or removed as a unit.

  • Comprehensive blocking of legacy file formats

  • Blocking Excel from using Dynamic Data Exchange (DDE)


Also see the announcements at the end of this post regarding the new Security Policy Advisor and Office cloud policy services.


Download the content from the Security Compliance Toolkit.


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, 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 365 ProPlus administrative templates version 4909 released on September 5, 2019 that can be downloaded here.


Componentization of GPOs


Most organizations can implement most of the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We have broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script, Baseline-LocalInstall.ps1, offers command-line options to control whether these GPOs are installed.


The “MSFT Office 365 ProPlus 1907” GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs, each of which is described later:



  • “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from opening or saving legacy file formats.

  • “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.

  • “Excel DDE Block – User” is a User Configuration GPO that blocks Excel from using DDE to search for existing DDE server processes or to start new ones.


Comprehensive blocking of legacy file formats


In the previous Office baseline we published, we tried to end the use of legacy file formats, including all the old Office document formats such as *.doc, *.xls, and *.ppt. However, we missed some important ones. So we just went ahead and fixed the glitch.


One of the threats of these old binary file formats is that their inherent complexity too often led to exploitable bugs in their parsers. The bigger threat is that many of these formats can include macros or other executable instructions that are easily abused. By contrast, macros are disabled with the most-commonly used Office Open XML (OOXML) document formats, which were first introduced with Office 2007. Only macro-enabled formats such as *.docm and *.xlsm support macros, and these can be filtered at the point of ingress.


While fixing the glitch, however, we also recognized that many organizations cannot entirely end their use of legacy Office document formats, so we broke out the file-blocking settings into a separate GPO, so they can be added or removed as a cohesive unit.


Blocking Excel from using DDE


Dynamic Data Exchange (DDE) is a very old interprocess communication method that is still used in some parts of Windows and remains supported for applications to use, primarily for backward compatibility. A few years ago, malware authors began embedding specially-formed DDE references in Office documents that were sent to victims and that would run attacker-chosen code. Since then, most Office apps have disabled the use of DDE. Excel by default blocks the ability to launch arbitrary DDE servers and now also supports user-configurable settings to enable DDE server process lookup and launch. These can now be configured through Group Policy, and this baseline recommends disabling both settings. Because of the likelihood that some organizations still depend on this functionality, we have broken out “Excel DDE Block” as a separate GPO.


Macro signing


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 have decided at this time to move these settings into a separate GPO to make it easier to switch the settings on or off without affecting the rest of the baseline.


Note that the “Block macros from running in Office files from the Internet” settings we turned on in the previous baseline are retained in the main GPOs and should be enforced by all security-conscious organizations.


Also see below about how the new Security Policy Advisor service can provide tailored recommendations for VBA macro policies.


Other changes in the baseline


“Block macros from running in Office files from the Internet” is now supported for Access, so we added it.


Implemented new settings to block the opening of certain untrusted files and to open others in Protected View.


Enabled the new “Macro Runtime Scan Scope” setting.


Removed the file block setting for “PowerPoint beta converters,” as Office no longer implements that block.


Changes in the baseline since the draft release


First, thanks to everyone who took the time to evaluate our draft baseline and provide us with feedback. Based on your feedback, we have made several minor adjustments to the baseline since publishing the draft release in July:



  • Changed several User Configuration settings from “Disabled” to Enabled with specific choices, as we have found that doing so is more effective at enforcing the desired policies:































Path



Policy Name



New value



Microsoft Office 2016\Security Settings



ActiveX Control Initialization



Enabled + 6



Microsoft Office 2016\Security Settings



Load Controls in Forms3



Enabled + 1



Microsoft Outlook 2016\Security\Security Form Settings\Attachment Security



Remove file extensions blocked as Level 1



Enabled + empty list of extensions



Microsoft Outlook 2016\Security\Security Form Settings\Attachment Security



Remove file extensions blocked as Level 2



Enabled + empty list of extensions



 



  • Removed the User Configuration setting, “Configure trusted add-ins” (in Microsoft Outlook 2016\Security\Security Form Settings\Programmatic Security\Trusted Add-ins) from the baseline, as we determined that it did not mitigate a contemporary security threat. In particular, the concept of “trusted” merely grants the COM add-in the ability to invoke Outlook Object Model interfaces without triggering user prompts. However, these add-ins can’t be installed without administrative privileges, and once installed they can also invoke more powerful Extended MAPI interfaces without triggering prompts.



  • Removed the User Configuration setting, “Always open untrusted text-based files in Protected View” (in Microsoft Excel 2016\Excel Options\Security\Trust Center\Protected View) for the time being, as we discovered a bug in its implementation. We anticipate adding this policy control back into the baseline at a later time.



  • Removed the User Configuration setting, “Excel 2007 and later binary workbooks” (in Microsoft Excel 2016\Excel Options\Security\Trust Center\File Block Settings) because it’s not needed to block legacy Excel file formats (unlike the similarly-titled Word policy) and it blocks use of the Personal Macro Workbook (personal.xlsb).


Deploy policies from the cloud, and get tailored recommendations for specific security policies


In addition to being able deploy these policies through Active Directory Group Policy or through Local Group Policy, you now have a new way to deploy user-based policies from the cloud to any Office 365 ProPlus client through the new Office cloud policy service.


The Office cloud policy service allows administrators to define policies for Office 365 ProPlus and assign these policies to users via Azure Active Directory security groups. Once defined, policies are automatically enforced as users sign in and use Office 365 ProPlus. No need to be domain joined or MDM enrolled, and it works with corporate-owned devices or BYOD. To learn more about Office cloud policy service, check out the announcement here: https://aka.ms/ocpsannouncement.


We also have a new service called Security Policy Advisor that can help you with deploying security policies. Security Policy Advisor can provide you with tailored recommendations for specific security policies based on how Office is used in your enterprise. For example, in most customer environments, macros are typically used in specific apps such as Excel and only by specific groups of users. Security Policy Advisor can help you identify groups of users and applications where macros can be disabled with minimal productivity impact, and optionally integrate with Office 365 Advanced Threat Protection to provide you information on who is being attacked. To learn more about Security Policy Advisor, check out the announcement here: https://aka.ms/spaannouncement.


 


 


 

Categories: Uncategorized Tags:

Security baseline for Office 365 ProPlus (v1907, July 2019) – DRAFT

July 24th, 2019 No comments

[Update, 24 September 2019: final version of this baseline released and is now available as part of the Security Compliance Toolkit.]


 


Microsoft is pleased to announce the draft release of the recommended security configuration baseline settings for Microsoft Office 365 ProPlus, version 1907. Please evaluate this proposed baseline and send us your feedback through the Baselines Discussion site.


 


This baseline builds on the overhauled Office baseline we released in early 2018. The highlights of this baseline include:



  • Componentization of GPOs so that “challenging” settings can be added or removed as a unit.

  • Comprehensive blocking of legacy file formats

  • Blocking Excel from using Dynamic Data Exchange (DDE)


Also see the announcements at the end of this post regarding the new Security Policy Advisor and Office cloud policy services.


 


The downloadable attachment to this blog post includes importable GPOs, a script to apply 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 365 ProPlus administrative templates version 4888 released on July 17, 2019 that can be downloaded here. The download for the final version of this baseline will be released through the Security Compliance Toolkit.


 


Componentization of GPOs


Most organizations can implement most of the baseline’s recommended settings without any problems. However, there are a few settings that will cause operational issues for some organizations. We have broken out related groups of such settings into their own GPOs to make it easier for organizations to add or remove these restrictions as a set. The local-policy script, BaselineLocalInstall.ps1, offers command-line options to control whether these GPOs are installed.


The “MSFT Office 365 ProPlus 1907” GPO set includes “Computer” and “User” GPOs that represent the “core” settings that should be trouble free, and each of these potentially challenging GPOs, each of which is described later:



  • “Legacy File Block – User” is a User Configuration GPO that prevents Office applications from loading or saving legacy file formats.

  • “Require Macro Signing – User” is a User Configuration GPO that disables unsigned macros in each of the Office applications.

  • “Excel DDE Block – User” is a User Configuration GPO that blocks Excel from using DDE to search for existing DDE server processes or to start new ones.


 


Comprehensive blocking of legacy file formats


In the previous Office baseline we published, we tried to end the use of legacy file formats, including all the old Office document formats such as *.doc, *.xls, and *.ppt. However, we missed some important ones. So we just went ahead and fixed the glitch.


 


One of the threats of these old binary file formats is that their inherent complexity too often led to exploitable bugs in their parsers. The bigger threat is that many of these formats can include macros or other executable instructions that are easily abused. By contrast, macros are disabled with the most-commonly used Office Open XML (OOXML) document formats, which were first introduced with Office 2007. Only macro-enabled formats such as *.docm and *.xlsm support macros, and these can be filtered at the point of ingress.


 


While fixing the glitch, however, we also recognized that many organizations cannot entirely end their use of legacy Office document formats, so we broke out the file-blocking settings into a separate GPO, so they can be added or removed as a cohesive unit.


 


Blocking Excel from using DDE


Dynamic Data Exchange (DDE) is a very old interprocess communication method that is still used in some parts of Windows and remains supported for applications to use, primarily for backward compatibility. A few years ago, malware authors began embedding specially-formed DDE references in Office documents that were sent to victims and that would run attacker-chosen code. Since then, most Office apps quietly disabled the use of DDE. Excel retained user-configurable settings to enable DDE server process lookup and launch. These can now be configured through Group Policy, and this baseline recommends disabling both settings. Because of the likelihood that some organizations still depend on this functionality, we have broken out “Excel DDE Block” as a separate GPO.


 


Macro signing


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 have decided at this time to move these settings into a separate GPO to make it easier to switch the settings on or off without affecting the rest of the baseline.


 


Note that the “Block macros from running in Office files from the Internet” settings we turned on in the previous baseline are retained in the main GPOs and should be enforced by all security-conscious organizations.


 


Also see below about how the new Security Policy Advisor service can provide tailored recommendations for VBA macro policies.


 


Other changes in the baseline



  • “Block macros from running in Office files from the Internet” is now supported for Access, so we added it.

  • Implemented new settings to block the opening of certain untrusted files and to open others in Protected View.

  • Enabled the new “Macro Runtime Scan Scope” setting.

  • Removed the file block setting for “PowerPoint beta converters,” as Office no longer implements that block.


 


Deploy policies from the cloud, and get tailored recommendations for specific security policies


In addition to being able deploy these policies through Active Directory Group Policy or through Local Group Policy, you now have a new way to deploy user-based policies from the cloud to any Office 355 ProPlus client through the new Office cloud policy service.


 


The Office cloud policy service allows administrators to define policies for Office 365 ProPlus and assign these policies to users via Azure Active Directory security groups. Once defined, policies are automatically enforced as users sign in and use Office 365 ProPlus. No need to be domain joined or MDM enrolled, and it works with corporate-owned devices or BYOD. To learn more about Office cloud policy service, check out the announcement here: https://aka.ms/ocpsannouncement.


 


We also have a new service in public preview called Security Policy Advisor that can help you with deploying security policies. Security Policy Advisor can provide you with tailored recommendations for specific security policies based on how Office is used in your enterprise. For example, in most customer environments, macros are typically used in specific apps such as Excel and only by specific groups of users. Security Policy Advisor can help you identify groups of users and applications where macros can be disabled with minimal productivity impact, and optionally integrate with Office 365 Advanced Threat Protection to provide you information on who is being attacked. To learn more about Security Policy Advisor, check out the announcement here: https://aka.ms/spaannouncement.

Categories: Uncategorized Tags:

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

June 18th, 2019 No comments

First published on TechNet on May 23, 2019
Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 version 1903 (a.k.a., “19H1”), and for Windows Server version 1903.

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

Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes.

This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. This baseline recommends configuring only two of those. However, we have made several changes to existing settings, including some changes since the draft version of this baseline that we published last month.

The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:




    • Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins. [Update 3 October 2019: we have republished the baseline with this setting removed.]



 




    • Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.



 




    • Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.



 




    • Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.



 




    • Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.



 




    • Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.



 




    • Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.



 




    • Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here .





Additional changes that we have adopted since publishing the draft version of this baseline include:




    • Dropping the enforcement of the default behavior of disabling the built-in Administrator and Guest accounts. We had floated this proposal at the time of the draft baseline, and have since decided to accept it. The change is discussed in more detail below.



 




    • Dropped a Windows Defender Antivirus setting that applies only to legacy email file formats.



 




    • Changed the Windows Defender Exploit Protection XML configuration to allow Groove.exe (OneDrive for Business) to launch child processes, particularly MsoSync.exe which is necessary for file synchronization.





Dropping the password expiration policies.

There’s no question that the state of password security is problematic and has been for a long time. When humans pick their own passwords, too often they are easy to guess or predict. When humans are assigned or forced to create passwords that are hard to remember, too often they’ll write them down where others can see them. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords. When passwords or their corresponding hashes are stolen, it can be difficult at best to detect or restrict their unauthorized use.

Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection ) and multi-factor authentication. While we recommend these alternatives, they cannot be expressed or enforced with our recommended security configuration baselines, which are built on Windows’ built-in Group Policy settings and cannot include customer-specific values.

This reinforces a larger important point about our baselines: while they are a solid foundation and should be part of your security strategy, they are not a complete security strategy. In this particular case, the small set of ancient password policies enforceable through Windows’ security templates is not and cannot be a complete security strategy for user credential management. Removing a low-value setting from our baseline and not compensating with something else in the baseline does not mean we are lowering security standards. It simply reinforces that security cannot be achieved entirely with baselines.

Why are we removing password-expiration policies?

First, to try to avoid inevitable misunderstandings, we are talking here only about removing password-expiration policies – we are not proposing changing requirements for minimum password length, history, or complexity.

Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem.

If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time ? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you.

Our baselines are intended to be usable with minimal if any modification by most well-managed, security-conscious enterprises. They are also intended to serve as guidance for auditors. So, what should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration?

The results of baseline compliance scans are usually measured by how many settings are out of compliance: “How much red do we have on the chart?” It is not unusual for organizations during audit to treat compliance numbers as more important than real-world security. If a baseline recommends 60 days and an organization with advanced protections opts for 365 days – or no expiration at all – they will get dinged in an audit unnecessarily and might be compelled to adhere to the 60-day recommendation.

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Dropping the enforced disabling of the built-in Administrator and Guest accounts

To keep baselines useful and manageable, we tend to enforce secure defaults for policy settings only when 1) non-administrative users could otherwise override those defaults, or 2) misinformed administrators are otherwise likely to make poor choices about the setting. Neither of those conditions are true regarding enforcing the default disabling of the Administrator and Guest accounts. Note that removing these settings from the baseline does not mean that we recommend that these accounts be enabled, nor does removing these settings mean that the accounts will be enabled. Removing the settings from the baselines simply means that administrators can now choose to enable these accounts as needed.

The built-in Guest account. The Guest account (RID -501) is disabled by default on Windows 10 and Windows Server. Only an administrator can enable the Guest account, and an admin would presumably do so only for a valid reason such as for a kiosk system.

The built-in Administrator account. The local Administrator account (RID -500) is disabled by default on Windows 10 but not on Windows Server. When installing Windows 10, Windows Setup prompts you for a new account which becomes the primary administrative account for the computer. By contrast, Windows Server’s setup prompts you for a new password for the Administrator account. The main differences between the built-in -500 Administrator account (when enabled) and a custom administrative local account are 1) the -500 account is not subject to account lockout, account expiration, password expiration, or logon hours; 2) the -500 account cannot be removed from the Administrators group; and 3) that by default the -500 account always runs with full administrative rights without UAC prompts, including over the network. This third difference can be removed (as our baselines always do) by enabling the security option, “User Account Control: Admin Approval Mode for the Built-in Administrator account.”

Our recommendations for administrative local accounts include:




    • You can choose not to have any administrative local accounts enabled and to administer domain-joined systems only with domain accounts.



 




    • If you choose to use local accounts for computer administration, you should have only one administrative local account enabled per computer. With this change in the baseline, you can choose to use the -500 Administrator account or a custom account, according to your needs. Note that if you rely on account lockout for defense against password-guessing attacks, you should not enable the -500 account – and you should consider disabling it on Windows Server.



 




    • The administrative local account’s password should be strong and should be different from the same account’s password on every other computer. We recommend the Local Administrator Password Solution (LAPS) or a similar tool to ensure that passwords are random and strong. LAPS can manage the password of the -500 account or a custom named local account on Active Directory domain-joined Windows clients and domain-joined member servers (but not for Domain Controllers). Note also that LAPS’ password-expiration enforcement is independent from Windows’ password-expiration mechanism, and always applies to whatever account LAPS manages.



 




    • Renaming the Administrator account is perfectly fine but is “security by obscurity.” Renaming is easy to do through Group Policy and doing so can mitigate some threats, but it’s less than a speedbump against other threats.



 

Categories: Uncategorized Tags: