What is patching?
This topic introduces you to the concept of patch management in BMC BladeLogic Server Automation (BSA). It includes the following sections:
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 BSA, 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 BSA, the patch administrator analyzes individual servers to determine which patches must be acquired and installed to comply with organizational standards. BSA 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 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 Deploy Jobs 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. BSA 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.
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 BSA 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 BSA 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 BSA, 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 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.
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 Jobs created during remediation are 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.
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.
Where to go from here
Now that you have a basic understanding of the process, it is time to build your patch catalog.