Chapter 12: Software Restriction Policy Baseline

 

 

This chapter starts with an overview of why organizations implement application access restrictions and then introduces Microsoft Software Restriction Policies. The chapter concludes with an example tier 3 Software Restriction Policy Baseline. This chapter explains why organizations employ application access restrictions and offers directions to plan and implement Software Restriction Policies in your Terminal Server environment.

 

Administrators quickly learn that providing users with full access to their computer results in policy violations, system stability and security issues. Offering users full access to their computer typically results in an increased number of help desk calls, licensing violations, and data loss. By implementing security controls that limit user access rights to computers shores up an organizations security posture by limiting accidental or deliberate damage to computers, applications and data.

 

List 12.1 shows which issues can be prevented by implementing security controls that limit user access rights to a computer:

Organizations turn to desktop security controls and application access restrictions to manage user access rights on computers, enforce corporate policy, reduce system configuration problems and decrease system downtime. As discussed in Chapter 11, Terminal Server desktop security controls ensure that the desktop environment is properly secured in order to encourage accepted system usage. Application access restrictions promote standardized application usage by allowing administrators to define what applications and file types can or cannot be executed on a computer.

 

As discussed in Chapter 2, the default behavior with Terminal Server is to assume that all users have access to all applications installed on a Terminal Server. To meet business and regulatory requirements, many organizations turn to application access restrictions to define which applications are available to specific users. There are two strategies used to implement application restrictions: a black-list policy and a white-list policy. A black-list policy is one in which an administrator specifies which applications are not allowed to execute, and all other applications are allowed. A white-list policy is one which an administrator specifies which applications are allowed to execute, and all other applications are denied.

 

 

Microsoft Software Restriction Policies provide the integrated framework to implement granular application and file execution entitlements, using Active Directory Group Policy without the need of any additional 3^rd party software. It was first introduced with Windows XP and followed by Windows Server 2003. Software Restriction Policies provide the security controls to manage application and file execution entitlements as well as the ability to mitigate the introduction of hostile code through email or web browsing, such as script based viruses or Active X controls. Script based viruses are controlled by the integration of the Windows scripting host with Software Restriction Policies, which provide control over VB Script and Jscript execution.

 

Software Restriction Policies are created using the Group Policy Management Console and can be applied to local machines, sites and domains, or Organizational Units. Software Restriction Policies can be configured as a user or machine policy. Machine policies are applied to all managed computers from the time they start and are enforced upon application or file execution. User policies are applied at the user level and are enforced through the duration of a user session upon application or file execution. A Software Restriction Policy consists of a default security level that defines if an application is allowed to run along with the rules that specify exceptions to the default security level.

 

List 12.2 highlights Software Restriction Policies capabilities:

 

Note: The implementation of Software Restriction Policies requires extensive testing to ensure that applications function properly and that the user environment is not too restrictive. Each organization should evaluate its unique requirements in order to develop Software Restriction Policies that provide sufficient security and manageability without limiting user productivity.

 

Software Restriction Policies can be applied in one of two security levels, Unrestricted or Disallowed. The Unrestricted security level is a blacklist policy that allows administrators to specify which application will not execute, and all other applications are allowed. The Disallowed security level is a white-list policy that allows administrators to specify which applications are permitted to execute, and all other applications are restricted. The Disallowed security level provides a higher level of security than Unrestricted because of the ability to restrict access to known trusted applications. One of the two security levels must be selected as the default policy security level.

 

A number of exceptions to the Disallowed security level require careful consideration while developing policies. For example, setting the security level to Disallowed will not prevent all software from executing on a machine.

 

List 12.3 highlights Disallowed security level exceptions:

 

There are two methods to determine which security level to use. If a comprehensive list of approved applications with their associated users has been developed, policies with the Disallowed security level can be created to allow only known trusted applications and files to execute (a white list policy). If no approved application to user list has been created, a policy with the Unrestricted security level can be developed to restrict only un-trusted applications or file types.

 

Once the default security level is selected, the next step is to create exceptions to the security level that allow or restrict an application to execute. For example, a Software Restriction Policy with the default security level of Unrestricted allows all applications to execute excluding applications that have been configured with exceptions. With this example, the exception to the Unrestricted security level specifies which applications are not allowed to execute. A Software Restriction Policy with the default security level of Disallowed allows exceptions to be created that define which applications are allowed to execute. Implementing the Disallowed security level involves significantly more upfront administrative work to determine exactly which applications are permitted and to test and validate the policy.

 

Regardless of the default security level, when a policy is created, the administrator must select one of four rules. Each rule uses a different evaluation criterion on the application or file. The four types of rules that can be selected are hash, certificate, path and Internet zone. Each rule uses a different strategy to evaluate if an application can or cannot execute.

 

It is possible that a file is subjected to more than one rule. When this happens, rules are evaluated in the following order: hash rule, certificate rule, path rule and finally the Internet zone rule. Also rules that more closely match a file will override more general rules.

 

While configuring a hash rule, one of the steps is to browse to the location of an application’s executable in order to calculate its hash value. A hash is a cryptographic fingerprint of a file that is created using a hash algorithm. The hash is used as a criterion to decide if the file is allowed to execute. When an attempt is made to execute a file, the hash value from the file is compared to the hash value from the rule. If the values match, then the file is processed based on the default security level, such as allowed to execute or not. If the hash values do not match the file, it will be prevented from opening. The hash values detects if a file has been altered in any way, such as from a virus or tampering since the creation of the hash rule.

 

A hash rule is an effective security control even if an application is renamed or moved because the hash value is based on a cryptographic calculation from the files contents. However, any changes to the application’s binary (i.e. updates, rebasing, re-linking, or digital signing) will result in changes in the hash value and the hash rule will no longer work. Hash rules can also be used to control the use of specific versions of an application, such as to deny one version with a known vulnerability to execute while allowing another trusted version to run.

 

A path rule can specify a directory or fully qualified path to an application as the criteria to determine if access is allowed. When a directory is specified, it refers to all applications within that directory and its subdirectories. Path rules can also be used to allow access to network resources, such as shared applications or scripts. Path rules support the use of environment variables, for example %program files%. Because a path rule is specified by its path, if an application is moved, the path rule will no longer apply. Path rules also support registry rules, which are handy security controls to manage what can execute out of registry autostartup locations, like the RunOnce key. The ability to control registry paths that perform autostartup tasks can control malicious code when it tries to install itself on a machine.

 

Path rules require the use of access control lists (ACLs) to control if code can be accessed and executed. When configuring a directory or a fully qualified path, it isnecessary to ensure that the ACLs are properly configured in order to avoid files system permission issues. Note that registry path rules are protected by default by ACLs and use embedded environment variables. Along with the ability to control registry autostartup locations, path rules can be used to prevent files with double extensions to execute. Double extensions are a common way to trick users into opening a virus. Virus writers use double extensions such as "I LOVE YOU.TXT.vbs" which is not a .TXT file, but a .vbs file. A path rule such as “*.???.EXE” will control the execution of code with three letter double extensions. It isimportant to note that the use of environment variables with path rules introduces risk because any user who can access a command prompt could change the environment variables for the duration of the session.

 

A certificate rule recognizes applications using digital certificates. The digital certificates are used as an evaluation criterionto determine if an application is allowed to execute. Certificate rules only apply to Windows Installer packages (MSI) and scripts that have been digitally signed. The digital certificate can validate if an application’s binary has changed since the digital certificate was created. The certificates used for a certificate rule should be supplied from the vendor or developer that developed the code. Certificates can be issued from a commercial or private Certificate Authority (CA).

 

A certificate rule is an effective security control even if the application is renamed or moved because it uses signed hashes contained in the signature of the signed file. Certificate rules are easier to manage than hash rules because one certificate rule can be used to allow all applications from a single source to be trusted automatically, based on the application’s digital signature. For example, an administrator can configure a certificate rule to allow only software signed by Microsoft to be installed. Certificate rules are a useful technique to trust software from a single source without the need to create rules for each individual piece of software.

 

An Internet zone rule uses Internet Explorer zones as the criteria to determine if software can be installed. Internet zone rules apply only to Windows Installer format (MSI) files; all other file formats cannot be controlled by Internet zone rules. The five zones are Internet, Intranet, Restricted Sites, Trusted Sites and My Computer.

 

When an MSI file is download, Internet Explorer determines from which zone the file originated and applies the appropriate security level based on the zone. For example, a policy can be created that allows files to be installed that originate from the Intranet or Trusted Sites zone. Conversely, downloaded MSI files that originate from the Internet or Restricted Sites zone can be restricted from installing.

 

Following an established logical process for decision making is the key to ensure that Software Restriction Policies will work. The first step is to specify the requirements and keep them at the forefront of all policy development decisions.

 

List 12.4 highlights a number of high level planning phase decisions used to develop Software Restriction Policies:

 

By default, Software Restriction Policies use the Unrestricted security level, which allows all software to execute. If a black-list policy is desired, the default security level can be used with the addition of exceptions to prohibit specific applications. If more control and a greater degree of security are required, a white-list policy can be implemented using the Disallowed security level, with exceptions that allow only known trusted applications and restrict everything else.

 

The default rules insure that when the Disallowed security level is used and no applications are specified as Unrestricted, the operating system will still work. It is possible to configure exceptions to control executables and drivers that reside within the default rules. Another consideration when using the Disallowed security level is how to deal with .dlls. Many applications have dependencies other than their executables, such as .dlls. There are two ways to manage .dlls. One is the default setting which assumes that .dlls are treated like the executable, either allowed or denied. The second option specifies if .dlls are treated as executables that require a rule for each executable and .dll. The latter option offers greater security with substantially higher administrative overhead. The settings are configured from the Enforcement Properties window.

 

Figure 12.1 shows the Enforcement Properties window.

 

Figure 12.1

 

Software Restriction Policies allow the configuration of designated file types to specify what an executable is, such as .exe, .dll, and .vbs. File types can be added or removed from the default list by accessing the Designated File Types properties window as shown in Figure 12.2. It isimportant to update the file type list routinely with new, executable file types to ensure they are secured. For example, if the security level is set to Disallowed and an attempt to execute an unlisted executable is made, the executable will run! Therefore, as new applications are placed into production or new vulnerabilities are identified, it is important to add the file types to the list.

 

Figure 12.2

 

 

List 12.5 highlights Software Restriction Policies best practices:

 

The next section will introduce an example Software Restriction Policy Baseline. It beginswith a Purpose and Scope statement and then proceeds with the procedure to configure a Software Restriction Policy. It concludes with a Policy Review and Compliance statement. This baseline is intended for informational purposes only.

 

 

The purpose of this baseline is to define standards for the configuration of Microsoft Software Restriction Policies. Software Restriction Policies provide the security controls needed to manage application and file execution entitlements as well as the ability to mitigate the introduction of hostile code through email or web browsing. Before any servers are placed on the production network, standard processes will be executed to ensure that all servers are installed and maintained in a manner that prevents unauthorized access, unauthorized use and disruptions in service.

 

This baseline is intended for all Windows Terminal Servers on the internal network and will be reviewed in conjunction with the other IT infrastructure policies.

 

The following procedure will create a test Group Policy Object linked to the WTS Organizational Unit. The Group Policy Object will be created, tested and validated in a lab or pilot environment on a test server. The test server will be provisioned identically as the production Terminal Servers. The Group Policy Object settings will be validated with non-administrative and administrative user accounts. While testing the Group Policy Object, the revision number will be appended to the end of the file name, such as. SRP_DEV01, SRP_DEV02, and so forth. After a Group Policy Object is validated, it will be named SRP_Prod_month/day/year and placed in production. Group Policy Object configurations will be made using the Group Policy Management Console.

1        Log on to a domain member server as administrator that has the Group Policy Management Console.

2        From the server desktop, click Start and then click Run, type “gpmc.msc /a.” Next, press Enter to access the Group Policy Management Console.

3        From the Group Policy Management console in the left pane, expand the “forest and domain” nodes and select the “WTS Organizational Unit.” Right click the “WTS Organizational Unit.” From the dialogue menu, click the “Create and link a GPO here” option.

4        From the New GPO window enter the name of the GPO, such as. “SRP_DEV01.” Click OK to proceed.

5        Once the Group Policy Management Console refreshes the new Group Policy Object will be listed under the WTS OU. Select the new Group Policy Object and right click it. From the dialogue menu select Edit to access its properties.

6        Navigate to the User Configuration > Windows Settings > Security Settings > Software Restriction Policies node. Right click the node and select the “New Software Restriction Policies” option.

7        Select the “Security Levels” node. Double click the “Disallowed security level.” From the Disallowed properties window, click the Set as default button. When presented with the Software Restriction Policies informational window, click Yes and then OK to close the Disallowed properties window.

8        Select and right click the “Additional Rules” node. Select the “New Hash Rule” option.

9        From the New Hash Rule properties window, click the Browse button and browse to the desired executable.

10    A hash value will be created, next set the Security Level to “Unrestricted.” Click OK to close the New Hash Rule properties window.

11    Close the Group Policy Object window and the Group Policy Management Console.

 

 

This policy will be reviewed quarterly.

 

Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

 

 

This chapter beganwith an overview of why organizations implement application access restrictions, then introduced Microsoft Software Restriction Policies and concluded with an example tier 3 Software Restriction Policy Baseline.

 

The next chapter will review Microsoft Session Directory functionality and introduces two tier 3 Session Directory Configuration Baselines.