S 4.286 Use of software restriction policies under Windows Server 2003

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Users are often confronted with unknown software through intensive use of the Internet (WWW, email, etc.), among other factors. The user must decide in such cases if they want to use this software. For example, malicious software often camouflages itself as a Trojan horse to entice the user to install and run the software. It is often difficult for the user to decide which software he can or should run. By applying software restriction policies, the IT environment can be protected against undesired and untrustworthy software.

After completing a standard Windows Server 2003 installation, at least one local software restriction policy should be created:

Start | Control Panel | Administrative Tools | Local Security Policy | open the context menu of Software Restriction Policies and select the New Software Restriction Policies option

Settings in Trusted Publishers:

Designated file types are the file types affected by the software restriction policies. For this reason, the Designated file types list should be updated regularly. The virus protection policies of the IT systems containing definitions of the critical file extensions can be used as a reference, for example.

The other settings should be left at their default values in normal cases. The predefined rules in particular should not be changed since the system could be placed in an unusable state otherwise. The policies should always apply to all users, including the administrators.

Types of additional rules

Type of rule Explanation Reliability of the security safeguard
Hash rule When a file is accessed, its hash value is calculated and then compared to a hash value stored earlier. The rule takes effect when the hash values are identical. However, if the contents of the file were manipulated in the meantime, then the hash value will change and the rule will not take effect any more! medium
Certificate rule The certificate rule identifies software based on an Authenticode Certificate from the software publisher and permits execution in protected areas of the server depending on the security level. medium
Path rule The path rule identifies software based on file path specification. The rule becomes invalid when the program is moved. low
Internet zone rule Zone rules only apply to .msi files (Windows Installer packages) low

Use of the software restriction policy

The software restriction policy requires detailed planning as well as adequate testing in a test environment, especially when the default value for the security level was set to Disallowed. When implementing the policy, hash and certificate rules should be preferred since the path and Internet zone rules only offer a low level of protection against the execution of programs and program libraries. In addition, the Microsoft Knowledge Base should also be consulted so you can avoid any unexpected and undesired effects already documented there when applying hash rules.

In the software restriction policy, the DLL libraries can be blocked right from the start. In this case, you will need to define a large number of rules for those libraries expressly permitted. The DLL libraries are frequently accessed when a program is executing, and the entire list needs to be processed in this case. Effects on the performance should therefore be taken into account as well.

The policy should be applied mainly to exposed servers with high security requirements such as on bastion hosts (publicly accessible computers connected to the corporate network) to minimise the number of possible points of attack for malicious software. The policy enabled and the corresponding rules set up cannot replace anti-virus software. To protect against security incidents, for example in connection with malicious software, the software restriction policy can be applied as a precautionary safeguard or a contingency safeguard.

If a software restriction policy is distributed via the group policies of the Active Directory, then a separate group policy object should be created for this purpose. The rules in the default group policies should not be changed. If unexpected and undesired effects are detected during live operation, then the separate group policy object can be disabled easily and the default rules can then take effect.

Documentation

All rules except for the predefined rules should be documented. The purpose of each rule should also be documented.

Review questions:

© Federal Office for Information Security. All rights reserved.