S 4.249 Keeping Windows client systems up to date

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: Administrator

Experience has shown that security-related updates or patches, which are released regularly by Microsoft, must be installed promptly. In practice, though, this often leads to problems because, on the one hand, the updates need to be installed as quickly as possible, but on the other hand, they need to be tested thoroughly before installation. There is no generally applicable solution to this problem. Here, a suitable compromise must be made that meets the security requirements while still being practicable.

S 2.273 Prompt installation of security-relevant patches and updates must be taken into account during planning.

• A process for handling patches and updates must be established at the organisational level (e.g. in the framework of change management).
• The process must not only take updates and patches for Windows systems into account, but also any updates and patches for the applications used (e.g. Microsoft Internet Explorer, Microsoft Office and software from third party manufacturers in particular).
• Administrators need to inform themselves regularly on weaknesses and the security updates available.
• The installation and testing of the updates must be tested on a test system.
• A strategy for recovering operability of the systems in case of problems must be available.

Checking the patch status

To keep an existing Windows system up to date, it is necessary to compare the current patch status of the system with the updates available from Microsoft. Microsoft offers a tool, the Baseline Security Analyzer (MBSA), that can be used to automatically evaluate the status of the system. The use of this tool or a comparable tool provides the administrators with a current overview of the patch status of the systems, and therefore contributes significantly to the overall security. The MBSA tool can be configured so that the comparison is not performed using a Microsoft server in the Internet, but using an internally installed Microsoft Windows Server Update Service (WSUS) instead. In this manner, the current status of the system can be compared with the company-specific target status. This approach is used primarily to test if the patches and updates released by the company are installed on all systems. It is also possible to store the test results directly in the SMS database by integrating the MBSA tool into the Microsoft System Management Server (SMS).

The MBSA tool has a graphical user interface (mbsa.exe), but it can also be controlled using the command line (mbsacli.exe). With the command line, it is possible to integrate the tool into an automated process so that the results can be processed further automatically (e.g. using scripts).

Using the MBSA tool, the patch status of the operating system and other Microsoft applications such as Microsoft Office, Exchange Server, Microsoft Internet Explorer (here, also the zone configuration in particular) can be checked. The checks can be executed locally and, for the most part, remotely as well.

Updating methods

To update a Windows system, it is possible to use the integrated Automatic Updates functionality of Windows or to install the updates and patches using a different (external) software distribution mechanism. The strategy to be used must be selected based on the specific circumstances and on a case-by-case basis. If an external software distribution mechanism is used, then the Automatic Updates function must be disabled so that the mechanisms cannot interact and cause problems due to their parallel use.

When the Automatic Updates function of Windows is used, the following configuration options are available:

• Updates are downloaded automatically and installed in accordance with the schedule defined (in Windows XP without Service Pack 1, this functionality is only available after updating to the newest version of the Automatic Updates software).
• Updates are downloaded automatically, but not installed automatically. The user is informed about available updates.
• When new updates are available, the administrator is notified of the availability of the updates, but the updates are not downloaded.
• In Windows Vista and higher, updates which are recommended but not critical can be directly excluded from the automatic installation temporarily on individual clients (Windows Update | Change Settings | Recommended Updates). Normally, the updates, however, should be selected centrally using the software distribution.

The updates should not be installed manually. To keep the time between the announcement of a security gap and the closing of the security gap as short as possible, it is recommended to install released updates automatically using the Automatic Updates mechanism or an external software distribution mechanism.

Since direct connections to the Internet are to be avoided from a security perspective and the updates to be installed are to be tested first in test systems, it is not recommend to update Windows systems directly from external sources (e.g. Microsoft) when using the Automatic Updates mechanism. Instead, the Windows systems should be configured so that an update server in the organisation is used. In this manner, it is possible to realise the following practical update procedure:

• Administrators are informed of the availability of a new update.
• The update is downloaded and installed on test systems.
• After the updates have passed the tests successfully, the update is released for the internal update server.
• Windows computers download the released update from the internal update server and then install it.

Application software and tools

The update functions of the application software and tools often fail with normal user authorisations and display disruptive or confusing messages to the user. Such messages should be prevented by the administrator, for example by integrating the update packages into the software distribution systems or using Planned Tasks (Windows XP) or Task Scheduling (in Windows Vista and higher).

Informing the users

Many updates are followed by a reboot and several automatic system activities impairing the operating speed for some time. Following the reboot, messages or progress bars, which are confusing for some users, might be displayed. However, the successful completion of the processes may not be put at risk, for example by a reboot triggered manually. Therefore, users should be informed of possible impairments prior to major updates. In addition, feedback from the users should be collected randomly and included in the improvement of the update cycle.

Verification of the systems

The Windows logs and software logs should be monitored for previously unknown errors for several days following an upgrade or a major system change (e.g. the installation of a new Service Pack). On a random basis, several clients should also be checked as to whether

• all updates were installed successfully (Windows system log),
• application-specific authorisations and security settings are still correct (either manually or using security templates), particularly in the Windows folders, network and firewall and
• if applications, protective software and hardware function properly.

Review questions:

• Is the current patch status of every system compared regularly to the updates available from Microsoft?
• Do the administrators regularly inform themselves of weaknesses and available security updates?
• Is the strategy defined for updating Windows client systems?
• Does the defined update strategy for Windows client systems also take application-specific updates into account, for example from third party manufacturers?
• Is the trustworthiness of the update sources ensured for Windows client systems?
• Is it guaranteed that only tested and released updates are installed on Windows client systems?
• Is there a strategy for restoring the operability of the systems when problems or errors occur?