Threats and Countermeasures Guide: Software Restriction Policies

  • Статья

Applies To: Windows 7

This topic for the IT professional discusses security threats against the Software Restrictions Policies feature in the Windows operating system and countermeasures that you can take to mitigate those threats in Windows Server® 2008 R2 and Windows® 7.

Overview

Software restriction policies provide a policy-driven system to specify which programs are allowed to run on the local computer and which are not. The policy settings were introduced in Windows Server 2003 and Windows XP. In Windows Vista and Windows Server 2008, the default hash rule algorithm was upgraded from Message Digest version 5 (MD5) to the Secure Hash Algorithm-256 (SHA256). SHA-256 is a 256-bit (32-byte) message digest hash, and it is meant to provide 128 bits of security against collision attacks. It is considered much stronger than MD5, which has known vulnerabilities. MD5 is still supported for compatibility with Windows XP. In addition, certificate rules can be activated from within the Software Restriction Policies snap-in extension instead of from within the Local Security Policies snap-in.

No improvements to Software Restriction Policies were made for Windows Server 2008 R2 and Windows 7. However, AppLocker™, which is an improved application control policy feature, was introduced.

Software Restriction Policies settings

The increased use of networks and the Internet in daily business computing means that it is more likely than ever that an organization's users can encounter malicious software. Software restriction policies can help organizations protect themselves because they provide another layer of defense against viruses, Trojan horses, and other types of malicious software.

You can configure the Software Restriction Policies settings in the following location within the Group Policy Management Console:

Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies

Vulnerability

People use computer networks to collaborate in many ways; they use email, instant messaging, and peer-to-peer applications. As these collaboration opportunities increase, so does the risk from viruses, worms, and other forms of malicious software. Email and instant messaging can transport unsolicited malicious software, which can take many forms—from native Windows executable (.exe) files, to macros in word processing (.doc) documents, to script (.vbs) files.

Viruses and worms are often transmitted in email messages, and they frequently include social engineering techniques that trick users into performing an action that activates the malicious software. The amount and variety of forms that malicious software can take make it difficult for users to know what is safe to run and what is not. When activated, malicious software can damage content on a hard disk drive, flood a network with requests to cause a denial-of-service (DoS) attack, send confidential information to the Internet, or compromise the security of a computer.

Note

Software restriction policies do not prevent restricted processes that run under the System account. For example, if a malicious program has set up a malicious service that starts under the Local System account, it starts successfully even if there is a software restriction policy configured to restrict it.

Countermeasure

Create a sound design for software restriction policies on end-user computers in your organization, and then thoroughly test the policies in a lab environment before you deploy them in a production environment.

A policy consists of a default rule that specifies whether programs are allowed to run and exceptions to that rule. The default rule can be set to Unrestricted (the program is allowed to run) or Disallowed (the program is not allowed to run).

Setting the default rule to Unrestricted allows an administrator to define exceptions (programs that are not allowed to run). A more secure approach is to set the default rule to Disallowed, and specify only the programs that are known and trusted to run.

There are two ways to use software restriction policies:

  1. If an administrator knows all of the programs that should run, then a software restriction policy can be applied to allow only this list of trusted applications.

  2. If all the applications that users might run are not known, then administrators can disallow undesired applications or file types as needed.

Software Restriction Policies has four rules with which to identify software. The purpose of a rule is to identify one or more software applications, and specify whether or not they are allowed to run. Creating rules largely consists of identifying software that is an exception to the default rule. Each rule can include descriptive text to help communicate why the rule was created.

A software restriction policy supports the following four ways to identify software:

  1. Hash: A cryptographic fingerprint of the file.

  2. Certificate: A software publisher certificate that is used to digitally sign a file.

  3. Path: The local or universal naming convention (UNC) path of where the file is stored.

  4. Zone: The Internet zone as specified through Internet Explorer.

Potential impact

A flawed software restriction policy implementation can disable necessary applications or allow malicious software to run. Therefore, it is important that organizations dedicate sufficient resources to manage and troubleshoot the implementation of such policies.

Note

Although software restriction policies are an important tool that can enhance the security of computers, they are not a replacement for other security measures such as antivirus programs, firewalls, and restrictive access control lists (ACLs).

Additional references

The following links provide additional information about designing and using software restriction policies: