Security patch testing and deployment phase

Testing the security patch

A security-related patch can affect many different parts of a system depending on the issue is it is supposed to fix and what is contained within the patch to do so. Therefore, testing must be included in the patching procedure and conducted for each patch planned for deployment. The goal of testing is to ensure that when a patch is deployed, the system's operations and applications are not impacted and business is not interrupted. To achieve this goal, the following minimum conditions must be met, and their success documented, before proceeding to the deployment phase:

• The testing environment simulates a majority of the targeted platforms
• The software delivery process succeeds on the targeted test platform
• The patch is installed on the target platform without significant issues
• Previously functioning operations on the target platform continue to operate after installation of the patch
• The patch is successfully removed in case of problems

If any of these conditions is not met, additional testing is performed prior to deploying the patch onto a vulnerable system. A few iterations may be required to ensure successful deployment and to reduce the risk of negatively impacting the affected system.

Deploying the security patch

Once the security patch successfully passes through the testing phase, you can begin the physical deployment process. Patches must be deployed in a manner that guarantees repeatability, consistency, status tracking and error logging. This is typically achieved with a patch management tool. There are myriad options available and organizations should use the tool that best fits their environment. Depending on how the roles and responsibilities of the patch management procedure are documented, the tool administrator, server administrator or desktop group can deploy a patch. These roles and responsibilities should be defined in advance within the patch management process itself.

Some organizations with limited test environments deploy patches onto a group of 'pilot' systems prior to rolling them out to the entire organization. If this method is used, the patch must be given enough time on the pilot systems to ensure no issues are identified. Once a pre-determined amount of time has passed and the deployment to the pilot systems is deemed successful, a full deployment to the remaining devices or nodes is scheduled.

The pilot method can be useful for affected servers as well. However, non-critical servers should be patched first and given the proper burn time. Again, once the pre-determined amount of time has passed, the patch can be installed on all the affected servers, including the highly critical ones.

When all the systems have been patched, the individual or group responsible for the tool reports the status of the deployment to their team.

Step by Step: Best practices for security patch management
  Introduction
  How to prepare for security patch testing
  Security patch testing and deployment phase
  Security patch validation and verification

ABOUT THE AUTHOR:

Felicia Nicastro, CISSP, CHSP, ISSMP is a Principal Consultant with International Network Services (INS), with over seven years in the information security field. Felicia's areas of expertise include security policies and procedures, security assessments and security architecture planning, design, implementation and operation. Felicia has also authored a book on patch management, titled Curing the Patch Management Headache, which was released in February 2005.