Executive Summary:
Group Policy's software restriction policy (SRP) feature gives admins a powerful tool to control what applications their users can run on Windows OSs. You can set up SRPs as blacklists to prevent specific applications from running and as whitelists that specify which applications are allowed to run. Hash rules define a hash to a specific application, which is most useful in blacklists. Path rules, including registry path rules, can be used to control a wide variety of applications.
|
Users constantly download and run applications they shouldn't, which can result in malware being installed on an organization's network. It's surprisingly difficult to control what users install and execute on their PCs in a Windows desktop world. The first part of solving this problem is making sure that users run their desktops with the least amount of privileges possible—that is, not as administrators or power users unless necessary. The second piece of the puzzle is to control what users can execute.
Many third-party solutions provide application whitelisting or blacklisting—that is, creating lists of applications that are allowed (whitelisted) or not allowed (blacklisted) to run—making it difficult for end users to run code with unknown or unwanted little visitors that can cause problems with your network. However, you can use Group Policy's software restriction policy (SRP, aka Safer) feature to control application execution. Although SRP is missing some features of third-party solutions, such as prebuilt catalogs of application signatures to allow or block, it provides nice capabilities that many IT shops haven't yet discovered or fully exploited.
How SRP Works
SRP is supported on Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP. You'll find it in Group Policy Editor (GPE) under either \Computer Configuration\Windows Settings\Security Settings, as Figure 1 shows, or \User Configuration\Windows Settings\Security Settings. SRP is available on both the local Group Policy Object (GPO) and domain-based GPOs, but on the local GPO it's available only on a per-computer basis. The power of SRPs comes when you deploy them via domain-based GPOs across multiple systems by using Group Policy's built-in targeting mechanisms.
SRP lets you define application restriction rules within a GPO, and those rules are delivered to the client machine via normal Group Policy processing. Windows stores the rules in the registry and checks them each time a process is executed; if a rule is matched, the application is either allowed or denied, depending on whether it's whitelisted or blacklisted. SRPs don't go into effect on already-running applications, even if Group Policy has applied the rules. It takes a restart of the application for a rule to become effective.
Setting Up SRP
The best way to illustrate how to use SRP is with a typical scenario. For example, I have a business user who runs Microsoft Office and some line-of-business applications. I want to control exactly what that user can execute, so I'm going to implement a whitelist with SRP.
As a best practice, you should create your SRP settings in a separate GPO from other policy settings so that you can disable your restrictions quickly if necessary. You'll need to decide whether to apply your restrictions per-computer or per-user. Per-computer application restrictions apply to anyone who logs on to the computer accounts in Active Directory (AD) that receive those restrictions; this option might be appropriate, for example, when using SRPs against terminal servers. Per-user restrictions are targeted toward a given set of user objects in AD and follow those users wherever they log on.
After you decide how to target your policies, the next step is to enable and start configuring your policies. First, start Group Policy Management Console (GPMC) and create your new software restrictions GPO. Right-click the newly created GPO within the Group Policy Objects container in GPMC and choose Edit to bring up GPE, focused on that GPO.
Navigate to the Software Restriction Policies node under Computer Configuration to set per-computer policies or under User Configurations for per-user policies. Right-click the Software Restriction Policies node and choose New Software Restriction Policies. A set of folders and policy items appears in the right-hand pane, which you can see in Figure 1. You might receive a message that a reboot is required before the policies will be enforced (this is true on Server 2008). This message is a bit confusing because you don't need to reboot either the client or server to start receiving these policies.
The first decision with these new items is whether you want to create a whitelist or blacklist. Whitelists create a more secure environment because they deny all code from running except what you explicitly allow. However, whitelists also require more overhead to manage, depending on the number of applications in your environment, how often the list changes, and what methods you use to identify them. For our example, we'll create a whitelist.
Double-click the Security Levels folder in the right-hand pane of GPE. On Windows 2003 and XP, the folder contains two nodes: Disallowed and Unrestricted. Server 2008 and Vista add a third node, Basic User. The Unrestricted node (blacklist mode) has a small check mark, indicating that it's the current default. To enable whitelist mode, double-click the Disallowed node and press the Set as Default button. Confirm the warning that appears, then close the dialog box to continue.
Basic User is a feature added with the release of Vista. In Basic User mode, users who are administrators on their workstations or AD domains have administrative tokens removed from any applications they run on their system. Essentially, they're prohibited from running any applications with administrative credentials. Behind the scenes, SRP modifies the process token on every application launched by the user to add deny permissions to the following security groups:
- Administrators
- Certificate Admins
- Schema Admins
- Enterprise Admins
- Domain Admins
Think of Basic User as a mechanism for controlling when your administrators are administrators. You might have a set of sensitive computers that contain customer data that administrators occasionally have to log on to. In such cases, you could set Basic User as the default for these computers to prevent users from running applications with their elevated credentials.
Previous
Register
