Windows 7 is just over six months old. It has been quickly adopted by PC users at home and in businesses. However, some IT admins are struggling with the platform's new security features. We take a look at the key features and what you need to know.
You can configure AppLocker locally using the Local Computer Policy object (gpedit.msc) or via Active Directory and Group Policy Objects (GPOs).
AppLocker relies on the built-in Application Identity service, which is normally set to manual startup type by default.
Administrators should configure the service to start automatically.
Within the local or group policy object, AppLocker is enabled and configured under the \Computer Configuration\Windows Settings\Security Settings\Application Control Policies container.
By default, AppLocker rules do not allow users to open or run any files that are not specifically permitted.
First-time testers will benefit by allowing AppLocker to create a default set of ‘safe rules' using the Create Default Rules option.
The default rules authorise all files in Windows and Program Files to run, along with letting members of the Administrators group run anything.
One of the most notable improvements over SRP is the ability to run AppLocker against any computer using the Automatically Generate Rules option to quickly create a baseline set of rules.
In a few minutes, dozens to hundreds of rules can be produced against a known clean image, saving administrators anywhere from hours to days of work.
Running by the rules
AppLocker supports four types of rule collections: Executable, DLL, Windows Installer, and Script.
SRP administrators will notice that Microsoft no longer has the registry rules or internet zones options. Each rule collection covers a limited set of file types.
For example, executable rules cover 32 and 64bit .EXEs and .COMs; all 16bit applications can be blocked by preventing the ntdvm.exe process from executing. Script rules cover .VBS, .JS, .PS1, .CMD, and .BAT file types.
The DLL rule collection covers .DLLs (including statically linked libraries) and OCXs.
If no AppLocker rules for a specific rule collection exist, all files that share the same format are permitted to run.
However, once a rule for a specific collection is created, only the files explicitly allowed in the rule can execute. For example, if you create an executable rule that allows .EXE files in %SystemDrive%\FilePath to run, only executable files located in that path are permitted to run.
AppLocker supports three types of rule conditions for each rule collection: Path Rules, File Hash Rules, and Publisher Rules.
Any rule condition can be used to allow or deny execution, and it can be defined for a particular user or group. Path and File hash rules are self-explanatory; both accept wild card symbols.
The Publisher rules are fairly flexible and allow several fields of any digitally signed file to be matched with specific values or wild cards.
By using a convenient slider bar in the AppLocker GUI, you can quickly replace the specific values with wild cards.
Each new rule conveniently allows one or more exceptions to be made. By default, Publisher rules will treat updated versions of files the same as the originals, or you can enforce an exact match.
NEXT PAGE: Rules for exceptions