Stay Safer with Software Restriction Policies

A credit union recently enlisted a security company to try to compromise the credit union’s computers. The security company successfully infiltrated the computers, starting its attack by scattering USB thumb drives around the credit union’s parking and smoking areas. Each USB thumb drive contained a Trojan horse executable. Credit union employees found most of the thumb drives, attached them to credit union workstations, then ran the Trojan horse executable. Unless you’re sure that your organization’s employees or members would never execute a file they found on a discarded thumb drive, you might want to give software restriction policies (SRPs) a closer look.

SRPs are a Group Policy feature that you can use to restrict application execution on Windows Vista, Windows Server 2003, and Windows XP computers. You can think of SRPs as similar to a set of firewall rules. You can configure SRPs to allow or deny the execution of specific applications. Then, you can configure a more general rule to allow or deny the execution of applications not covered by the specific rules. So, for example, you can configure a general rule to allow everything, while creating a rule to ban sol.exe (solitaire.exe on Vista). Or, you can begin by banning everything, then allow only applications for which you’ve created an SRP rule.

You can implement several types of SRP rules, including zone, path, certificate, and hash. After a quick look at SRP fundamentals, I briefly show you how to implement each rule type, then concentrate on what I consider the most effective SRP rule: the hash rule.

Initial Configuration

You can configure SRPs in either the User or Computer sections of Group Policy. This flexibility lets you apply policies to groups of computers or users. For example, you can apply an SRP to the Accountants organizational unit (OU) that restricts those users from playing Minesweeper or Solitaire. Or, you might apply an SRP to a group of computers in a college’s general-access student laboratory to restrict everyone who uses lab computers to a set of preapproved applications.

To enable SRPs, you first create or edit a Group Policy Object (GPO), then navigate to Computer (or User) Configuration, Windows Settings, Security Settings, Software Restriction Policies. Next, right-click the Software Restriction Policies node and select the New Software Restriction Policies option.

After you’ve enabled SRPs, you need to decide whether to set the Unrestricted or the Disallowed security level. The default level is Unrestricted, which lets all except explicitly blocked applications run. In contrast, Disallowed prevents all software from running unless you set an exception rule. Note that Vista allows a third security level, Basic User, which forces all applications to run at the Basic User level unless specifically configured otherwise. But because this article is about restricting applications from running, we won’t look at the Basic User level.

If you’re serious about restricting the use of unauthorized software in your organization, you should implement the Disallowed security level. The Unrestricted level requires you to know which unauthorized software users might be trying to run, which is a little like guessing lottery numbers. Although the Unrestricted level can work well in a secure environment where management has asked you to disable Windows’ built-in games, it’s difficult to bend into a hardened security solution. However, if you want to block just a few applications without completely locking down your organization’s computers, use the Unrestricted security level.

To set the Disallowed level for an SRP, navigate to the Security Levels node under Software Restriction Policies, and double-click the Disallowed policy. In the resulting Disallowed Properties dialog box, which Figure 1 shows, simply click Set as Default. Windows will display a message that the selected level is more restrictive than the current security level and might cause some programs to stop working. Click OK.

In a default SRP, exception rules already exist for all .exe files in the %SystemRoot% and %SystemRoot%System32 directories. You can view these exceptions in the policy’s Additional Rules node. These rules give the OS a minimal level of functionality even if you activate the Disallowed security level. However, these defaults also potentially allow an attacker to copy an executable file into either of these directories. The default rules don’t differentiate between applications such as cmd.exe and rootkit.exe, they just allow all executables in these directories to run. NTFS permissions provide some protection by keeping people from copying unauthorized applications to these directories and executing them. But to really lock down a computer, you need to replace these general rules with something more specific.

Note that you can also use SRPs on computers that don’t fall under the purview of Active Directory (AD), such as laptops, by creating a security template based on a computer under the SRP, then applying that template to the local policy. You need to make sure the template lets you run the Secedit utility so that you can roll back or update the SRP as required.

General Policy Settings

Under the Software Restriction Policies node, you’ll find the following three general policies that determine how Windows applies SRPs: enforcement, designated file types, and trusted publishers. Let’s look at each of these general policy types.

Enforcement. You use the enforcement policy to specify whether SRPs apply to software library .dll files as well as to .exe, .vbs, and all other file extensions listed as executable in the designated file types policy. The Enforcement Properties dialog box, which Figure 2 shows, also lets you specify whether the SRP applies to members of the local administrators group.

For the tightest security, you’d set the enforcement policy to include all software files and to apply to all users. However, creating individual rules for the thousands of .dll files on a standard Windows installation would require weeks of effort. Unless you must lock down your system to this degree, a more practical and still secure solution is to have the enforcement policy bypass software libraries.

Note that you should include local administrators in the enforcement policy. If a computer needs to run an application that’s not in the SRP allow list, the administrator can temporarily move the computer to an OU that doesn’t enforce SRPs.

Designated file types. The designated file types policy is a list of all file extensions—in addition to the standard .exe, .dll, and .vbs extensions—that Windows considers as executable code. Figure 3 shows the Designated File Types Properties dialog box. If your organization uses a file type that isn’t listed here, such as Perl files, you can add the file type through this dialog box.

Trusted publishers. You use the trusted publishers policy to prevent users from adding a trusted publisher to their workstations. For example, if end users try to download an application from Adobe’s Web site, the system asks them whether they want to trust that application or not. The settings in this policy determine who can make the decision about which publishers to trust: end users, local administrators, or enterprise administrators. The most secure option is to allow only enterprise administrators to designate trusted publishers, as Figure 4 shows. The trusted publishers policy also lets you enforce a certificate revocation list (CRL) check on any trusted certificate to ensure that it’s valid.

Allowing or Denying Application Execution

Now that we’ve covered the SRP basics, let’s explore the four types of rules you can use to allow or deny application execution: zone, path, certificate, and hash.

Zone rules. You use Internet zone rules to restrict or allow the execution of downloaded .msi (Windows Installer) files, based on the Microsoft Internet Explorer (IE) zone the file was downloaded from. Because this rule applies only to .msi files downloaded from the Internet to the client, this form of SRP is less useful than the other types of rules available.

To create an Internet zone rule, right-click the Additional Rules node and select New Internet Zone Rule. Select Internet zone, and set the Security level to Unrestricted or Disallowed. In the Internet zone rule that Figure 5 shows, .msi files downloaded from locations in the Restricted sites zone are Disallowed.

Path rules. Path rules let you specify a folder or full pathname of an application that can or can’t be executed. The weakness of the path rule is that it relies solely on pathname and/or filename. For example, Figure 6 shows a path rule that allows the execution of Outlook Express. Nefarious parties could simply rename a file containing malicious code to msimn.exe and copy it to C:Program FilesOutlook Expressmsimn.exe. As far as the path rule is concerned, the file containing malicious code is legitimate and can be executed. Note that if you set up multiple path rules, the most specific path rule takes precedence. For example, a path rule to C:directoryapplication.exe takes precedence over a path rule to C:directory.

Certificate rules. Certificate rules are based on a publisher’s signing certificate. The main problem with this type of rule is that it requires you to locate a publisher’s signing certificate—which can be a chore. Furthermore, you can’t use a certificate rule to distinguish between multiple applications from a particular publisher. For example, you can’t use a certificate rule to block employees from playing Solitaire because all games included with Windows are signed with the same publisher’s certificate as important OS components, such as IE.

To create a certificate rule, right-click the Additional Rules node and select New Certificate Rule. Click Browse, locate the publisher’s certificate (a .crt or .cer file), set the security level to Unrestricted (or Disallowed), then click OK.

Hash rules. Hash rules are my favorite type of SRP. They don’t require you to locate a publisher’s certificate, they aren’t based on Internet zone rules, and because they use a calculated hash value to identify an executable, an attacker can’t dress up a malicious executable with a new name to bypass the rule.

Hash rules use a hash generated from a specific file. For example, if you generate a blocking rule using the hash from the version of notepad.exe that’s part of Windows 2003, the rule won’t block the version of notepad.exe that ships with XP Professional. And if you generate a blocking hash rule for XP’s version of notepad.exe, it won’t block the version of notepad.exe that ships with Vista. Although applications that ship with the OS generate different hash values depending on which OS is installed, other applications—such as Microsoft Word or Mozilla Firefox—generate the same hash value whether they’re installed on Vista, Windows 2003, or XP clients.

Creating hash values requires access to the binary executable file on the computer on which you’re editing the GPO. If you’re creating the GPO on a domain controller (DC), you can map a drive on a model workstation by using an administrative share such as \XP-REF-SYSC$. Locating the executable is then simply a matter of navigating to it in the mapped network drive.

If any SRP rules conflict, hash rules take precedence over all other rules. Also note that files that you rename or move to a different location retain their hash values. So if you use a hash rule to block a file, such as a virus executable, the rule will work even if someone renames the virus executable.

The biggest drawback of using hash rules with the Disallowed policy is that configuring the initial set of allowable applications takes time. You also need to remember to update your hashes every time you update an application or install new software. To run a patched application, you need to create a new hash rule for it. Note that you should create new hash rules for updated applications rather than amending existing ones because both the patched and unpatched versions might coexist on your network for a time. Eventually, you’ll remove the hash rule for the unpatched application.

To create a hash rule, right-click the Additional Rules Group Policy node and select New Hash Rule. In the resulting New Hash Rule dialog box, click Browse and navigate to the application you want to create the hash rule for. When you select the application, Windows will automatically generate the file hash, as Figure 7 shows, and will display file details in the File information box.

Developing and Troubleshooting SRPs

When you create SRPs, you should create a temporary OU within AD and assign the GPO you’ve created to this temporary OU. You can then place the test users or computer accounts in this temporary OU until you’ve configured the SRP for your needs. After you’ve tested the SRP GPO, you can attach it to an OU that stores production user or computer accounts. Make sure you thoroughly test SRPs—both in the IT department lab and with a pilot group of users—before implementing them throughout your organization. SRPs are complicated, and you probably won’t get them 100 percent correct the first time you try to implement them.

If you need to debug a problem with SRPs, you can look for SRP events (event IDs 865, 866, and 867) in the local computer’s system log. You can also activate more advanced SRP logging by adding the string LogFileName to the following registry subkey:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsSaferCodeIdentifiers.

LogFileName is the path the computer will write the log file to.

Follow the Rules

Using SRPs, you can keep unwanted applications—from productivity-sapping games to viruses—from running on your systems. And Vista, Windows 2003, and XP provide a number of flexible options that let you create the best policies for your organizations. Although implementing SRPs by using only hash rules is a lot of work, hash rules are extremely effective at locking down computers. If the credit union in our introductory scenario had implemented SRPs as outlined in this article, the Trojan horse executable would never have been executed because it wouldn’t have been in the list of allowed applications defined by the hash rules.