Skip to main content
Version: 8.5.X

Patch Management

Know how Patch Management helps in deploying and managing the patches.

What is Patch Management?

A patch is a piece of software code applied after the software program is installed to rectify an issue within it. Generally, the software applications roll out several patches after their initial release and keep on releasing the versions to fix any vulnerabilities or bugs in an application. Patch management is the process of managing a network of computers by regularly distributing and applying the updates to software. These patches are often necessary to correct errors.

Benefits

For organizations owning multiple servers and computers, updating patches manually can be both time-consuming and challenging. It can also increase business risks if any critical vulnerability is left unforeseen. The following are the few reasons why Patch Management should be considered:

  1. Security: It fixes vulnerabilities on software and applications that are susceptible to cyber-attacks, helping the organization reduce its security risk.
  2. System Reliability: It ensures that software and applications are updated and run smoothly.
  3. Feature and Functional Improvements: It can go beyond application fixes by providing updates in its feature or functionality.
  4. Compliance: With the continuous rise in cyber-attacks, organizations require to maintain a certain level of compliance. Patch management is a necessary piece of adhering to compliance standards.

Patch Management Process Lifecycle

Patch Lifecycle

  • The patch information is collected from the application website and put into a Central Patch Repository (CPR). The network of the organization is then scanned to identify the computers that require these patches. For large geographically distributed networks Distribution/Relay Servers are configured.
  • These patches contain critical and security/non-security updates, service packs, rollups, feature packs, etc. These installed and missing patches are analyzed, downloaded, and asked for an approval before updating it on the system. Generally, patches are approved only if they do not cause any problems post deployment.
  • Policies can be created to enable multiple deployment and scheduling settings. Various Reports can also be generated after the successful deployment and the related information is sent to the server.

Working

The working of Patch Management depends on whether a patch is being applied to a stand-alone system or to a multiple computer network. While the system is in stand-alone mode, the OS and the applications, will periodically perform an automatic check to see if any patches are available. If found any, the patches will be downloaded and installed automatically.

In contrast to the above, in organizations with huge IT Infrastructure, checking for patches and deploying them on individual computer is a complicated and time-consuming process. In order to overcome this, the larger organizations undergo a centralized patch management rather than manually allowing each computer to download its own patches. Also, conducting centralized patching helps to conserve the Internet bandwidth. Instead of downloading individual patches across all the computers, the server can download, and distribute the patch to all the computers available on the network. This saves the bandwidth consumption.

For security purpose,

When patches (updates or fixes for software) are applied to Red Hat or CentOS systems, it's crucial to ensure the integrity and authenticity of these patches.

The process involves:

  1. Downloading the Patch: The system downloads the patch file from the official source (e.g., Red Hat repositories).

  2. Generating a Checksum: Once the patch file is downloaded on the motadata file server, the Motadata Serviceops application generates a checksum for the file using the SHA-256 algorithm.

    note

    SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function that takes an input (or 'message') and returns a fixed-size, 256-bit hash value. It is widely used to ensure data integrity because even a small change in the input will produce a drastically different hash.

  3. Checksum Comparison: Red Hat provides a checksum (hash value) for each patch file they release. This checksum is published alongside the patch file itself.

    The generated checksum of the downloaded patch file is compared with the checksum provided by Red Hat. If the checksums matches, it means the file is authentic and has not been tampered with or corrupted during the download process. If they do not match, it indicates a potential issue, such as corruption or tampering, and the patch should not be applied.

Motadata ServiceOps streamlines the process through a centralized patch management repository. This retrieves patches available through third-party application websites and distributes them to the computers on the organization's network.

Architecture

The ServiceOps Architecture includes below:

  1. Main Server hosted on Cloud and File Server on Premise
  2. Main Server and File Server hosted on Premise
  3. Main Server and File Server hosted on Cloud
  4. Remote Office

a. Main Server hosted on Cloud and File Server on Premise

The architecture mainly consists of the following components:

  1. Central Patch Repository
  2. ServiceOps Main Server (Cloud)
  3. File Server (On Premise)

Main Server on Cloud and File Server on Premise

As shown above, the Motadata Central Patch Repository checks the Internet repeatedly to draw latest patch information from the third-party application websites and stores it. The local patch database regularly updates itself by pulling the updated patch details from the central repository.

The ServiceOps Main server, located in the cloud, synchronizes with the central repository. It periodically downloads the updates and vulnerabilities available in the database.

The scan will automatically determine which updates are needed on each client system, taking into account the operating system, build version, application, and update dependencies. Resulting to this, the missing patch details along with the respective severity for individual computer will be identified and installed into the database.

The entire process of information gathering, patch analysis, and publishing the latest vulnerability database occurs periodically. The updated patches are available for access once the Central Patch Repository and the ServiceOps server both are synchronized. ServiceOps also supports manual sync for patch updates. Comprehensive views of Patch-wise Systems and System-wise patches with installation status can be viewed on the ServiceOps portal.

After the missing and installed patches are listed, an approval is needed for updating the missing patches into the system. Approved patches are then downloaded from the third-party website on File Server and stored. These patches are then pushed on to the targeted systems for installation as per the deployment policy. Installed patches and service packs are verified and deployed on the systems. These can effectively generate reports for the purpose of monitoring and security compliance.

b. Main Server and File Server hosted on Premise

The architecture mainly consists of the following components:

  1. Central Patch Repository
  2. ServiceOps Main Server (On Premise)
  3. File Server (On Premise)

Main Server and File Server on Premise

As shown above, the Motadata Central Patch Repository checks the Internet repeatedly to draw latest patch information from the third-party application websites and stores it. The local patch database regularly updates itself by pulling the updated patch details from the central repository.

The ServiceOps Main server synchronizes with the central repository. It periodically downloads the updates and vulnerabilities available in the database.

The scan will automatically determine which updates are needed on each client system, taking into account the operating system, build version, application, and update dependencies. Resulting to this, the missing patch details along with the respective severity for individual computer will be identified and installed into the database.

The entire process of information gathering, patch analysis, and publishing the latest vulnerability database occurs periodically. The updated patches are available for access once the Central Patch Repository and the ServiceOps server both are synchronized. ServiceOps also supports manual sync for patch updates. Comprehensive views of Patch-wise Systems and System-wise patches with installation status can be viewed on the ServiceOps portal.

After the missing and installed patches are listed, an approval is needed for updating the missing patches into the system. Approved patches are then downloaded from the third-party website on File Server and stored. These patches are then pushed on to the targeted systems for installation as per the deployment policy. Installed patches and service packs are verified and deployed on the systems. These can effectively generate reports for the purpose of monitoring and security compliance.

c. Main Server and File Server hosted on Cloud

The architecture mainly consists of the following components:

  1. Central Patch Repository
  2. ServiceOps Main Server (Cloud)
  3. File Server (Cloud)

Main Server and File Server hosted on Cloud

As shown above, the Motadata Central Patch Repository checks the Internet repeatedly to draw latest patch information from the third-party application websites and stores it. The local patch database regularly updates itself by pulling the updated patch information from the central repository.

The ServiceOps Main server, located in the cloud, synchronizes with the central repository. It periodically downloads the updates and vulnerabilities available in the database.

The scan will automatically determine which updates are needed on each client system, taking into account the operating system, build version, application, and update dependencies. Resulting to this, the missing patch details along with the respective severity for individual computer will be identified and installed into the database.

The entire process of information gathering, patch analysis, and publishing the latest vulnerability database occurs periodically. The updated patches are available for access once the Central Patch Repository and the ServiceOps Main server get synchronized. ServiceOps also supports manual sync for patch updates. Comprehensive views of Patch-wise Systems and System-wise patches with installation status can be viewed on the ServiceOps portal.

After the missing and installed patches are listed, an approval is needed for updating the missing patches into the system. Approved patches are then downloaded from the third-party website on the File Server and stored in the cloud. These patches are then pushed on to the targeted systems for installation as per the deployment policy. Installed patches and service packs are verified and deployed on the systems. These can effectively generate reports for the purpose of monitoring and security compliance.

d. Remote Office

Remote Office

In the Remote Office setup, the Distribution Server is installed as a component. It synchronizes the missing patch details from the ServiceOps server and downloads the missing patches. The downloaded patches are further distributed to the clients for patch deployment. On completion of the successful deployment, the status is updated to the server.

Prerequisites

  1. Internet Connectivity ServiceOps requires Internet connectivity for the following purposes:

    • For updating the Patch Vulnerability from Central Patch Repository.
    • For downloading patches from the third-party application website.

    Proxy settings will be needed to be configured for production patch management, as direct Internet connectivity will not be available.

  2. Storage As a part of Patch Management, the File Server needs to be installed. It is used for maintaining the downloaded patch and pushing them to the managed clients. As a part of maintenance, space availability check and old data clean up needs to be performed.

  3. For Windows patch management, the 'Windows Update' service should not be disabled.

  4. The ServiceOps patchcentral url "https://patchcatalog.motadataserviceops.com/" must be accessible.

  5. For Windows Patch Management, the following URLs must be accessible:

    • http://windowsupdate.microsoft.com
    • http://*.windowsupdate.microsoft.com
    • https://*.windowsupdate.microsoft.com
    • http://*.update.microsoft.com
    • https://*.update.microsoft.com
    • http://*.windowsupdate.com
  6. For Linux Patch Management, the following URLs must be accessible:

  1. For Mac Patch Management, the below URL must be accessible:

  2. For Third-Party Patch Applications, the below URL must be accessible:

Supported Devices

The * marked OS versions are not supported for patch management.

Windows Client OSWindows Server OSLinux Client OS
  • Windows 7*
  • Windows 8
  • Windows 10
  • Windows 11
  • Windows Server 2008*
  • Windows Server 2012
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022
  • Ubuntu
  • CentOS
  • RedHat
  • Mint
  • openSUSE
  • Debian
  • Oracle Linux
  • Rocky Linux
  • Almas Linux

Supported Linux OS Version List:

The * marked OS versions are not supported for patch management.

Linux OS Version
Ubuntu
  • v24.04 LTS
  • 23.04 (Lunar Lobster)
  • 22.10 ( Kinetic ) (For All Desktop and Server versions)
  • 22.04 ( Jammy ) (For All Desktop and Server versions)
  • 21.04 (For All Desktop and Server versions)
  • 20.04, 20.10 (For All Desktop and Server versions)
  • 18.04 (For All Desktop and Server versions)
  • 16.04 (For All Desktop and Server versions)
CentOS9, 7*
RedHat9, 8, 7
Mint20, 19, 18
openSUSE15.6, 15.5, 15.4*, 15.3*
SUSEEnterprise 15 and above
Debian12, 11, 10*, 9*, 8*
Oracle Linux9, 8, 7
Rocky Linux9.4
Almas Linux9.4
note

To sync the Ubuntu and Mint OS Patches with the Central Repository, kindly upgrade the server to the latest ServiceOps v8.5.0. Backward compatibility is not supported.

Supported Client macOS Upgrade Version List:

  • macOS ("10.15", "10.16", "12", "13", "14")

Supported Windows Third-Party Patch Applications:

  • Browser (Google Chrome, Mozilla Firefox, and Microsoft Edge)
  • Adobe Acrobat Reader

Not Supported Windows Patch Categories:

  • Drivers Patches
  • BIOS Patches

Supported Patch Categories:

ToolsFeature PacksService Packs
Update RollupsDefinition Updates (Antivirus Definition Updates)Critical Updates
UpdatesHotfixSecurity Updates

The steps required to be carried out in the ServiceOps portal for Windows and Linux Patch Management would be the same. The user just needs to change the OS specific field and related application as shown in the Automatic Patch Test and Automatic Patch Deployment.