S 4.324 Configuration of auto-update mechanisms in patch and change management
Initiation responsibility: Change Manager
Implementation responsibility: Administrator
Many products are equipped with automatic update mechanisms (auto-update) that notify users of available patches and updates. They also often provide an option to download the updates from the Internet and install them immediately. All operating systems and available standard software packages are usually now equipped with such mechanisms. The modes of operation of the update mechanisms vary depending on the version, installation mode and manufacturer.
In general, IT products with auto-update look for new versions or software packages on a public update server every time the system starts or connects to the Internet. The products offer several ways of configuring the auto-update mechanism. When new IT components are put into operation, it should always be checked if they are equipped with update mechanisms, what these are and how they can be configured. In this process, it should also be checked what data the auto-update mechanism transmits to the manufacturer. The general handling of these mechanisms has to be defined first. Then, the specific configuration of the update functions in the individual products has to be determined. The following provides an overview of various versions of these mechanisms.
Not all software products provide for complete deactivation. If the organisation wishes to prevent uncontrolled communication of IT components with the outside world, packet filters have to be used.
If querying a public update server is not desired, many software products can be re-routed to other internet addresses than the manufacturer's address, such as internal addresses.
Some manufacturers provide software for the independent operation of update servers or update mirror servers. In this case, the update server is locally installed in the organisation (e.g. Windows Server Update Services WSUS). The update server communicates directly with the manufacturer and downloads the desired updates directly from the manufacturer. The advantage of this solution is that the IT systems of the organisation to be updated do not have to communicate with the update server of the manufacturer but only with the local update server. This reduces the external data traffic to a minimum. Many products for update servers provide a graphical user interface (GUI) for setting the desired parameters conveniently. However, there are also products where the parameters needed to use local update servers are hidden or that require a packet filter and/or firewall to prevent queries to a public update server.
If public update servers are to be used, the authenticity of the update server has to be checked first, see S 4.177 Assuring the integrity and authenticity of software packages. Furthermore, it should be investigated whether time intervals or events can be used to control the update queries. The settings must then be specified according to the change strategy defined.
It has to be checked how communication with update servers can be reduced to a minimum. Furthermore, a decision must be made as to whether direct communication with the manufacturer is to be the only alternative or is to be used in addition to internal communication (parallel configuration).
Parallel configuration if often appropriate for mobile users who do not always communicate within the authority or company network. With mobile IT systems, it may be more important to install a current patch that closes a dangerous security gap straight away than to wait for its release by change management. However, it may also be desirable for all software changes to be exclusively carried out by internally released software distribution.
With auto-update mechanisms it also has to be considered whether the manufacturer only loads the changes to an internal IT system and then leaves the installation of the changes to the user, or whether the changes are automatically installed immediately after the download.
It also must be decided whether the IT systems reboot directly after the installation of changes, if required, or only when the system is shut down, for example.
Review questions:
- Were requirements for auto-update mechanisms specified when the patch and change management strategy of the organisation was defined?
- Are new components checked to see if they have any auto-update mechanisms and which type they have?
- Was the type of protection of auto-update mechanisms defined?