S 4.419 Application control in Windows 7 and higher by means of AppLocker

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Software configuration and installation

In some cases, the software configuration of a client deviates from the specified default configuration just after it has been provided unless this is prevented by technical means. In general, these deviations increase the longer the client is in use. The cause for this is installations by the end users which do not pass by the default change management process. On the one hand, these installations can be useful tools for daily work. On the other hand, often software which has nothing to do with normal operation is installed. In both cases, however, the defined change management process should be performed.

Due to the installation of this additional software, an administrator quickly loses track of the current software configuration on the clients. This can result in any occurring errors becoming no longer comprehensible for an administrator. Even more serious, however, is the fact that the software installed in addition is not covered by the patch and change management (see S 2.273 Prompt installation of security-relevant patches and updates). Thus, security gaps in the software can be used by attackers in order to smuggle in and execute, for example, malicious codes on the clients.

On server systems, too, software may not be installed in an uncontrolled manner. For example, when a backup administrator wishes to use certain tools, they should not simply install them, but integrated them via the change management process. Thus, the installation is documented and the tools are included in the patch management.

AppLocker

The AppLocker feature introduced with Windows 7 Ultimate, Windows 7 Enterprise and Windows Server 2008 R2 helps the administrator to keep the systems under control by preventing the unauthorised installation and execution of software by other users by technical means.

AppLocker should be used to protect system integrity.

AppLocker is a development of the Software Restriction Policies (SRP) which are used in the Microsoft Windows XP, Vista and Server 2003 operating systems (see S 4.286 Use of software restriction policies under Windows Server 2003). When configuring these policies, however, the administrator must generate a separate rule for each software and each required update. This can result in a great deal of time and effort for administration.

In contrast to software restriction policies, AppLocker offers administrators more flexible options to define policies for software control that meet the requirements of the organisation. Examples of this include the wizards and rule generation tools by means of which rules can be generated automatically. They should be used in order to define, for example, the default rules allowing the execution of important system files. In addition to this, the step-by-step instructions and the integrated help support the administrator when configuring user-defined rules. In addition to the default rules, policies should be defined for executable files, installation programs, scripts and DLLs. The policies can be configured separately and provide better protection of the systems, as they are not limited to executable files exclusively.

Rules

There are three types of rules: Allowed, Denied and Exception. By means of these rule types, rules allowing the execution of the default software defined in the organisation (positive list) or denying the execution of known malicious software (negative list) can be defined. The method denying all applications and only allowing the installation and execution of software on the positive list should be selected. Thus preventing that the software not yet included in the negative list can be installed and executed.

The default rules evaluate the file or folder path or a hash value via the executable file ("file hash") of the software. In addition to this, rules based on application signatures are possible. The following aspects need to be considered in this regard:

Rules based on the file or folder path

If, for example, a rule allowing the execution of all software under C:\Programme is defined, the protection can be bypassed by moving an executable file of a locked software into this folder. In this case, local administration rights of the end users are required. This should be prevented by means of corresponding safeguards (see S 2.32 Establishment of a restricted user environment).

Rules based on the file hash

A file hash can be referred to as a cryptographic fingerprint of a file. This rule type can be used when an executable file is not digitally signed. After each software update, the hash must be generated again and the rules adjusted. This can result in high time and effort for administration. For this reason, the rule types either based on the file or folder path or based on the digital application signature should be preferred over this rule type.

Rules based on application signatures

If the file is electronically signed, publisher rules based on the digital application signatures should be defined. When using this method, it must be ensured that the application identity service (AppIDSvc) is executed on the client.

When using application signatures, the "Any publisher" security level should not be selected, but at least the respective publisher defined. Providing additional attributes such as the version number, the rule can be restricted further. For example, an application can be executed in a certain version and higher provided it was signed by the publisher. Older versions are not executed; newer versions, however, are allowed automatically

The IT Security Officer and the Head of IT are responsible for developing the positive and the negative list. Together with the heads of departments and the end users, they should include their respective requirements, check them for completeness and review the lists at regular intervals. If necessary, modifications must be made.

Group policy management

The application control should be implemented by an administrator. In a domain network, the rules should be configured centrally using the group policy management. Here, the Windows Server 2008 R2 domain functional level is required. In a domain with the Windows Server 2008 functional level, the application control can be configured using corresponding client administration tools (for example, the remote server administration tools for Windows 7).

Using group policy objects (GPOs), different rule sets should be defined and assigned to certain users or groups afterwards. For example, it can be specified that the administration tool for the central database may only be carried out by the development department. The Microsoft Office Suite, however, can be used by all employees of the organisation with its complete range of functions.

The required settings can be found in the group policy management editor under Computer Configuration | Policies | Windows Settings | Security Settings | Application Control Policies | AppLocker.

Logs

If a user tries to start an application contrary to the rules defined in AppLocker, AppLocker prevents the program from being executed and documents the process by means of an entry in the system log. In order to detect and solve attempted manipulations, the system log must also be evaluated at regular intervals with respect to the AppLocker entries. Ideally, the system logs are brought together on a central log server for this purpose and evaluated automatically.

When AppLocker is introduced on a productive system, it can also be operated in the monitoring mode for a certain transitional period. In this mode, the program is not prevented from being executed if a rule is broken, but a log entry is still written. Evaluating the logs, programs not yet adequately covered by the set of rules can be identified.

Review questions:

© Federal Office for Information Security. All rights reserved.