I’ve worked with hundreds of clients on the design and implementation of application control (whitelisting) solutions. The key to a successful application control implementation is *not* have to manually manage the whitelist on an application-by-application basis.
Our goal should be to identify and approve how trust propagates to files on a system and not be forced to approve each file individually – a concept referred to as “trusted change”. For end-user desktop computing, manually managing a whitelist on a file by file basis simply won’t scale. How can we automate the management of the whitelist? Here are some examples:
- If a file/application/update is digitally signed by an application publisher that I trust, then the entire installation is trusted. This is probably the most common example and is the foundation of Microsoft’s improvements with Windows 7 AppLocker over Windows XP’s Software Restriction Policies.
- If a file/application/update is installed by a trusted process (e.g. software distribution agent) on a system, then the entire installation is trusted.
- If a file/application/update is installed by a self-updating application (e.g. iTunes, Chrome, Firefox), then these changes are automatically trusted.
- If a trusted user/group (e.g. IT admin, departmental admin) installs the application, then the entire installation is trusted.
These are just a few of the more common examples out of the 20 or so scenarios that I believe are important. I’ve outlined these for clients evaluating application control solutions in a spreadsheet toolkit with the evaluation categories and suggested weightings.
Bottom line: Controlling whether or not a given file can execute is the easy part. The success of any end-user targeted application control project is in the automated care and feeding of the whitelist. There is simply no way this can be managed on a file by file basis.
Category: Virtualization Security Tags: