These are some quick notes from a session on AppLocker by Paul A. Cooke, Tech-Ed EMEA 2008:
As you may have seen, I’ve written a few articles on Software Restriction Policy (SRP) under Windows XP and Windows Vista for www.windowsecurity.com (see below). I’m very happy to tell you, that Microsoft now improved this functionality and renamed it into: AppLocker!
Unfortunately I cannot bring you any screenshots (because of NDA), but I can tell you a few things about the basic functionality. With AppLocker you can more easily eliminate unwanted and unknown applications in your Windows (7) environment. You can enforce application standardization – both from a security (malware), and from a management point of view (licensing & user control).
What most organizations try to do these days, it to limit users to be standard users (non-administrators) on their local machines – however this is actually not enough to feel secure as an IT administrator. Running as standard user is not the solution to all of our problems. Many applications can do bad stuff, even within user context – like stealing data, deleting data, manipulating data, encrypting data, creating bot-nets, send spam, social engineering etc. etc. This is true for applications that install in user context (like Google Chrome), or regular executables that don’t actually install – they just run!
If you want to control applications like that, what can run and what cannot – then you need another approach. AppLocker comes to the rescue!
AppLocker has been build around digital signatures – signing of software executables and DLLs. This was also an option in SRP under Windows XP, were we had path, filename, HASH & certificate rule, but it was pretty hard to manage and enforce back then. With Windows 7, a new GUI has been added to the group policy editor to support easy creation of software rules. We have 3 types of rules:
- Allow rules: same as Whitelisting (‘known good’ software)
- Deny rules: same as Blacklisting (‘known bad’ software)
- Exceptions: exclusion from allow or deny rules
Allow rules are of course the recommended approach – the “default deny all applications” rule (Whitelisting), but with specific applications the network administrators wants to allow users to run. As an administrator, you get granular control of specific applications, enforcing who can run and/or install them (if they have the appropriate rights and permissions).
The administration is done by group policy under Computer Configuration > Application Control Policies, but strangely enough you have to put in affected users and groups (still unclear whether or not the SYSTEM account is still excluded from SRP checks). So this is actually Computer policies that are able to hit users, like loopback or group policy preferences.
You can create multiple rule sets and take advantage of specific attributes, like app version (equal/above/below X.0.0.0), filename (executable name), product publisher (the valid root certificate used to sign), product suite (like “Microsoft Office 2007”) – and wildcards seems to be supported still.
You can control executables, installers (MSI), scripts, and DLLs, using certificates (publisher), HASH or path rules. The disadvantage of using HASH rules is, that the HASH will change if the application is updated, certificate/publisher rules are much more flexible because the signature is still going to be there (unless the developers totally mess up). So always try to go for publisher rules, certificates are here to stay :)
Can be run in 3 modes: Enforce policy, Enforce Policy using Group Policy Inheritance and Audit Only mode! The latter is pretty cool, as you can configure a Software Restriction Policy, and test it out before you go “live”.
AppLocker supports import and export of rules, which can be very useful, but one of the best new features is, that there’s no need to create all the rules manually – you have the option to “automatically generate rule”, this feature will analyze a “reference machine” (not sure if this has to be the local machine yet) and files in a given folder on that machine (not sure if this can be a share yet). You can compare this to a “snapshot” feature, take all files in this folder (and subfolders), and make an allow rule from that (certificate based preferably).
The new rule creation tools and wizards seem pretty straight forward – but you really need to think about the SRP design before you go for it, and test intensively, or else you’ll end up in serious trouble ;-)
I just can’t wait to test this deeply and bring you more information!
Previous article series on SRP:
Default Deny All Applications (Part 1)
Default Deny All Applications (Part 2)
Microsoft AppLocker description:
http://www.microsoft.com
.
