S 4.146 Secure operation of Windows client operating systems

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator, Head of IT

After installation and initial configuration according to the Windows concepts and security policies planned in advance, the Windows systems are generally operated in a network. On the one hand, the security of such a network depends on the configuration parameter settings. However, another factor significantly affecting network security is the way in which changes need to be made to the configuration during live operation. The side effects of such changes in particular need to be taken into account since the changes can unintentionally open up security gaps under some circumstances.

The Windows client versions offer a series of tools and mechanisms to help administrators maintain the level of security of a running system:

• Windows File Protection or Windows Resource Protection is a system mechanism in Windows ensuring that system files remain in their original, unchanged states. The mechanism uses two components: The SystemFileChecker (sfc.exe), which checks the system files, for example when the system starts, for their integrity and replaces any changed files with original files from temporary storage. Furthermore, there is a monitoring mechanism that replaces a system file with its original version after an attempt to write to the file. The mechanism can also be configured so that the changed file is kept after receiving a corresponding user confirmation. The sfc.exe program can be used with the following command line parameters:

Windows 2000:

• sfc /ENABLE: The changes are applied after confirmation.
• sfc /QUIET: Changed files are replaced by the originals without prompting for confirmation.

Windows XP:

• sfc /SCANNOW: Immediately checks all protected system files.
• sfc /SCANONCE: Checks all protected system files once the next time the system is started.
• sfc /SCANBOOT: Checks all protected system files every time the system is started.
• sfc /REVERT: Resets the settings of the program to the default settings.
• sfc /PURGECACHE: Empties the file cache.

Windows Vista and Windows 7:

• sfc /SCANNOW: Checks the integrity of all protected system files and repairs any files with problems, if necessary.
• sfc /VERIFYONLY: Checks the integrity of all protected system files. No files are repaired.
• sfc /SCANFILE: Checks the integrity of the specified file and repairs the file if problems are detected. The file must be specified with its full path.
• sfc /VERIFYFILE: Checks the integrity of the specified file. No files are repaired.
• sfc /OFFBOOTDIR: Specifies the storage location of the offline boot directory for offline repairs.
• sfc /OFFWINDIR: Specifies the storage location of the offline Windows directory for offline repairs.

To be able to perform the steps mentioned above, administrator rights are required.

• With Windows XP, the automatic system recovery was introduced. This mechanism can be used to recover a previous system state, for example when a software installation fails and the system is put in an unstable state. Depending on the local circumstances, and especially on the software distribution strategy implemented, the use of automated system recovery can offer advantages, for example in a test environment.
  
  Windows Vista offers two ways of restoring a damaged system: using Control Panel | Backup and Restore and the Restore your entire computer from a Windows Complete PC Backup and Restore image option. In Windows 7 and higher, these settings can be found under the following path: Control Panel | Recovery | Open System Recovery.
  
  System recoveries may only be carried out by administrators responsible. The configuration of the recovered system must be checked for conformity with the currently valid security policies to ensure that the security of the information system is not at risk. Special care must be taken to ensure that no critical patches, updates or settings are reset. If necessary, they must be reinstalled and reconfigured.
• Windows contains tools for configuring the security settings of Windows client computers: the command line-based security editor secedit.exe and the Security Configuration and Analysis MMC snap-in. The security configuration can also be stored in a database and then used as the basis for checking a computer for conformity. To do this, you first create a database with the Security configuration and analysis MMC snap-in (Operation/Open Database, enter new or existing database name). The database can then be initialised using a security template (.inf file, see Security Templates MMC snap-in). Using Operation/Analyse Computer Now and Operation/Configure System Now, it is possible to analyse or configure the system based on the settings in the database. The database itself is a file-based database (.sdb file) and can be copied to other systems. This information is not of much use, though, when the access rights deviate at the file or registry level since only the fact that they deviate is documented, but not which access rights actually deviate.
• When operated in a domain, the security settings of a Windows client are generally specified by applying group policies or the settings contained in an object. In this manner, it is also possible to efficiently and centrally administer the security settings, even for large Windows networks. The changes to group policy objects (GPOs) settings are made centrally on a domain controller and are then distributed to the computers affected. The GPO mechanism can be configured so that the GPO settings are updated periodically so that the changed settings can take effect (see also S 2.231 Planning of group policies under Windows and S 2.326 Planning the Windows XP and Windows Vista group policies).
• The security of accesses to the system can be increased using a smart card-based login procedure. Authentication in this case is not performed using a user name and a (possibly weak) password, but using a certificate stored on a chip card instead. Windows can be configured so that users can log in both by entering a user name and password and a chip card or by using a chip card only. Generally, only Microsoft-compliant certificates and chip cards supported by the Windows operating system can be used. Along with BitLocker and the procedure supported for authentication of the user before starting the operating system, Windows Vista and Windows 7 offer another way to deny unauthorised persons access to the system (see S 4.337 Use of BitLocker drive encryption for more information).

The security of an information system always depends on the physical security of the IT systems and network components as well. Their physical security must be ensured when operating a Windows client system. The following generally needs to be taken into account for the secure operation of a Windows client system:

• The security of Windows depends primarily on the security of the Active Directory. On the one hand, the information stored there must be protected against unauthorised changes, and on the other hand, the same data needs to be kept consistent. This requires the corresponding care to be taken, especially when making changes. It is urgently recommended not only to define the values or ranges of values of parameters in the framework of security planning, but also to define internal or administrative procedures that are suitable for implementing the specified security policy. For example, it should be specified which steps need to be taken to delete or create a new user account so that all necessary changes are made correctly. Additional information on the secure operation of Windows clients in an Active Directory can be found in S 5.16 Active Directory.

In addition to guaranteeing the security of the Active Directory and the system security, which depends on the parameters specified in the Active Directory, it is also necessary to guarantee the security of important system services. The security of the DNS, WINS, DHCP, RAS, and Kerberos services play a particularly crucial role in this regard.
It must be ensured in this case as well when changes are made that the currently valid and defined security policies are not violated. Information on how to configure these services can be found in S 4.246 Configuration of the system services under Windows XP, Vista and Windows 7 and in the safeguards referenced there.

• The Microsoft Management Console snap-ins (MMC snap-ins) are available by default for the administration of a Windows client system. MMC snap-ins are management modules that can be integrated into the MMC over a standardised interface. For this reason, access to the various MMC snap-ins must be regulated. Normal users generally should not be allowed to access the system administration tools. One exception to this rule is the MMC snap-in for administering certificates, which also needs to be used by normal users to manage their own certificates. Access to the individual MMC snap-ins can be finely controlled via the GPO settings.
• Normal users should not be granted access to the administrative tools used to access the local registry of a computer (regedt32 and regedit). This can also be accomplished via the GPO settings (see S 4.75 Protection of the registry under Windows systems).
• The security of a Windows network depends on many factors. In particular, security gaps can arise through the use of additional applications that are either incorrectly configured or contain programming errors. In many cases, problems only occur when several applications are operated together for the first time. For this reason, tests must be performed before introducing a new application to determine if there are any obvious problems. It is impossible to be fully certain that no problems will occur, though, because it is particularly difficult and extremely complicated to test for side effects in other applications.
• Even when the changes are implemented carefully and all precautions are followed, it is impossible to completely rule out the existence of security gaps in a complex system. For this reason, a system must always be properly monitored (see S 4.148 Monitoring a Windows 2000/XP system and S 4.344 Monitoring of Windows Vista, Windows 7 and Windows Server 2008 systems). The depth and precision of monitoring must be adapted to the threat scenario. The type and manner of monitoring can only be specified for a specific case. In general, the tasks of the administrators should also be monitored. In addition, it is recommended to audit the systems regularly to detect any gaps arising due to changes to the system.
• From a security perspective, changes to the domain structure are also critical. For this reason, such changes should only be made after careful planning. It must be taken into account, even in the initial planning phase, that a Windows domain structure (separation into domains, trees, and forests) only permits minor changes after it has been set up (see S 2.229 Planning Active Directory).
• From a security perspective, it is also important to document all policies, rules, and processes that affect the operation of a Windows client system. Operation manuals should be created for this purpose, and it must be required to update the manuals when changes are made to the system. Since the operation manuals contain security-related information, they should be stored so that unauthorised persons cannot gain access to them while simultaneously allowing authorised administrators easy access.

The recommendations provided can only be of a general nature since the maintenance of system security also depends on the local conditions. For this reason, corresponding policies for secure operation of a Windows network must be created as early as the network planning phase, which take the local requirements into account. Under some circumstances, it may be impossible to securely configure certain security mechanisms optimally. This is the case, for example, when you need to continue using "old" applications that are only designed for use with weak authentication (or no authentication at all). In this case, corresponding countermeasures must be implemented at another location - or at the organisational level - to guarantee a satisfactory level of security.

The security of a Windows system during live operation depends primarily on the knowledge of the administrator. For this reason, the training and further education of the system administrator is an important safeguard (see also S 3.27 Training to Active Directory Administration), since potential security gaps can only be detected and avoided by competent administrators. In addition, normal users also need to be trained on security aspects (see also S 3.28 User training on Windows client operating system security mechanisms) so that they know the potential risks involved and can use the security mechanisms correctly.

Review questions:

• Are the depth and precision of the system monitoring of Windows client operating systems adapted to the threat scenario?
• Is access to all administration tools of Windows client operating systems prohibited for users?
• Are function and security tests performed before new applications are introduced on Windows client operating systems?
• VoIP in the WLAN: Is qualified protection of the WLAN guaranteed?