Contributor:
Mark Austin
March 19th, 2010

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.

Application Control - Windows Publisher in Privilege Guard

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.

Introducing Defendpoint

Edit: Privilege Guard has now evolved into the brand new security suite, Defendpoint, which encompasses Privilege Management, Application Control and Sandboxing. For more information, please visit www.avecto.com/defendpoint.

More from the Blog

Related technology and security insights

  • 28
    Jun
  • Story related

    NotPetya ransomware: Attack analysis

    On June 27, 2017 a number of organisations across Europe began reporting significant system outages caused by a ransomware strain referred to as Petya. The ransomware is very similar to older Petya ransomware attacks from previous years, but the infection ...