If you are running a Windows domain and have Windows devices and Office, maybe with a splash (or more) of Chrome, this might be for you.
You may have spent some time implementing white lists (and/or black lists, restricted execution, unsigned blocking) for traditional installers - an attempt to reduce risk or just control the sprawl of various downloads. I am assuming malicious downloads are covered elsewhere and you have a scheme to update software, so put that to one side.
Now, there are plenty more very easy ways to add software that could be a risk, here are just four:
- Chrome has extensions - these can be controlled now within Group Policy
- Office 2016 has Office Add-ins - these can be controlled (mostly) from the Office 365 Admin Centre
- Windows 10 has a Microsoft Store - Microsoft store for business admin is where this can be controlled
- Microsoft Azure has the ability to set trusts with apps and your directory - this is controlled in the Azure Active Directory Admin console (setting for if users or only admins can trust)
Lots of the software here will have some form of access to your computer and in some cases this goes much further and can access your entire active directory, automatically take data to a cloud service, and so on. You should at least start the journey to understand where your environment sits.
More info...
Adventures in Chrome
It would be sensible to lock this down and only approve extensions you have tested/checked. There are approaching 200,000 extensions that do a huge variety of things, from setting Chrome in Dark Mode to syncing passwords you enter to some cloud service. If you do control Chrome extensions via Group Policy remember that each one you check will need to be added (white listed) in your group policy which may be a higher risk change. And, you need a process to check them within a decent time-frame.
Fun with Microsoft Azure Active Directory
If you have synced your directory to Azure, or work that way native, then many apps/services can link into and reference your online directory. This is a quick way to setup things like Single Sign On. However, it does mean the app will have access to your directory. It would be sensible to have a central point (admin) to check these trusts and evaluate the app being linked to your Azure. And, the new phishing kid on the block is one of these trust boxes prompting users to click trust, once clicked this gives the attacker access to an API into your directory.
Would welcome any comments on what others have done/found.
Adam
