New Contributor

A bit of feedback on the "Security baseline for Office 365 ProPlus (v1907, July 2019) - DRAFT"

settings. For reference, I deployed the settings via Group Policy and my Office suite at the time was on version 1907 (Build 11901.20176).

 

Macro Runtime Scan Scope

With the "Macro Runtime Scan Scope" policy, I have had difficulties related to some built-in functionality in Access. When the Scan Scope is set to "Enable for all documents", and used at the same time as with Windows Defender Attack Surface Reduction, I seem to receive blocks against the "Block Win32 API calls from Office macro" (92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B) rule from the .accde files within "C:\PROGRAM FILES\MICROSOFT OFFICE\ROOT\OFFICE16\ACCWIZ".

 

Example:

Windows Defender Exploit Guard has blocked an operation that is not allowed by your IT administrator.
 For more information please contact your IT administrator.
 	ID: 92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B
 	Detection time: 2019-08-12T23:08:11.700Z
 	User: (unknown user)
 	Path: C:\PROGRAM FILES\MICROSOFT OFFICE\ROOT\OFFICE16\ACCWIZ\ACWZMAIN.ACCDE
 	Process Name: OFFICE_VBA
 	Security intelligence Version: 1.299.1840.0
 	Engine Version: 1.1.16200.1
 	Product Version: 4.18.1907.4

That particular event was a result of making a new local Access Database, putting 1 record in a table and then Create -> Query Wizard -> Simple Query Wizard -> OK. While I am not a fan of Access, we have a number of users who leverage the tool quite a bit and these blocks make Access "less than functional" to them. If I set the "Macro Runtime Scan Scope" back to my previously configured "Enable for low trust documents", the built-in Access functions work fine, since I have that specific folder added to Trusted Locations, as it is a default trusted location when the Office suite installs.


Interestingly enough, adding exceptions to ASR for the respective folder or specific .accde does not work. (I also attempted a simultaneous Path exception to Windows Defender itself, with no luck.) I assume that this is a result of the way in which the data is passed to Windows Defender via AMSI due to the "Macro Runtime Scan Scope", which perhaps makes it difficult/impossible to make exclusions.

 

Excel File Block prevents copy/paste from Access

On a somewhat different note, the file block settings setting "Excel 97-2003 workbooks and templates" which prevents Open/Save, conflicts with, again, Access. If you have query results, or a table you wish to cut and paste into Excel, the default paste mechanism seems to require the ability to open "Excel 97-2003 workbooks and templates". If you set the file block settings for that file type to "Save Blocked", the paste from Access to Excel will work. If you set it to another value other than "Do not block", the paste will fail and you will receive a warning that Excel 97-2003 files are blocked. If you choose an alternative paste method, such as "Paste Special -> Text" or "Paste, match destination formatting", it will work, but depending on the data in Access, there could be some clean up needed (leading zeroes could be stripped).

 

The remaining difficulties my organization may have with file block settings will be a result of how we operate, and those we work with, but this particular instance seemed worthy of note, since it impacts what could be viewed as a standard workflow/interplay between two Microsoft developed applications.

 

Hope the information is useful. If you can think of something I have overlooked that will allow these to work and enable me to tighten up the policies a bit more, please let me know.

www.000webhost.com