McAfee Application Control 5.0 (due out Dec. 15) is the result of McAfee's acquisition of Solidcore and the integration of Solidcore S3 Control with McAfee ePolicy Orchestrator (ePO). McAfee Application Control rivals SignaCert for the broadest client support among all the products in InfoWorld's review. It also boasts write protection and ownership protection of whitelisted files, good reporting and alerting, and no significant cons.
McAfee Application Control can enforce whitelisting policies on Windows NT 4 through Windows Server 2008 (Windows 7 support is forthcoming), Suse Linux 9 and 10, Oracle Enterprise Linux, Red Hat Linux 3 through 5 (and CentOS), and Solaris 8 through 10. Its precursor, Solidcore S3 Control, is in use on thousands of client nodes and is deployed on more than 250,000 ATMs.
McAfee Application Control's management console is a dashboard component of McAfee ePO 4.5 (screen image). Administrators connect via a secure browser session, where they can manage Application Control and any other McAfee security solutions they have deployed.
Protected PCs are considered "Solidified," a term that harkens back to the product's Solidcore days. The client interface is minimal, consisting of command-line instructions and parameters. Clicking an icon on the client desktop, called the McAfee Solidifier Command Line (screen image), gives access to all the Solidifier console commands, which allows a user to control everything an administrator could from within the ePO management console. Of course, ePO configurations can prevent local commands from working.
What McAfee Application Control may lack in client interface it makes up for in overall functionality. It can allow or deny program executions by file name, SHA-1 hash, path rules, and digital certificates. McAfee's solution is one of only two products in this review (the other is Lumension) to allow or deny individual scripts or files of any type, although configuring these policies takes extra steps in McAfee.
(SignaCert can monitor individual scripts, or any file type, but cannot block executions.) An administrator must first create a rule about the script interpreter or originating process, but then can allow or prevent individual scripts and files. For example, to prevent individual Perl scripts, the administrator would have to create a rule regarding Perl.exe, but then can allow or deny individual Perl scripts. Similarly, 16-bit applications can be controlled by first creating a rule about Ntdvm.exe, and then marking the individual 16-bit applications.
Whitelisting rules can be created by defining trusted binaries, users, publishers, and directories. Trusted directories can include excluded subfolders so that not every location and file under a trusted parent folder is automatically trusted by default.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.