Security Baseline for Office 365 July 2017 DRAFT Feedback

%3CLINGO-SUB%20id%3D%22lingo-sub-801669%22%20slang%3D%22en-US%22%3ESecurity%20Baseline%20for%20Office%20365%20July%202017%20DRAFT%20Feedback%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-801669%22%20slang%3D%22en-US%22%3E%3CP%3EA%20bit%20of%20feedback%20on%20the%20%22%3CSPAN%20class%3D%22lia-message-unread%22%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2FMicrosoft-Security-Baselines%2FSecurity-baseline-for-Office-365-ProPlus-v1907-July-2019-DRAFT%2Fba-p%2F771308%22%20target%3D%22_blank%22%20rel%3D%22noopener%22%3ESecurity%20baseline%20for%20Office%20365%20ProPlus%20(v1907%2C%20July%202019)%20-%20DRAFT%3C%2FA%3E%22%3C%2FSPAN%3E%3C%2FP%3E%3CP%3Esettings.%20For%20reference%2C%20I%20deployed%20the%20settings%20via%20Group%20Policy%20and%26nbsp%3Bmy%20Office%20suite%20at%20the%20time%20was%20on%20version%201907%20(Build%2011901.20176).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CU%3E%3CSTRONG%3EMacro%20Runtime%20Scan%20Scope%3C%2FSTRONG%3E%3C%2FU%3E%3C%2FP%3E%3CP%3EWith%20the%20%22Macro%20Runtime%20Scan%20Scope%22%20policy%2C%20I%20have%20had%20difficulties%20related%20to%20some%20built-in%20functionality%20in%20Access.%20When%20the%20Scan%20Scope%20is%20set%20to%20%22Enable%20for%20all%20documents%22%2C%20and%20used%20at%20the%20same%20time%20as%20with%20Windows%20Defender%20Attack%20Surface%20Reduction%2C%20I%20seem%20to%20receive%20blocks%20against%20the%20%22%3CSPAN%3EBlock%20Win32%20API%20calls%20from%20Office%20macro%22%20(92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B)%20rule%20from%20the%20.accde%20files%20within%26nbsp%3B%22C%3A%5CPROGRAM%20FILES%5CMICROSOFT%20OFFICE%5CROOT%5COFFICE16%5CACCWIZ%22.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EExample%3A%3C%2FP%3E%3CPRE%3EWindows%20Defender%20Exploit%20Guard%20has%20blocked%20an%20operation%20that%20is%20not%20allowed%20by%20your%20IT%20administrator.%0A%20For%20more%20information%20please%20contact%20your%20IT%20administrator.%0A%20%20ID%3A%2092E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B%0A%20%20Detection%20time%3A%202019-08-12T23%3A08%3A11.700Z%0A%20%20User%3A%20(unknown%20user)%0A%20%20Path%3A%20C%3A%5CPROGRAM%20FILES%5CMICROSOFT%20OFFICE%5CROOT%5COFFICE16%5CACCWIZ%5CACWZMAIN.ACCDE%0A%20%20Process%20Name%3A%20OFFICE_VBA%0A%20%20Security%20intelligence%20Version%3A%201.299.1840.0%0A%20%20Engine%20Version%3A%201.1.16200.1%0A%20%20Product%20Version%3A%204.18.1907.4%3C%2FPRE%3E%3CP%3EThat%20particular%20event%20was%20a%20result%20of%20making%20a%20new%20local%20Access%20Database%2C%20putting%201%20record%20in%20a%20table%20and%20then%20Create%20-%26gt%3B%20Query%20Wizard%20-%26gt%3B%20Simple%20Query%20Wizard%20-%26gt%3B%20OK.%20While%20I%20am%20not%20a%20fan%20of%20Access%2C%20we%20have%20a%20number%20of%20users%20who%20leverage%20the%20tool%20quite%20a%20bit%20and%20these%20blocks%20make%20Access%20%22less%20than%20functional%22%20to%20them.%20If%20I%20set%20the%20%22Macro%20Runtime%20Scan%20Scope%22%20back%20to%20my%20previously%20configured%20%22Enable%20for%20low%20trust%20documents%22%2C%20the%20built-in%20Access%20functions%20work%20fine%2C%20since%20I%20have%20that%20specific%20folder%20added%20to%20Trusted%20Locations%2C%20as%20it%20is%20a%20default%20trusted%20location%20when%20the%20Office%20suite%20installs.%3C%2FP%3E%3CBLOCKQUOTE%3E%3CHR%20%2F%3E%3C%2FBLOCKQUOTE%3E%3CP%3EInterestingly%20enough%2C%20adding%20exceptions%20to%20ASR%20for%20the%20respective%20folder%20or%20specific%20.accde%20does%20not%20work.%20%3CEM%3E(I%20also%20attempted%20a%20simultaneous%20Path%20exception%20to%20Windows%20Defender%20itself%2C%20with%20no%20luck.)%3C%2FEM%3EI%20assume%20that%20this%20is%20a%20result%20of%20the%20way%20in%20which%20the%20data%20is%20passed%20to%20Windows%20Defender%20via%20AMSI%20due%20to%20the%20%22Macro%20Runtime%20Scan%20Scope%22%2C%20which%20perhaps%20makes%20it%20difficult%2Fimpossible%20to%20make%20exclusions.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CU%3E%3CSTRONG%3EExcel%20File%20Block%20prevents%20copy%2Fpaste%20from%20Access%3C%2FSTRONG%3E%3C%2FU%3E%3C%2FP%3E%3CP%3EOn%20a%20somewhat%20different%20note%2C%20the%20file%20block%20settings%20setting%20%22Excel%2097-2003%20workbooks%20and%20templates%22%20which%20prevents%20Open%2FSave%2C%20conflicts%20with%2C%20%3CEM%3Eagain%3C%2FEM%3E%2C%20Access.%20If%20you%20have%20query%20results%2C%20or%20a%20table%20you%20wish%20to%20cut%20and%20paste%20into%20Excel%2C%20the%20default%20paste%20mechanism%20seems%20to%20require%20the%20ability%20to%20open%26nbsp%3B%22Excel%2097-2003%20workbooks%20and%20templates%22.%20If%20you%20set%20the%20file%20block%20settings%20for%20that%20file%20type%20to%20%22Save%20Blocked%22%2C%20the%20paste%20from%20Access%20to%20Excel%20will%20work.%20If%20you%20set%20it%20to%20another%20value%20other%20than%20%22Do%20not%20block%22%2C%20the%20paste%20will%20fail%20and%20you%20will%20receive%20a%20warning%20that%20Excel%2097-2003%20files%20are%20blocked.%20If%20you%20choose%20an%20alternative%20paste%20method%2C%20such%20as%20%22Paste%20Special%20-%26gt%3B%20Text%22%20or%20%22Paste%2C%20match%20destination%20formatting%22%2C%20it%20will%20work%2C%20but%20depending%20on%20the%20data%20in%20Access%2C%20there%20could%20be%20some%20clean%20up%20needed%20(leading%20zeroes%20could%20be%20stripped).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20remaining%20difficulties%20my%20organization%20may%20have%20with%20file%20block%20settings%20will%20be%20a%20result%20of%20how%20we%20operate%2C%20and%20those%20we%20work%20with%2C%20but%20this%20particular%20instance%20seemed%20worthy%20of%20note%2C%20since%20it%20impacts%20what%20could%20be%20viewed%20as%20a%20standard%20workflow%2Finterplay%20between%20two%20Microsoft%20developed%20applications.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHope%20the%20information%20is%20useful.%20If%20you%20can%20think%20of%20something%20I%20have%20overlooked%20that%20will%20allow%20these%20to%20work%20and%20enable%20me%20to%20tighten%20up%20the%20policies%20a%20bit%20more%2C%20please%20let%20me%20know.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-811049%22%20slang%3D%22en-US%22%3ERe%3A%20Security%20Baseline%20for%20Office%20365%20July%202017%20DRAFT%20Feedback%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-811049%22%20slang%3D%22en-US%22%3E%3CP%3EAnother%20thing%20I%20ran%20into%2C%20which%20is%20a%20bit%20odd%3A%20The%20baselines%20configure%20the%20option%20for%20%22Always%20open%20untrusted%20text-based%20files%20in%20Protected%20View%22%20to%20%22Enabled%22.%20I%20agree%20with%20that%20policy%20setting%2C%20but%20noticed%20that%20when%20I%20would%20open%20a%20CSV%20in%20Excel%20from%20an%20untrusted%20location%20%3CEM%3E(in%20this%20case%2C%20attached%20to%20an%20email)%3C%2FEM%3E%2C%20Excel%20would%20begin%20to%20start%2C%20state%20%22opening%20in%20Protected%20View%22%20and%20then%20never%20actually%20finish%20launching.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETo%20test%2C%20I%20set%20the%20policy%20back%20to%20'Not%20Configured'%2C%20and%20the%20CSV%20opened%20fine%2C%20though%20not%20in%20Protected%20View%20%3CEM%3E(as%20expected)%3C%2FEM%3E.%20I%20then%20set%20the%20option%20via%20the%20Trust%20Center%20GUI%2C%20and%20opened%20the%20file%20again.%20This%20time%20it%20opened%20in%20Protected%20View%20fine%2C%20with%20only%20a%20brief%20delay%20when%20it%20swapped%20to%20using%20Protected%20View.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%2C%20I%20reset%20the%20GPO%20back%20to%20%22Enabled%22%2C%20but%20then%20in%20my%20'customization%20GPO'%2C%20I%20set%20GPP%20for%20Registry%20settings%20to%20set%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-markup%22%3E%3CCODE%3EHKEY_CURRENT_USER%5CSoftware%5CMicrosoft%5COffice%5C16.0%5CExcel%5CSecurity%5CProtectedView%5CEnableForeignTextFileProtectedView%20%3D%201%20(DWORD)%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAlthough%20I%20did%20not%20test%20the%20associated%20file%20types%2C%20I%20also%20configured%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%20class%3D%22lia-code-sample%20language-markup%22%3E%3CCODE%3EHKEY_CURRENT_USER%5CSoftware%5CMicrosoft%5COffice%5C16.0%5CExcel%5CSecurity%5CProtectedView%5CEnableDatabaseFileProtectedView%20%3D%201%20(DWORD)%3C%2FCODE%3E%3C%2FPRE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ejust%20in%20case%20it%20would%20exhibit%20the%20same%20behavior%20in%20the%20future.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWith%20these%20settings%20configured%20in%20addition%20to%20the%20Policy%20key%20%3CEM%3E(or%20in%20lieu%20of%2C%20if%20that%20is%20the%20choice)%3C%2FEM%3E%2C%20the%20associated%20file%20types%20will%20open%20in%20Protected%20View%2C%20but%20Excel%20will%20not%20lock%20up.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20assumption%20is%20there%20is%20some%20policy%20parsing%20issue%20in%20Excel%20causing%20the%20lock%20up%2Ffreeze%2C%20but%20I%20would%20not%20be%20able%20to%20prove%2Fvalidate%20that.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
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.

1 Reply
Highlighted

Another thing I ran into, which is a bit odd: The baselines configure the option for "Always open untrusted text-based files in Protected View" to "Enabled". I agree with that policy setting, but noticed that when I would open a CSV in Excel from an untrusted location (in this case, attached to an email), Excel would begin to start, state "opening in Protected View" and then never actually finish launching.

 

To test, I set the policy back to 'Not Configured', and the CSV opened fine, though not in Protected View (as expected). I then set the option via the Trust Center GUI, and opened the file again. This time it opened in Protected View fine, with only a brief delay when it swapped to using Protected View.

 

So, I reset the GPO back to "Enabled", but then in my 'customization GPO', I set GPP for Registry settings to set:

 

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\EnableForeignTextFileProtectedView = 1 (DWORD)

 

Although I did not test the associated file types, I also configured:

 

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\EnableDatabaseFileProtectedView = 1 (DWORD)

 

just in case it would exhibit the same behavior in the future.

 

With these settings configured in addition to the Policy key (or in lieu of, if that is the choice), the associated file types will open in Protected View, but Excel will not lock up.

 

My assumption is there is some policy parsing issue in Excel causing the lock up/freeze, but I would not be able to prove/validate that.