Endpoint Protection

  Google has been doing a fabulous job of obfuscating the installation routine of Chrome, making it difficult to block with software restriction policies in AD.  Is anyone successfully blocking Chrome installation with SEP policies?

How smart are your users?  You could block programs named "ChromeSetup.exe", "chrome.exe", and "gears-chrome-opt.msi" in Application and Device Control.  You probably also want to block the google updater, i think it is "googleupdate.exe".

The downside to this is renaming the exe will allow it to continue.  However, this could be your first line of defense with hashes being your second line.

You can block the application using the MD5 for ChromeSetup.exe

MD5: e4dccea034d671408a145f44cf56c5ee

See https://www-secure.symantec.com/connect/forums/how-block-applications-sep-using-md5

Thomas

Please be careful with working with application and device control. Recently I worked on an issue where explorer was terminated when one of the processes were ran.
Please test all policies before applying to the production environment.

Seems Google themselves are becoming outlaws, breaking the standard Windows install methods and policies, instead installing SOFTWARE, EXE and DLL files into user profiles! 
Very bad and sneaky, IMO. That's what rogue and phony AV apps do, and that's the tricks the BAD GUYS use.
 When it comes down to a once trusted vendor using such tactics to get into corporate and GOVERNMENT doors, then it's time to block their browser and probably anything Google, IMO.
No folder can be created under %userprofile% named GOOGLE, and no file can exist with such a name in it.
Thank you SEP.
IMO, what google is doing is plain unethical and I've love to tell their CEO, how dare they work to get around corporate and agency policies against installing software that isn't approved or standard by using such trickery.
This is one of the bits from my app and device control policy, preventing files from being created here:
%userprofile%\local settings\application data\google\chrome
There can be no Program Files\Google folder, no folder named Chrome in Program files or the profile area.

This actually dates back to when their desktop search toolbar someone had somehow installed here hammered on some other state domain controllers, and then when I saw them attempting to sneek application installations into the profile area, that was enough.
It's a browser with somewhat of a not so smooth history in the security area anyway so it was a browser we didn't need.

Part of the problem with MD5 hashes is that google continually updates their product, so the download seems to have a different hash quite often, and more often then one tech guy could keep up with.  The solution below to block the directories themselves is probably the best one I've seen.