Windows Security Catalogs and Effective Application Control

Solutions that provide application whitelisting or application control need to provide the administrator with a set of rules that can be used to precisely identify applications. The most common types of rule will check the file name or certain attributes of the file, as these rules are relatively simple to maintain, and in most circumstances will provide adequate protection, assuming a least privilege approach is in place, where users can’t tamper with application files.

However, sometimes it is necessary to check the integrity of a file, and therefore most good application control solutions should provide additional capabilities for this purpose. In particular, you should expect a solution to provide support for both trusted publishers and file hashing.

Application Control: The Trusted Publisher Rule?

A trusted publisher rule can be used to ensure that a set of application files have been signed by a specific vendor. If the vendor has not signed the application then the only other realistic option is to take a hash of the file, such as a SHA1. The only problem with file hashes is that they are difficult to maintain, as an update to an application will require a new set of file hashes. For this reason, checking the publisher is a much better approach, if the application has been signed, and hashes should only be used as a last resort.

Windows Security Catalogs

This brings me on to Windows security catalogs, which is the subject of this post. If you check the properties of an application in the operating system, such as calc.exe, you will notice that the application is not signed by Microsoft. At first glance this would suggest that a publisher rule can’t be applied to operating system binaries, as they are not signed by Microsoft. Well that depends on whether your application control solution has built-in support for Windows security catalogs. All of the operating system binaries are indirectly signed by Microsoft. This is achieved by placing hashes of the operating system binaries into various security catalogs, which are then signed by Microsoft. If you’re interested in delving deeper then the catalog files can be found in C:\Windows\System32\catroot.

Privilege Guard Support

We built support for Windows catalog files into Privilege Guard 2.5 (Edit: now Defendpoint) and the screenshot below highlights the publisher for timedate.cpl being identified as “Microsoft Windows” on Windows 7, even though the applet is not signed directly by Microsoft. On Windows XP the publisher will be set to “Microsoft Windows Publisher” for operating system binaries.

To understand the power of this capability, you could just as easily create a single rule to match any application binary that is signed by “Microsoft Windows”. This would be an extremely effective and secure way to whitelist all of the binaries that are part of the operating system, which would also include all future Windows updates.

So if you’ve ever wondered why the operating system files are not signed by Microsoft, now you know why, but more importantly I hope I have shown how application control solutions can provide a secure approach to identifying operating system binaries, which will require little to no maintenance of policies.