Patch Management User Guide for HP-UX 11.x Systems (762796-001, March 2014)

Advanced topic: scanning for security patches
You can use the SWA Tool to identify security patches for installation. This tool also identifies
patches that have associated warnings. For more information about SWA, see Chapter 9: “Using
HP-UX Software Assistant for patch management” (page 89).
Testing the patches to be installed
The single most important action that can ensure the success of a software patch is to first test the
changes in a nonproduction environment. Every environment is unique, and patch testing can
uncover potential problems unique to the environment in which the patches will be installed. If you
test thoroughly, you can reduce the chance of encountering problems with new patches.
The level of testing you perform depends in part on the patch management strategy you choose.
For example, because proactive patching involves installing patches before a problem occurs, it
allows more time than reactive patching to complete a sufficient level of patch testing.
HP subjects all General Release (GR) and Special Release (SR) patches to extensive
testing. See Chapter 4: “HP-UX patch overview” (page 18) for more information about GR and SR
patches. However, it is impossible to test all permutations of all patches on all hardware
configurations. Therefore, prior to deploying the patches on production systems, you should test
the set of patches you intend to install in a test environment that closely simulates the production
configuration. Even if you are deploying a standard HP-UX patch bundle, you should still perform
testing. Deploying any patch without first testing it in an environment increases a system's exposure
to risk.
The following is an outline of a basic patch test scenario:
1. The patches to be installed are identified and acquired.
2. The acquired patches are installed on a test system and tested to a standard that your
organization considers acceptable. Many organizations break this step into multiple levels of
testing to accomplish distinct goals. If testing results in unsatisfactory results, you must perform
an investigation to identify the root cause of the problem before proceeding.
3. The tested patches are installed on production systems.
The success of your testing approach relies heavily on how closely the configuration of the test
environment matches the configuration of the production systems on which the tested patches will
be installed. Within hardware limits, it is a best practice to duplicate the production environment
as closely as possible.
Ideally, you have a test system that is identical to the production system on which patches are to
be installed, and you have sufficient time available to test all patches prior to deploying them. This
situation allows you to perform very effective testing to verify that the patches to be installed will
not result in unexpected or undesirable system behavior.
Many customers have a two- or three-tiered approach to testing. Patches are initially installed on
a system that is often referred to as the development system. These types of systems are used for
local development. In a three-tiered system, after certain organization-specific rules have been met,
the patches are installed on another system that is often referred to as the test system. The patches
must then meet another set of organization-specific rules. For example, many customers require
that the patches be installed on the test system for some specified period of time with no problems.
The amount of time varies widely and can be as short as a week. However, for many customers,
one to three months is considered a reasonable time frame for testing. Once these rules have been
satisfied, the patches are installed on one or more production systems. Customers who initially
install the patches on only a subset of their production systems typically monitor these systems for
several weeks prior to installing the patches on the remaining production systems. For reactive
patching, the longer testing time frames are usually not reasonable and a stripped-down approach
to testing is usually required.
54 Patch management overview