eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Application whitelisting-a security practice in which administrators identify which applications are allowed to run on a system and deny all others-is all the rage these days. In situations where users can’t be trusted, strict whitelisting makes plenty of sense as a part of a more comprehensive endpoint security policy. However, without enough provision for flexibility and centralized management, whitelisting products can render workstations too rigid for mainstream use.
I experienced the benefits and drawbacks of application whitelisting firsthand in my tests of Faronics Anti-Executable Enterprise 3.5, a whitelisting product that’s available in Standard and Enterprise flavors. The Enterprise version is basically the Standard version that’s managed centrally using the Faronics Core management console. To cut to the chase, I found Faronics Anti-Executable to be a solid stand-alone product for strict lockdown scenarios, but I was disappointed with its central management capabilities and its provisions for flexibility in the face of software updates and mainstream use.
During my testing, there was a three-day period of Patch Tuesday, an Adobe update and a Java update. Just on my little testbed of 10 workstations, it took considerable effort to allow the patches to be installed, to allow the updated app to run and to update the whitelist to continue to allow it to run. In an environment of 5,000-plus machines, this added burden could outweigh the positives provided by control.
On the other hand, in areas where configurations don’t need to be updated constantly and where security is the paramount concern, Faronics Anti-Executable Enterprise does a great job. This is also a much more appropriate use of application whitelisting technology in general.
For example, the average business user would not tolerate the intrusiveness and disruption, but on a kiosk or shared workstation, this would be perfect. Malware can’t run, keyloggers can’t be installed and all warnings could be silent while non-whitelisted apps are terminated. Other use cases include workstations in a classroom, POS-really anywhere you want to limit the user to a few specific tasks and block everything else.
Faronics Anti-Executable Enterprise 3.5 is priced starting at $40 per client, with volume discounts that can push the price down to $9.99 per client.
Faronics in the Lab
Faronics in the Lab
Installation of the management server and console was simple. A wizard walked me through the setup to the extent that I merely had to click “next” a few times and then click “finish.”
That’s where the hand-holding stopped abruptly, as I never encountered another wizard. While there is help available for Faronics Core Console, the MMC Snap-in GUI management tool, it is pretty bare bones and not context-sensitive. There are traditionally helpful passages in the help area, such as “click yes to enable this feature,” but there was no explanation of the feature. Help is slightly better for end users if you choose to make it available as a PDF-based manual.
The GUI is pretty straightforward, so the lack of wizards didn’t cripple me. But it took a few minutes to get orientated to the GUI. It’s organized like any other MMC snap-in, with a tree in the left pane broken down by Faronics Core Server, Workstations, Tasks and Reports. The Action Pane appears on the right and shows tree-sensitive actions.
The first thing I did was navigate to the local instance of Faronics Core Server and choose to Create Core Agent Install, which generated a very small MSI install package. The MSI file could be pushed to workstations however you want, including manually. I also had to install the Anti-Executable workstation software on each client in the same manner.
Neither of these installs can be silent. Under this same action menu (Manage Users and Roles), I created a variety of console user accounts (there are four presets: Guests, Users, Power Users, Administrators), which are good enough, but custom groups and privileges can’t be created. Different roles can be assigned with different levels of privilege in the console and in Anti-Executable.
Once the client agent was installed on my 10 workstations, they automatically contacted the management server and appeared under Managed Workstations. I created a few Custom Workstation Groups for various configurations. It’s likely that an actual implementation would involve quite a few groups with different policies assigned by configuration or user job tasks. I could drag and drop workstations into the groups I created and could also have used an LDAP server (AD or eDirectory).
Straightforward Settings
Straightforward Settings
Settings for Anti-Executable are pretty straightforward. Protection can be enabled (active whitelist), disabled (totally unprotected) or in maintenance mode (new executable files are automatically whitelisted when enabled). Other settings are whether to show a tray icon, to disable mouse and keyboard, and to shut down or restart the workstation.
The degree to which the user can be involved can be controlled: Is there a splash screen or not? Are pop-up notifications of blocked applications on or off? Alerts are customizable by whitelist or blacklist, as is an image, such as a logo or a photo of you holding a sledgehammer accompanied by an explanation of why what the user is doing is wrong.
If the tray icon is shown, there is a key combination to enable the interface (left-shift, left-click) followed by an administrative login that requires a strong password. Administrative rights are required for administrators and trusted users. The former can make lasting changes, and the latter can make temporary exceptions. Those without credentials will have their applications blocked.
Reporting is bare bones. In essence, each workstation agent writes a log of basic information and those are combined into a single report. This is very basic stuff, like time, machine name, user account, event and description. It would not be fun to scan through thousands of lines of this stuff every day looking for anomalies. I could easily export reports and import them into another app for better reporting.
The bulk of my time with Faronics Anti-Executable was spent building and maintaining whitelists-as it is with all whitelisting products. Building whitelist maintenance into your patching process is important, so it’s best to set aside a workstation (or virtual machine) on which to apply patches, and then build and test whitelists before deployment.
I found it best to actively maintain the whitelist on one machine and push that whitelist to the others through the management console. I could not see how this could be automated. I had to do this by saving whitelists (AEWL files) from the first machine and then manually applying them to the other workstations.
This proved to be an extremely effective method of preventing the installation of malware. I could download any piece of test malware I wanted (demonstrating that whitelisting should be part of a more comprehensive endpoint security policy), and Anti-Executable stopped it from running. And software configurations are locked. It’s not the easiest software in the world to manage, and I suspect the problems will be worse in larger organizations, but the client agent does what it is supposed to do.