Implementation process for patch management
This topic describes the workflows for installing and configuring all of the TrueSight Server Automation components for patch management, and the workflow for setting up and executing related patching jobs.
The sections below describe the tasks involved in each workflow, and provide references to further details in TrueSight Server Automation technical documentation.
Overview of patch management
Most security breaches are due to known and unpatched vulnerabilities. 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, BMC Decision Support for Server Automation or TrueSight Smart Reporting for Server Automation reports are available to show compliance.
The following table describes some key elements of the TrueSight Server Automation patch management solution.
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.
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 2008 or 2012. 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.
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:
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 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:
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.
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 BMC Decision Support for Server Automation or TrueSight Smart Reporting for Server Automation.
Patch management consists of the following tasks:
- Preparatory tasks
- Defining role-based permissions
- Configuring Global Configuration parameters
- (Offline mode only) Building an offline patch repository
- Downloading patch downloader utilities from BMC
- Preparing XML configuration files for downloading patch content
- Downloading patches to the offline patch repository
- Patching tasks
- Creating and updating a patch catalog
- Creating and running a Patching Job and a Remediation Job
These tasks are described in more detail in Checklist for setting up and enabling patch management.
BMC recommends that you set up a small test group of servers and run the patch process on the group. Then, expand the process to all servers in the organization.
What environments are supported?
Supported platforms for storing the patch repositories of patch catalogs
|Patch catalog||Supported platforms for storing patch repositories|
Windows or Unix
Any AIX server
Note: If you are downloading patches using the SUMA option, ensure that you have the SUMA utility installed on your repository server.
Red Hat Enterprise Linux (RHEL) using the CDN interface
Red Hat Enterprise Linux 6, 7, or 8
|SuSE Linux 12|
SuSE Linux with SMT installed.
Note:To patch SuSE 12 targets, ensure that the SuSE patch repository server is configured with the Subscription Management Tool (SMT).
The following table lists the versions that are installed with SMT out-of-the-box, as well as the versions on which SMT must be manually installed.
Warning: BMC strongly recommends using Zypper when creating a patching job for a patch catalog that was created using the Subscription Management Tool (SMT). For more information, see Zypper patching tool.
|SuSE Linux 11||SuSE Linux with createrepo and python-urlgrabber installed.|
|Oracle Enterprise Linux||Any supported RPM-based Linux with createrepo and python-urlgrabber installed|
Windows or Unix
Note: If you are using Solaris 11 patches, you can only use a Solaris 11 server for storing the patch repository.
|Debian||Windows or Unix|
|Cent OS||Any supported RPM-based Linux with createrepo and python-urlgrabber installed|
|Fujitsu Solaris||Windows or Linux|
An HP-UX patch repository must reside either directly on the HP-UX (SWA) Server or in a directory that the SWA Server considers to be a local share.
Note that if you are using an offline downloader, you can run the offline downloader on any Windows or Linux machine, but the HP-UX patch repository must still reside on the HP-UX (SWA) Server.
Checklist for setting up and enabling patch management
The following table provides a checklist for performing all of the tasks required to set up the provisioning system and provision servers. Each step in the table also includes a link to more information.
Set up roles and permissions
To create or update a catalog, you must be assigned a role that includes the necessary permissions. You can assign permissions to one role or divide them between several roles.
Although this process is not essential for patch management, BMC always recommends that you grant users the minimum set of permissions needed to perform actions. If you do not set up a patching administrator with a limited set of permissions, a superuser such as the BLAdmins role must perform patch management. Grant the minimum set of permissions to the patching administrator, as well as grant the minimum level of access to any servers where you will be setting up patching infrastructure.
|2||Configure global patch configuration parameter|
Global Configuration parameters provide basic information used during patch catalog creation and updating, as well as for Patch and Remediation Jobs. The following parameter groups are available:
Choose offline mode or online mode
There are two patch management modes:
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.
|5||Create a patch repository for offline mode|
In an offline environment, Internet access is not available to any of the servers in the environment. In this case, you work in Offline Mode using the Patch Downloader utility to download metadata and payload information to a server with Internet access. After downloading, you transfer metadata and payload information, using removable storage, to the patch repository within the air-gapped environment.
From the BMC EPD site, download the appropriate utilities for building your offline repository. The utilities are platform-specific. You must know which platform you plan to use to download your patches.
Use the utilities that you downloaded from the BMC EPD site to prepare the XML configuration files for downloading the patch content. To download the patch content, use the utilities and the XML configuration files that you prepared.
Create a patch catalog in online mode
|For both types of repositories, online and offline, you create a patch catalog using the TrueSight Server Automation Console. Patches are added to the catalog as depot objects according to filters that you define for the catalog.|
|7||Stock the catalog||To ensure that you are working with valid patch content, you must run a Catalog Update Job before you run a Patch Job.||Updating an existing catalog|
|8||Creating and running a Patching and Remediation Job|
A Patching Job has two parts:
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.
Patch management authorization requirements
To perform patch analysis and remediation tasks, you must have the appropriate authorizations assigned to your user role and to the relevant system objects and resources. The following tables list the minimum authorizations required, for both roles and objects. For a list of permissions required for a specific role, such as patch catalog manager, see Minimum permissions for patching.
Minimum permissions for patching
|ACLPolicy.*||Create ACL policies to grant permissions to other roles that download patch objects.|
|ACLTemplate.*||Create ACL templates to grant permissions to other roles that download patch objects.|
|AIXPatchSoftware.*||AIX only: Create and read patch software.|
AIX only: Create and read software.
|BatchJob.*||Create and execute Batch Jobs that run concatenated Deploy Jobs|
|BLPackage.*||Create remediation packages and read their contents.|
|CustomSoftware.*||Linux and Windows only: Create Linux remediation jobs and read their contents.|
|DeployJob.*||Read and execute jobs that deploy patch packages.|
|DepotFile.*||Optional: Manage offline patch catalog metadata content.|
|Create the patch catalog in a depot folder or create remediation objects in a depot folder.|
Navigate to the patch catalog or remediation objects in a depot group.
|Create Patch Analysis jobs and remediation jobs in a folder or navigate to them in a group.|
|Create Patch Analysis jobs and remediation jobs in a folder or navigate to them in a group.|
|LinuxSoftware.*||Linux only: Create and read software.|
|PatchCatalog.*||Create and manage a patch catalog|
|PatchDownloadJob.*||Manage patch downloads.|
|PatchGlobalConfig.Modify||Optional: Manage global patch settings.|
|PatchingJob.Read||Read the jobs used as the basis of remediation.|
|PatchRemedationJob.*||Manage patch remediation jobs.|
|PatchSmartGroup.*||Create smart groups in the patch catalog.|
|Create a patch repository on a helper server, read the contents of the repository, read contents of target servers, deploy patches to target servers.|
|ServerGroup.Read||Allow user to browse to the helper server when selecting it and to browse to target servers.|
|SolarisSoftware.*||Solaris only: Create and read software.|
|WindowsSoftware.*||Windows only: Create and read software.|
|PatchSmartGroup.Read||Allow user to open patch smart groups|
|PatchSmartGroup.Write||Allow user to add new objects into patch smart groups|
Object level permissions for patching
Grant these permissions on the depot folder where you create a patch catalog and to all depot folders that are parents of the patch catalog folder.
Also grant these permissions on the depot folder where you create any remediation packages and to all parent job folders or groups.
|Server functioning as a patch repository|
|Grant these permissions to the server used as a patch repository.|
|Grant these permissions on target servers.|
|Target server groups||ServerGroup.Read||Grant these permissions on any target server groups that hold the target server.|
|Job folder containing Patching and remediation jobs||JobGroup.Read|
Grant these permissions on the job folder where you create a Patching Job and to all parent job folders or groups.
Also grant these permissions on the job folder where you create any remediation jobs and to all parent job folders or groups.
|Grant this permission on any Patching Jobs.|
Sizing the patch repositories
See the section about Patch Repository Sizing in the TrueSight Server Automation Sizing Guide available from the BMC Communities for the latest sizing and scalability recommendations.