The Software Restriction Policies node is found in the Windows SettingsSecurity Settings node of the User Configuration or the Computer Configuration node of a GPO. By default, the Software Restriction Policies folder is empty. When you create a new policy, two subfolders appear: Security Levels and Additional Rules. The Security Levels folder enables you to define the default behavior from which all rules will be created. The criteria for each executable program are defined in the Additional Rules folder.
In the following sections, you learn how to set the security level for a software restriction policy and how to define rules that will govern the execution of program files.
Prior to creating any rules that govern the restriction or allowance of executable files, it is important to understand how the rules work by default. If a policy does not enforce restrictions, executable files run based on the permissions that users or groups have in the NTFS file system.
When considering the use of software restriction policies, you must determine your approach to enforcing restrictions. There are three basic strategies for enforcing restrictions, as follows:
– Unrestricted This approach enables all applications to run except those that are specifically excluded.
– Disallowed This approach prevents all applications from running except those that are specifically allowed.
– Basic User This approach prevents any applications from running that require administrative rights, but enables programs to run that only require resources that are accessible by normal users.
The approach you take depends on the needs of your particular organization. By default, the Software Restriction Policies area has an Unrestricted value in the Default Security Level setting.
For example, you might want to enable only specified applications to run in a high-security environment. In this case, you would set the Default Security Level to Disallowed. By contrast, in a less secure network, you might want to allow all executables to run unless you have specified otherwise. This would require you to leave the Default Security Level set as Unrestricted.
In this case, you would have to create a rule to identify an application before you could disable it. You can modify the Default Security Level to reflect the Disallowed setting.
Because the Disallowed setting assumes that all programs will be denied unless a specific rule permits them to run, this setting can cause administrative headaches if not thoroughly tested. You should test all applications you wish to run to ensure that they will function properly.
To modify the Default Security Level setting to Disallowed, use the following procedure.
1. In Server Manager, on the Tools menu, select Group Policy Management to open the Group Policy Management console.
2. Expand the forest container and browse to your domain. Then expand the domain container and select the Group Policy Objects folder. The GPOs that currently exist in the domain appear on the Contents tab.
3. Right-click a GPO and select Edit. A Group Policy Management Editor window opens.
4. Browse to the Software Restriction Policies node under either Computer Configuration or User Configuration.
5. Right-click Software Restriction Policies and select New Software Restriction Policies.
The folders containing the new policies appear.
6. In the details pane, double-click Security Levels. Note the check mark on the Unrestricted icon, which is the default setting.
7. Right-click the Disallowed security level and, from the shortcut menu, select Set As Default. A Software Restriction Policies message box appears, warning you of your action.
8. Click Yes, and then close the Group Policy Management Editor and Group Policy Management consoles.
You have now modified the Default Security Level for a software restriction policy.
Configuring software restriction rules
The functionality of software restriction policies depends first on the rules that identify software and then by the rules that govern its usage. When you create a new software restriction policy, the Additional Rules subfolder appears. This folder enables you to create rules that specify the conditions under which programs can be executed or denied. These rules can override the Default Security Level setting when necessary.
You create new rules of your own in the Additional Rules folder using a dialog box like the one shown in Figure 6-15.
FIGURE 6-15 The New Path Rule dialog box
There are four types of software restriction rules that you can use to specify which programs can or cannot run on your network:
– Hash rules
– Certificate rules
– Path rules
– Network zone rules
There is also a fifth type of rule—the default rule—that applies when an application does not match any of the other rules you have created. To configure the default rule, select one of the policies in the Security Levels folder and, on its Properties sheet, click Set As Default.
The functions of the four rule types are explained in the following sections.
A hash is a series of bytes with a fixed length that uniquely identifies a program or file. A hash value is generated by an algorithm that essentially creates a fingerprint of the file, making it nearly impossible for another program to have the same hash. If you create a hash rule and a user attempts to run a program affected by the rule, the system checks the hash value of the executable file and compares it with the hash value stored in the software restriction policy. If the two match, the policy settings will apply. Therefore, creating a hash rule for an application executable prevents the application from running if the hash value is not correct. Because the hash value is based on the file itself, the file will continue to function if you move it from one location to another. If the executable file is altered in any way, for example, if it is modified or
replaced by a worm or virus, the hash rule in the software restriction policy prevents the file from running.
A certificate rule uses the digital certificate associated with an application to confirm its legitimacy. You can use certificate rules to enable software from a trusted source to run or to prevent software that does not come from a trusted source from running. You can also use certificate rules to run programs in disallowed areas of the operating system.
A path rule identifies software by specifying the directory path where the application is stored in the file system. You can use path rules to create exceptions that allow an application to execute when the Default Security Level for software restriction policies is set to Disallowed, or you can use them to prevent an application from executing when the Default Security Level for software restriction policies is set to Unrestricted.
Path rules can specify either a location in the file system where application files are located or a registry path setting. Registry path rules provide assurance that the application executables will be found. For example, if an administrator uses a path rule to define a file system location for an application, and the application is moved to a new location, such as during a network restructuring, the original path in the path rule would no longer be valid. If the rule specifies that the application should not function unless it is located in a particular path, the program would not be able to run from its new location. This could cause a significant security breach opportunity if the program references confidential information.
In contrast, if you create a path rule using a registry key location, any change to the location of the application files will not affect the outcome of the rule. This is because when you relocate an application, the registry key that points to the application’s files is updated automatically.
NETWORK ZONE RULES
Network zone rules apply only to Windows Installer packages that attempt to install from a specified zone, such as a local computer, a local intranet, trusted sites, restricted sites, or the Internet. You can configure this type of rule to enable Windows Installer packages to be installed only if they come from a trusted area of the network. For example, an Internet zone rule could restrict Windows Installer packages from being downloaded and installed from the Internet or other network locations.
Using multiple rules
You can define a software restriction policy by using multiple rule types to allow and disallow
program execution. By using multiple rule types, it is possible to have a variety of security levels.
For example, you might want to specify a path rule that prevents programs from running
from the \Server1Accounting shared folder and a path rule that enables programs to run
from the \Server1Application shared folder. You can also choose to incorporate certificate
rules and hash rules into your policy. When implementing multiple rule types, systems apply
the rules in the following order of precedence:
1. Hash rules
2. Certificate rules
3. Network zone rules
4. Path rules
When a conflict occurs between rule types, such as between a hash rule and a path rule, the hash rule prevails because it is higher in the order of preference. If a conflict occurs between two rules of the same type with the same identification settings, such as two path rules that identify software from the same directory, the more restrictive setting will apply. In this case, if one of the path rules were set to Unrestricted and the other to Disallowed, the policy would enforce the Disallowed setting.
Configuring software restriction properties
Within the Software Restriction Policies folder, you can configure three specific properties to provide additional settings that apply to all policies when implemented: Enforcement,Designated File Types, and Trusted Publishers.
As shown in Figure 6-16, the Enforcement properties enable you to determine whether the policies apply to all files or whether library files, such as dynamic link library (DLL) files, are excluded. Excluding DLLs is the default. This is the most practical method of enforcement. For example, if the Default Security Level for the policy is set to Disallowed and the Enforcement properties are set to All Software Files, you would have to create a rule that checked every DLL before the program could be allowed or denied. By contrast, excluding DLL files by using the default Enforcement property does not require an administrator to define individual rules for each DLL file.
FIGURE 6-16 Configuring Enforcement properties
DESIGNATED FILE TYPES PROPERTIES
The Designated File Types properties within the Software Restriction Policies folder, as shown in Figure 6-17, specify file types that are considered executable. File types that are designated as executable or program files are shared by all rules, although you can specify a list for a computer policy that is different from one that is specified for a user policy.
FIGURE 6-17 Configuring Designated File Types properties
TRUSTED PUBLISHERS PROPERTIES
Finally, the Trusted Publishers properties enable an administrator to control how systems handle certificate rules. In the Properties dialog box for Trusted Publishers, shown in Figure 6-18, the first setting enables you to specify which users are permitted to manage trusted certificate sources. By default, local computer administrators have the right to specify trusted publishers on the local computer and enterprise administrators have the right to specify trusted publishers in an OU. From a security standpoint, in a high-security network, users should not be allowed to determine the sources from which certificates can be obtained.
The Trusted Publisher Properties sheet also lets you decide if you wish to verify that a certificate has not been revoked. If a certificate has been revoked, the user should not be permitted access to network resources. You have the option of checking either the publisher or the time stamp of the certificate to determine if it has been revoked.
This article is a part of 70-410 Installing and Configuring Windows Server 2012 Prep course, more articles in this course are :
70-410 Installing and Configuring Windows Server 2012 Prep course includes following practice tests: