Ultimate guide to Windows 7 security

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 64-bit .EXEs and .COMs; all 16-bit 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.

Rules for exceptions

If you need to make a rule for a file type that is not defined in AppLocker's policy table, you'll have to use some creativity to get the desired effect. For example, to prevent Perl script files with the .PL extension from executing, you would have to create an executable rule that blocked the Perl.exe script interpreter instead. This would block or allow all Perl scripts and require some resourcefulness to gain finer-grained control. This is not a unique issue, as many other application control products have the same sort of limitation.

AppLocker's configuration and rules can easily be imported and exported as readable XML files. Plus, the rules can be quickly cleared in an emergency, and everything can be managed using Windows PowerShell. Reporting and alerting are limited to what can be pulled from the normal event logs. But even with the limitations, AppLocker gives up-to-date Microsoft shops an effective way to prevent users' missteps from compromising their machines, not to mention the company network.

Software makers routinely sacrifice some security for the sake of usability, and Microsoft is no exception. I've built a career on teaching people how to harden Microsoft Windows over its default state. But with Windows 7, most of that old advice is no longer necessary. Microsoft now delivers a product that is significantly more secure out of the box. Administrators don't have to download NSA security templates or modify the system in any way to make users fairly secure from the start. In most cases, they simply need to know what security capabilities Microsoft provides and how to put them to work.