Summary

Applying the Third Wall Policy, 'Disable Exe Running from %AppData%' (DERA) provides excellent protection from Malware but can adversely impact user operations if not managed appropriately.  This issue is compounded by applications such as Zoom which change their installation folders and/or their executable names.  This KB discusses methods to fully mitigate this risk.

Problem Detail

Not every executable needs to be blocked from running from the %AppData% or %LocalAppData% folder.  In fact, some applications (such as ConnectWise Manage) require it.  For this reason it is a best practice to do an .exe scan of the Client and using that scan to create an exception list prior to applying the DERA policy.  As the exception list is literal, any changes to the path and/or executable names will break the exception.  This presents an issue when an update to an application results in one of those changes.

Additionally, unmanaged environments often run multiple versions of any given software title.  In the context of applying exceptions to DERA, applications which use different paths and/or executable names will require their own explicit exceptions, increasing the cost of management.  Finally, applications which automatically update themselves add complexity to the problem as well.

Prevention

The first step in preventing this issue is to disable both automatic updates and user-initiated updates.  Most commercial products will offer methods to do this but those methods and capabilities will vary from vendor to vendor.  Using Zoom (again) as an example, this page shows how to do this with either Active Directory changes or direct registry modifications.

With this done, you now own the update process.  This means you can rely on there not being any further changes to the environment until you've made them.  The next step is to homogenize the current version in use at the Client environment by rolling out an automated installation/update to all appropriate computers within the Client.

Refer to the software vendor for information on how to package their application for deployment.  Zoom includes this option with their product, most other vendors will as well.  If a business application does not provide this option, consider using a custom application packager, such as Microsoft's.  Either way, with the packager fully built, run it on two test devices, one without the application installed, one with.  This will effectively test the Installation Process and the Update Process and ensures a seamless deployment.

With the software package complete and installed on these test computers we can now set a valid exception list.  Use the test machine which ran the full Installation Process to gather the new exception list.  The 'AppData Scan' button on the Computer Screen will pull this list for you.  Once scanned, use the Scan Results view on the Client Screen to find the new additions.  Finally, apply them to the 'Current Exceptions' view and save them.

Now you're ready to deploy the software package to the environment.  Use an Automate Script for delivery.  Your environment now is fully running one and only one version of the title and that version will not change until the next time you push an update.  This means your can be confident the DERA policy will not block this application for any reason.

Maintenance

Over time, either recommended security update, compatibility issues or new feature sets will force you to update the running version.  This necessitates performing most of the steps already executed.  Check that no changes have been made to the update blocks, package the update, capture and apply the appropriate exceptions, then roll out the new build to the environment.

Closing

Environments which already perform this application management will describe benefits over and above fewer DERA tickets.  Fewer maintenance issues, faster problem resolution and easier customer training are but a few.  New desktop deployments also benefit.  Third Wall strongly recommends this strategy of application management in environments in conjunction with applying the DERA policy for exceptional resistance to common malware installation techniques.