S 4.244 Secure configuration of Windows client operating systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The security of a workstation computer depends primarily on whether or not users are able to perform administrative tasks on the computer, which functions are made available to the users, and if the users use the security mechanisms provided correctly.

When configuring Windows XP, Windows Vista and Windows 7, the following aspects must be taken into account from a security perspective:

Data storage and processing

It is recommended not to store any data locally on workstation computers when the clients are networked. This makes it easier to administer the systems centrally, control security policies, and back up data. In addition, a security advantage is gained because even if a client is compromised, no sensitive data will be found locally since it is stored on a server, which as a rule is better protected than a client. In individual cases, it may be necessary to store data locally on a workstation for security reasons, for example when only the workstation user is allowed to access the data and it will not be transmitted over the network. In this case, though, the workstation should not be considered a standard workstation, which means that special rules must be planned and implemented for such workstations. Examples of appropriate safeguards include protecting the clients with strong security mechanisms ("hardening") locally as well as in the network, the use of hard drive encryption, and the integration of the clients into a central backup concept.

Confidential data must be processed securely. It is not only necessary to restrict direct access to the data according to the authorisation concept, but also to ensure that it is impossible for unauthorised persons to access temporary contents. Many applications generate temporary files while operating, and these files may not be adequately protected, in contrast to the original data. For this reason, it is highly recommended to clean up the directories in which temporary files are stored on a regular basis (e.g. TEMP, TMP, and the printer spool directory). This can be realised using a script that is executed when the system shuts down (see S 2.326 Planning the Windows XP, Vista and Windows 7 group policies). The swap file is deleted by the Shutdown: Clear virtual memory pagefile policy in Group Policy Objects when the system shuts down. In Windows Vista or Windows 7, this is done using the setting Shutdown: Clear virtual memory pagefile under Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.

Software restrictions

The system configuration should be specified so that normal users cannot perform administrative tasks. This can be achieved using the access rights to files and the registry or the right to start the configuration tools, for example the Microsoft Management Console. These settings are administered using group policies, and the settings should be planned when planning the group policies. The use of software restriction policies (SRPs) and, in Windows 7 and higher, AppLocker can also provide additional security in this context.

Only authorised administrators should be allowed to install software. The ability for normal users to install software should be restricted to the greatest extent possible (see S 2.9 Ban on using non-approved hardware and software). Installations performed using the Windows Installer can be restricted by defining suitable group policies in Computer Configuration | Administrative Templates | Windows Components | Windows Installer. If and to what extent the right to install software needs to be restricted depends on the software installation policy of the company or government agency. It should be noted that these settings only apply to the Windows Installer and do not prevent users from installing or updating other programs.

The software restriction technology introduced in Windows XP allows you to restrict the programs that can be run on a given computer. By defining software restriction policies in the Computer section of a GPO (Computer Configuration | Windows Settings | Security Settings | Software Restriction Policies), it is possible to specify the set of allowed programs (positive list) or of the prohibited programs (negative list).

A positive list should not only allow the applications, but also all system programs required for regular operation.

A program can be identified in a software restriction rule using a fully or partially qualified path name, a hash value, a digital signature or certificate, or the program zone (for example Internet, Local Computer). It is not only possible to apply a rule to normal executable files, but also to DLLs, ActiveX control elements, Windows Installer files, and VBScript files, among others.

The configuration options available for restricting execution of a program using SRP are very flexible and allow a number of operational scenarios to be realised. However, this advantage comes at the expense of considerably more administration since the rules defined can quickly become complex and disorganised. Comprehensive planning and extensive testing are essential if a company or government agency decides to implement software restriction policies.

Windows Vista and Windows 7 offer Parental Controls as another way to restrict the use of applications (see S 2.32 Establishment of a restricted user environment). However, parental controls are not designed for professional use and not available in a domain environment. If under-age persons have access to clients in the institution, the restrictions possible using the parental controls should be realised by implementing alternative safeguards.

Services

Windows XP, Windows Vista and Windows 7 are not server operating systems and should only be used on clients and should not make any applications or services available in the network. Among other things, normal workstation computers should not make any directory shares available other than the default administrative shares. If the administrative shares are not used for administration, then they should be deactivated (HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameter\AutoShareWks=0).

If shares on the clients are necessary for certain reasons, then the simple file sharing mechanism introduced in Windows XP should not be used so as to avoid the security risks involved in its use. If simple file sharing is enabled on a client, then all users who access this computer over the network will be assigned to the Guest account. The authorisations for accessing the share must be granted as restrictively as possible, though. It must be taken into account that simple file sharing is only possible by default on stand-alone clients not belonging to any domain. On clients installed as domain members, simple file sharing is deactivated by default. Under Windows 7, folder sharing can be accessed via the context menu and is called Share with. To share a folder in a domain environment, administrator rights are required.

The overall security of an IT system also depends on which system services are used. Information on the secure configuration of services can be found in S 4.246 Configuration of the system services under Windows XP, Vista and Windows 7.

In Windows 7 and higher, an IT system can be used as a dedicated print server. In this case, this IT system must not be used for any other purpose. The hardware of the IT system and the access security must meet the corresponding server requirements (see also module S 3.101 General server). All application functions must be disabled.

User accounts

A user account in Windows XP, Windows Vista and Windows 7 should only be used by the person authorised to use it, which means the user account must be assigned to a single user. The primary reason for this is to ensure it is possible to determine which user is assigned which account. Shared accounts should not be used whenever this is possible. This must be guaranteed at the organisational level.

If a new user account is created in the Active Directory, then it must be ensured that the user account is assigned to the right organisational unit since the correct security settings for this user account are determined using the OU specified. The rights granted to a user result from, among other things, his group memberships and the group policies linked to the organisational unit of the user.

If the Windows XP, Windows Vista or Windows 7 system is administered using personal user accounts, then the built-in administrator account can be locked. This account is locked by default in a standard Windows Vista and Windows 7 installation.

The administrator account should always be renamed. The built-in administrator account can be deactivated or renamed in the user administration or using the policies of the accounts: Administrator account status and Accounts: Rename administrator account (in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options). It is recommended to run a test phase before deactivating the administrator account in which administration is only performed using the personal user accounts.

All Windows versions contain a Guest account by default. The Guest account should not be used, and users should always use a dedicated user account. The Guest account should be deactivated, but a complex password should be assigned to the account in spite of this. In a standard Windows Vista or Windows 7 installation, the Guest account is deactivated by default, but no password is assigned to the account. Setting a password provides corresponding password protection even if the Guest account is activated unintentionally or without authorisation. The Guest account can be renamed and deactivated in the local user administration or using the Accounts: Guest account status and Accounts: Rename guest account policies (in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options).

The account for support users (SUPPORT_388945a0) created by default in Windows XP is normally not used in government agency and corporate environments and should be deleted for this reason. The local user administration is used to delete this account. In Windows Vista and Windows 7 and higher, the user account for support users is no longer available.

When operating a Windows system in a domain, no additional local user accounts should be created, if this is possible. In general, only those accounts absolutely needed locally should be created locally. The local user accounts should be checked at regular intervals.

According to S 4.2 Screen lock, password protection for the screen saver must be enabled for every user. If the computer is configured to go into Standby mode, then users must be required to enter the password when resuming the system from the Standby mode (Control Panel | Power Options | Advanced | Prompt for password when computer resumes from standby).

The requirements in S 2.11 Provisions governing the use of passwords and S 4.15 Secure log-in must be implemented. This applies especially to the length, quality, and change interval of the passwords, the number of failed attempts to enter the password, and when a user account should be locked.

Securing the login procedure

Access to the system must be limited to authorised persons only. The corresponding user rights must be assigned restrictively as required (see S 4.247 Restrictive assignment of authorisations under Windows Vista and Windows 7). In general, administrative access over the network should only be allowed for authorised administrative personnel. Furthermore, logins over the network to local user accounts without a password must be prohibited. This is achieved by enabling the policy Accounts: Limit local account use of blank passwords to console logon only (in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options).

Automatic user logins must be deactivated on all Windows installations. Administrative users provide explicit authentication. Automatic login to the Recovery Console must be prohibited as well and the access to data outside the system directory must be restricted. Otherwise, it may be possible to access data without authorisation, and such access cannot be logged, either. To implement these restrictions, deactivate the following policies: Recovery Console: Allow automatic administrative logon and Recovery Console: Floppy copy and access to all drives and folders policies (in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options).

In a standard installation of Windows Vista and Windows 7, the built-in administrator account is deactivated. Since this account is not assigned a password in a standard installation, a password should be assigned to the built-in administrator account after installation.

All users must provide explicit authentication before they are granted access to the system. Users should be required to enter the keyboard shortcut CTRL+ALT+DEL when logging in (deactivate the following policy: Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Interactive logon: Do not require CTRL+ALT+DEL). This guarantees that the original login screen is used and that no forged login screens can appear.

In addition, the name of the last user who logged in should not be displayed in the login screen (policy: Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Interactive logon: Do not display last user name).

It is also recommended to display a warning whenever a user attempts to log in locally. The exact text of the warning depends on the specific circumstances and should be defined on a case-by-case basis. The text of the warning and the message title are specified with the help of the Interactive logon: Message text for users attempting to logon and Interactive logon: Message title for users attempting to logon policies in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options.

Login information for domain accounts are stored temporarily by default so that a user can still log in to his client even when the domain controller is unavailable. The number of accounts for which such information is stored temporarily is specified in the policy in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Interactive logon: Number of previous logins to cache and should be set to the lowest value possible. The actual parameter setting used depends on the specific circumstances and should be defined on a case-by-case basis.

System settings

The Autostart functionality is enabled by default in a standard installation of Windows and therefore poses a security risk since hazardous content can be executed without any user interaction. For this reason, the Autostart function should be disabled on all drives (see also S 4.57 Disabling automatic CD-ROM recognition and S 4.339 Prevention of unauthorised use of removable media under Windows Vista and Windows 7). To do this, it is necessary to activate the policy Computer Configuration | Administrative Templates | System | Disable Autoplay and set the value to All drives. In Microsoft Windows Vista and Windows 7, the corresponding setting is found in Computer Configuration | Administrative Templates | Windows Components | Autoplay Policies | Turn off Autoplay.

Internal system objects (mutexes and semaphores, for example, which are used to synchronise different threads and processes) possess their own access rights. These access rights can be restricted by defining a special policy that denies non-administrative users the right to change objects not created by them (Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | System objects: Strengthen default permissions of internal system objects (e.g. symbolic links).

Normally, Windows allows both local as well as remote access to diskettes and CD-ROMs. However, as recommended in S 4.52 Device Protection under Window NT/2000/XP, access should be restricted to the user currently logged in.

Autonomous communication over the Internet by Windows

The default configurations of several Windows services and applications allow the services and applications to contact servers in the Internet automatically and without informing the user. When such contact is made, system-specific and/or user-specific data is transmitted to Microsoft or other providers.

The following list provides an overview of the services and applications that autonomously transmit data to Microsoft. This list is by no means complete.

It is recommended for most of the services and applications listed above to disable the transmission of data. This can be achieved by reconfiguring the registry and program options accordingly, making changes in the file system or using security gateway filters. The manageability of this function was significantly improved with the introduction of Service Pack 2. A new category was added to the group policies in Computer Configuration | Administrative Templates | System | Internet Communication Management.

Enabling or integrating hardware security functions

A driver should be installed for every activated hardware connected to the Windows system.

Only the most recent drivers certified by Microsoft should be used for security functions such as biometric devices, smartcards and hard drive encryption. If possible, such hardware should be used in combination with the built-in Windows security APIs, for example, Biometric Framework and Smartcard Authentication.

The Data Execution Prevention (also referred to as Opt Out) should be switched on for all programs and services, if possible.

Basic settings for Group Policy Objects (GPOs)

The basic settings for group policy objects in Windows Group Policy Objects are described in S 4.245 Basic settings for Windows Group Policy Objects.

Review questions:

© Federal Office for Information Security. All rights reserved.