Application restriction products or whitelist products let administrators configure client computers to run only specifically authorized applications. Rather than worrying about users running malware or dangerous scripts, administrators develop a list of authorized applications that users are allowed to run. If an application isn’t on the authorized list, the user is simply blocked from running that application. Depending on the complexity of the technology used for whitelisting, these approved applications can be identified by publisher certificate, a hash value “digital fingerprint,” or a simple path and filename.
Identification based on publisher certificate is typically the easiest way to manage application whitelisting. When you identify an application based on a publisher certificate, you often have the option of including all future versions of that application in any rule. One drawback of identification on the basis of publisher certificate is that there are still a large number of applications that aren’t digitally signed and can’t be identified in this manner. Some implementations of this technique only allow whitelisting based on the publisher’s name, whereas others allow whitelisting based on the name assigned to the application and the version of that application.
Identification based on hash value lets you generate a digital hash, something like a digital fingerprint, that identifies the target application’s executable file. A drawback of digital hashes is that every time the file is modified, through patching or the installation of a new version of the application, the hash value needs to be recalculated because the digital fingerprint has changed. If you’re whitelisting based on hash value, you need to come up with a way of keeping your hash values up-to-date as part of your regular patch management cycle.
Identification based on path is the simplest way of identifying files, but it’s also the least secure. An advantage of publisher certificates and hash values is that if an executable file is modified by malware, the file will no longer be whitelisted because it will no longer match the identifying properties of the publisher or hash rule. An infected executable file identified by pathname will still be whitelisted because even though the file itself might have become malicious, it will still be identified as safe by the whitelist.
Software Restriction Policies and AppLocker
Windows has had application restriction policies since the release of Windows XP. Software Restriction Policies (SRPs) let you create hash rules and path rules. SRPs have the following benefits and drawbacks:
- Include hash-based and location-based file identification.
- Include publisher certificate rules, but they work on an all-or-nothing basis. You either allow all applications signed by a publisher or no applications signed by a publisher. For example, you can’t use a publisher certificate rule to allow Adobe Acrobat but block Adobe Photoshop. You need a copy of the publisher’s certificate in .cer or .crt format to create an SRP certificate rule.
- Allow you to specify which file extensions indicate that a file is executable.
- Don’t include publisher rules.
- Rules must be created manually.
- No central reporting solution, other than combing event logs.
- Use native Group Policy functionality; don’t require installation of an extra client.
Windows 7’s AppLocker extends the functionality of SRPs. AppLocker offers the following improvements and differences over SRPs:
- You can create a publisher rule based on a sample file rather than needing a separate certificate file in .cer or .crt format.
- You can automatically scan a computer to have a set of publisher and certificate rules created.
- Doesn’t support clients other than Windows 7 Professional, Enterprise, or Ultimate editions.
- Must be applied through Group Policy. Lack of client software means administrators must perform substantially more work to get AppLocker working.
- Still doesn’t provide a central reporting solution.
If you want to use application whitelisting as part of your organizational security strategy, and you’re looking for a product that offers more than SRPs and AppLocker, consider using an application restriction product such as Lumension Application Control, Sophos’s Endpoint Security and Data Protection, or Bit9 Parity. All of these products provide substantially more functionality than application whitelisting. Although I mention this functionality, the focus of the following product reviews is to compare their application whitelisting functionality.
Lumension Application Control
Lumension Application Control is a whitelist-specific product that offers automatic application discovery, software update authorization, script and macro protection, application review options, local application authorization, and heuristics to detect the spread of malicious code that has been locally authorized on a specific number of computers. Lumension uses hash-based and path-based rules for file identification and lets administrators remotely scan clients to generate file identification lists.
Client deployment. The Lumension software ships with both an x64 and an x86 Windows installer in MSI format. Administrators can deploy the software to clients through either Group Policy or more sophisticated solutions such as Microsoft System Center Configuration Manager (SCCM).
Creating and updating policies. Lumension Application Control lets you perform discovery to identify which applications are present in your environment. You use the results of these scans to create application whitelisting policies.
After you identify the files that are present in your environment, you can use the Lumension Application Control console to add files to file groups. You use file groups as the basis for blocking or allowing applications. You can apply different application whitelists to different users by assigning the users to different file groups. File groups determine which applications are whitelisted for that user, as Figure 1 shows.
Benefits over AppLocker. The biggest benefit of Lumension Application Control over AppLocker is the extensive remote discovery functionality. With AppLocker, you must run the wizard locally on a reference system to create the application list. With Lumension, you simply point the wizard at a target system to generate the list after scanning that system.
Lumension also provides better monitoring functionality with centralized reporting. The product leverages the power of SQL Server databases in generating reports.
Finally, Lumension offers spread check functionality. The software automatically blocks the spread of suspicious executable files.
Additional notes. Lumension has a very involved installation process. Whereas the installation for both Endpoint Security and Data Protection and Bit9 Parity is primarily a short wizard that you can easily click through, Lumension Application Control installation involves closely following several pages of detailed instructions. A competent administrator won’t find this task to be problematic, but the more complex an installation process is, the more likely an administrator is to make mistakes when implementing it.
Although Lumension Application Control provides a quick and easy way of generating file identification data for use in whitelists, the product documentation suggests using path rules for applications that are regularly updated. As I mentioned earlier, path rules can be problematic from a security perspective because a path rule will still allow an executable file infected by malware to run whereas a certificate rule or hash rule will not.
Summary - Lumension Application Control
PROS: Straightforward detection of applications; whitelists are easy to create
CONS: Complicated installation routine; difficult to configure
RATING: 4
PRICE: $45 license; $9 per year maintenance
RECOMMENDATION: Admins who are looking for more functionality than AppLocker provides might like this product; however, it has an unnecessarily complicated installation routine.
CONTACT: Lumension Security • 888-970-1025 • www.lumension.com