Since it is very difficult to establish a security patch testing environment that is an exact replica of a production environment, the testing phase is typically the most problematic. This can be due to costs, and the presence of various operating systems and applications within the environment.
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...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
. 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.
ABOUT THE AUTHOR:
[IMAGE]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.
