Patch Management
Swisscom carries out automatic patching of the operating system according to the Customer-defined patching windows.
New minor releases and security fixes are automatically installed on the systems during patching. No applications, features, or add-ons are installed on Windows systems.
On Managed RHEL VMs, all packages from the official Red Hat and Swisscom repositories will be updated to the latest available version.
Automated installation of regular hotfixes is carried out after the patches have been assessed internally by Swisscom. Swisscom restarts the systems following installation.
Since there are significant patching-related differences between Windows and Linux, these are explained separately below. With the day-2 action "Update Patching Suspension" one can suspend the automated patching for up to 60 days (Windows) or 120 days (RHEL), measured from the last time the system was patched. If the last patch installation was longer than 60/120 days ago, it is not possible to suspend the automated patching process without patching the system first. One can use the day-2 action "Run On Demand Patching" to immediately patch a system. This action can be executed in all states of the machine. Please note that to prevent accidental patching, it is not allowed to run on-demand patching while the machine's automated patching is suspended. One needs to disable the patching suspension (using the "Update Patching Suspension" action) first.
Release Process
| Week | Action |
|---|---|
| Week 0 | Week 0 means the last week of the current patching month/patch cycle. In this week Swisscom evaluates the latest patches and release them. These patches are installed on a few dedicated test systems to perform functional tests of the patch installation of these patches |
| Week 1 | This is the first patching window the user can select on his VM. Typically, development and test systems are patched in this first window |
| Week 2 | This is the second patching window the user can select on his VM. It is up to the user which systems shall be patched within this window |
| Week 3 | This is the third patching window the user can select on his VM. It is up to the user which systems shall be patched within this window |
| Week 4 | This is the fourth patching window the user can select on his VM. It is up to the user which systems shall be patched within this window |
With this mechanism, the user is free to choose which systems should be patched in which week.
Actions
| Action | Description |
|---|---|
| Update Patching Window | The desired patching window can be changed with this action. |
| On demand patching | Can be used to patch a machine immediately. Not possible if the machine has a patching suspension set. |
| Suspension | Can be used to suspend the automated patching process for up to 60 days (measured from the last time the system was patched). If a system is currently in patching suspension, the action can be used to disable the suspension |
Functions/Configuration options
| Properties | Description |
|---|---|
| Patching Window | The customer defines a time window during which the system shall be updated, e.g "2nd Week Wednesday 02:00 - 04:00": The system will be patched every month on the second Wednesday of the month between 02:00 - 04:00 (UTC). This maintenance window will be kept as short as possible. |
| Emergency Patches | The process for importing emergency patches is performed manually. Emergency patches are installed on the systems outside the maintenance window. The customer is notified of this and a patching date is proposed. The customer can reject this date and make a new proposal. Patching must be done within 10 days, however. Otherwise, the SLAs will be suspended. If the next maintenance window falls within this timeframe, the emergency patch can also be installed during the maintenance window. |
| Server state during patching | During the patching window system restarts will be performed if necessary. If multiple systems have the same patching window configured, no guarantee can be given at present as to the sequence in which they will be restarted. |
| Restrictions | Hotfixes may not be installed manually via Internet. The removal of already installed hotfixes is not automated. |
Additional information for Managed Windows
Only OS patches are installed during patching for Windows. New OS features are not automatically installed. As for OS patches, a distinction is made between functional patches and security patches. Security patches are installed monthly according to the chosen patching window, functional patches on demand. A Swisscom provided System Center Windows Update Service is used for Windows OS patching. The system to be patched automatically downloads the patches during the patching run, installs them and restarts the server if necessary.
Additional information for Managed RHEL
Swisscom utilizes the Red Hat system management tool Red Hat Satellite to manage patching of Managed RHEL VMs.
The errata from the vendor Red Hat will be synchronized by Swisscom on a weekly basis. Also, the relevant child channels are synchronized (however, updates only concern child channels to a very limited degree).
On the first day of the month, a monthly "snapshot" of all channels is made, including the child channels. After the internal testing, the snapshot is available for the VMs on the 28th of the month.
At the defined patching window, the automation will then install the available updates.
The automation will install updates from preconfigured official Red Hat and Swisscom repositories, to patch the Managed RHEL VMs.
These repositories are:
RHEL 7
| Repo Name | Repo ID | Type |
|---|---|---|
Red Hat Enterprise Linux 7 Server (RPMs) | rhel-7-server-rpms | Official Red Hat repository |
Red Hat Enterprise Linux 7 Server - Optional (RPMs) | rhel-7-server-optional-rpms | Official Red Hat repository |
Red Hat Enterprise Linux 7 Server - Extras (RPMs) | rhel-7-server-extras-rpms | Official Red Hat repository |
Red Hat Enterprise Linux 7 Server - Supplementary (RPMs) | rhel-7-server-supplementary-rpms | Official Red Hat repository |
Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server | rhel-server-rhscl-7-rpms | Official Red Hat repository |
Managed OS Agents RHEL 7 | sc-managed-os_esc_managed_os_tools_rhel7 | Swisscom repository |
RHEL 8
| Repo Name | Repo ID | Type |
|---|---|---|
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) | rhel-8-for-x86_64-baseos-rpms | Official Red Hat repository |
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) | rhel-8-for-x86_64-appstream-rpms | Official Red Hat repository |
Red Hat CodeReady Linux Builder for RHEL 8 x86_64 (RPMs) | codeready-builder-for-rhel-8-x86_64-rpms | Official Red Hat repository |
Managed OS Agents RHEL 8 | sc-managed-os_esc_managed_os_tools_rhel8 | Swisscom repository |
Remark: Any packages from other repositories than the one listed above are not automatically patched and must be updated by the customer (e.g., sc-managed-os_epel_rhel8)
Swisscom recommends that services or applications run by the customer, are automatically started after a reboot. This can be achieved by using systemd, which is a system and service manager for Linux operating systems.
Emergency Patching
The following section describes the handling of so-called "Emergency Patches" in the context of automatic patching of Managed OS service. The process for emergency patching is semi-automated in consultation with the customer.
Definition of emergency patches
The software vendor defines a severity level for each patch. Emergency patches are those which are judged by the manufacturer to have the highest severity level.
Managed Windows
(https://technet.microsoft.com/en-us/security/gg309177.aspx) Swisscom assesses the patches provided by the manufacturer on a monthly basis and releases them. These patches are then automatically installed within the HPMW. If it is necessary to install a patch immediately due to the current situation, this is implemented as promptly as possible in consultation with the customer via the proper change management.
Managed RHEL
(https://access.redhat.com/security/updates/classification)
| Severity classification | Description |
|---|---|
| Critical impact | This assessment is for errors that can easily be exploited by a remote, non-authenticated attacker and can affect the system (arbitrary code execution) without requiring interaction with the user. These types of vulnerabilities can be exploited by a worm. Errors that require an authenticated user, a local user, or unlikely configuration are not considered critical. |
Service Management Process
As soon as the manufacturer (Microsoft, Red Hat) publishes an emergency patch, Swisscom will be informed on the corresponding channels. Swisscom in return informs the customer (about the existing service management processes) that an emergency patch is available and must be installed. The decision when to install an emergency patch is also made via the SM process in consultation with the customer. The period of time that the customer can delay for the installation of an emergency patch is contractually regulated.
This service management process is identical for Windows and Linux. The installation of the emergency patches depends on the respective operating system and is done via WSUS or Red Hat Satellite.