What is patching?

This topic introduces you to the concept of patch management in TrueSight Server Automation. It includes the following sections:

Introduction
Overview of patch management process
Offline mode or online mode?
What is patch metadata?
What is a patch catalog?
What is a Patching Job?
Standard patching and emergency patching
Where to go from here

Introduction

This topic and the corresponding walkthroughs are intended for system administrators who are responsible for patch management in their environment. Although the administrators are probably new to TrueSight Server Automation, they should have prior knowledge of server and infrastructure management.

Most security breaches are due to known and unpatched vulnerabilities. However, many companies view patching as an overhead activity. As a result, there is real pressure to manage patching as efficiently and effectively as possible.

With TrueSight Server Automation, the patch administrator analyzes individual servers to determine which patches must be acquired and installed to comply with organizational standards. TrueSight Server Automation automates the process of building and maintaining a patch repository, analyzing target servers, and, if necessary, packaging and deploying patches. At the end of the process, TrueSight Smart Reporting for Server Automation reports are available to show compliance.

Overview of patch management process

Patch management starts with the creation of a catalog of patch data.

After you create and update a patch catalog, you run a Patch Analysis Job to identify missing patches on your servers. The next step is a Patch Remediation Job, which creates software packages that contain the patch payloads, as well as a Deploy Job to carry those payloads to the servers that you want to remediate.

Basically, you need to perform the following tasks for patch management:

Create a patch catalog
Analyze the target to determine the patches that needs to be deployed
Deploy the required patches to targets requiring remediation. TrueSight Server Automation creates the necessary BLPackages and Deploy Jobs to remediate the targets.
Analyze the targets again to make sure each server is patched correctly

The process differs slightly depending on if you are following a standard patching process, or if you have to deploy an emergency patch. To learn a bit about the differences between the two, see Standard patching and emergency patching.

Tip

There is an excellent webinar available from BMC Communities, which offers an overview of the entire patch management process, along with some examples of advanced use cases. See the Best Practices Webinar - Patching with TrueSight Server Automation on BMC Communities.

Offline mode or online mode?

There are two patch management modes:

Online mode — Patches are downloaded directly from the appropriate product site. Online mode indicates the TrueSight Server Automation application server has direct internet access and downloads the patch metadata and payloads from the Shavlik networks (for Microsoft systems) or the OS vendor web sites.
Offline mode — Patches are pre-downloaded to a local repository and patches are applied from the repository. Offline mode is useful when, for whatever reason, the TrueSight Server Automation application server doesn't have internet access. Use Offline mode if you work in an air-gapped environment. In Offline mode, you use the BMC offline Patch Downloader utility to download metadata and payload information to a server with Internet access. After downloading, you can transfer the metadata and payload information (using removable storage) to the patch repository within the air-gapped environment.

The Patch Downloader utilities run scripts that use XML configuration files (samples are provided with the product) containing required information such as the repository location, as well as filters used during downloading from the vendor website.

What is patch metadata?

All patch vendors publish some kind of information that basically says that a given patch is needed based on operating system, application version, or existing patches.

We call this information the patching metadata, because it tells us information about the patch: specifically where the patch applies. In TrueSight Server Automation, this metadata is stored in the patch catalog.

What is a patch catalog?

A patch catalog provides a place to store metadata about patches. Patch catalogs store vendor patch metadata, and are the source of information used for analysis, downloading patch payloads, and deployment.

Patch catalogs can be designed for specific needs. For example, a patch catalog can used for a particular operating system, such as Microsoft Windows 2019. With well designed patch catalogs, it is easier to select the patches that should be used when evaluating the patch configuration of a particular server.

What is a Patching Job?

You run a Patching Job to identify missing patches on your servers. A Patching Job uses the information contained in the patch catalog to analyze one or more target servers for patch compliance.

There are three jobs that run within a Patching Job, each representing different parts of the overall patch process:

Analysis — The Patch Analysis Job analyzes the configuration of target servers and determines the required patches.
Remediation — The Patch Remediation Job downloads the payload from the vendor sites to the Patch Repository, packages the payload as a BLPackage, and creates a Deploy Job to apply the patches.
Deploy — The Deploy Job created during remediation is then run to deliver the required patches to targets requiring remediation.

You can choose to run only the analysis part of a Patching Job, and then run remediation later, or you can run remediation immediately after the analysis.

Standard patching and emergency patching

It is important to make the distinction between the standard patch management process and emergency patching.

Process	Description
Standard Patching	Standard patching refers to applying critical or important vendor patches. The standard patching process normally involves either reusable or purpose-built Patch Smart Groups. A typical patching process includes: Surveying large groups of servers, using a standard policy, for reporting and assessment purposes. This is done by setting up and executing a Patch Analysis Job. The results of the job should give you a good idea of the amount of work required to patch the environment (do many servers require more than 10-15 patches?), and the amount of time estimated. You don't typically generate the remediation packages with this job. Setting up smaller patching remediation jobs, usually aligned by specific criteria, such as maintenance window, business unit, change control/request or server owner groups, or some combination of those. These patching jobs will generate remediation packages, and those remediation jobs will need to execute all within a particular maintenance window, or when a particular change is approved to run, and so on, depending on the criteria. Once staged and executed, the patching job will usually be re-run, for one of the following reasons: Reporting purposes To either certify that the group of servers no longer need patches To do a second-pass deployment for any “still missing” patches or patches that did not deploy the first time. Some companies perform this cycle twice, with the third Patching Job performing the verification/reporting, as it is sometimes difficult to achieve 99% compliance with one remediation pass. A typical full patch management lifecycle is 15-30 days for the full production environment, with another 15 days up front for pre-production.
Emergency patching	Also known as zero day or critical patching, emergency patching refers to either one specific patch, or a list of similar patches. The process is actually a lot like standard patching, but the change controls tend to be broader, and more servers tend to get remediated within the same job (or by using fewer jobs than the standard patch process). Since this patch list is highly focused, testing overhead tends to be smaller, and the windows into which the patches are deployed tend to be much narrower. A typical window for emergency patching could be 10 days for the entire environment. Patch Compliance dashboards are critical for emergency patching, and since these usually still need to run in some kind of seven day maintenance windows, the capability to quickly understand deployment success rates and patch compliance across specific groups or populations is very important. Deployment success rates and patch compliance for emergency patching are mostly measured using job results, and also with trailing reports in TrueSight Smart Reporting for Server Automation.

Process

Description

Standard Patching

Standard patching refers to applying critical or important vendor patches. The standard patching process normally involves either reusable or purpose-built Patch Smart Groups. A typical patching process includes:

Surveying large groups of servers, using a standard policy, for reporting and assessment purposes. This is done by setting up and executing a Patch Analysis Job. The results of the job should give you a good idea of the amount of work required to patch the environment (do many servers require more than 10-15 patches?), and the amount of time estimated. You don't typically generate the remediation packages with this job.
Setting up smaller patching remediation jobs, usually aligned by specific criteria, such as maintenance window, business unit, change control/request or server owner groups, or some combination of those. These patching jobs will generate remediation packages, and those remediation jobs will need to execute all within a particular maintenance window, or when a particular change is approved to run, and so on, depending on the criteria.
Once staged and executed, the patching job will usually be re-run, for one of the following reasons:
- - Reporting purposes
  - To either certify that the group of servers no longer need patches
  - To do a second-pass deployment for any “still missing” patches or patches that did not deploy the first time.

Some companies perform this cycle twice, with the third Patching Job performing the verification/reporting, as it is sometimes difficult to achieve 99% compliance with one remediation pass. A typical full patch management lifecycle is 15-30 days for the full production environment, with another 15 days up front for pre-production.

Emergency patching

Also known as zero day or critical patching, emergency patching refers to either one specific patch, or a list of similar patches. The process is actually a lot like standard patching, but the change controls tend to be broader, and more servers tend to get remediated within the same job (or by using fewer jobs than the standard patch process).

Since this patch list is highly focused, testing overhead tends to be smaller, and the windows into which the patches are deployed tend to be much narrower. A typical window for emergency patching could be 10 days for the entire environment.

Patch Compliance dashboards are critical for emergency patching, and since these usually still need to run in some kind of seven day maintenance windows, the capability to quickly understand deployment success rates and patch compliance across specific groups or populations is very important.

Deployment success rates and patch compliance for emergency patching are mostly measured using job results, and also with trailing reports in TrueSight Smart Reporting for Server Automation.

Where to go from here

Now that you have a basic understanding of the process, it is time to build your patch catalog.

Walkthrough-Setting-up-and-managing-an-online-patch-catalog-for-Windows

Walkthrough-Setting-up-and-managing-an-online-patch-catalog-for-Linux