Organizations can ensure successful testing of a security patch by first taking the following steps:
- Understand the files, functions and operations of the security patch. To ensure that all groups (e.g., server, application or desktop groups) comprehend the full impact of its installation, the following questions should be answered by the individuals (e.g., security team members or tool administrators) responsible for patch management:
- What problem does this patch solve?
- What systems are affected?
- What files are affected?
- Does the target system require a reboot?
- Does the target software process require a restart?
- Does the patch have an uninstall feature?
- If the patch or uninstall fails, how can the system be recovered?
- Prioritize and rate the severity of each security patch. The following table shows an example of how to prioritize patches based on criteria, along with the recommended and maximum timeframes associated with each. Some organizations prefer to use a color coding system versus a numbering scheme. The colors associated with each priority are also provided below to show how each line up. This table helps set the priority of a patch when it is released. However, if an organization already has compromised systems within their environment, this table does not apply.
- Initiate the change control procedure within the organization. The change control procedure or process is a set of documented steps that all changes must go through prior to installation on any systems or devices. Every organization should have a documented change control procedure in place that all groups within the organization must follow. Change management ensures that modifications to systems occur in a controlled environment. While initiating change control is possible after releasing a patch, it's important to complete change control prior to testing the patch and preparing it for deployment. Change control is executed according to the priority level of the patch. For example, if a patch is categorized as "Emergency" or "Red," an expedited version of the change control procedure is implemented to ensure the patch is installed within the required timeframe.
|Priority||Priority Color||Criteria||Recommended Timeframe||Maximum Recommended Timeframe|
|1 -- Emergency||Red||Organization is vulnerable, an exploit has been published and other organizations are being affected by the exploit||Within 6-12 hours||Within 12-18 hours|
|2 -- Critical||Orange||The organization is vulnerable, but no known exploitation of the vulnerability||Within 48 Hours||Within 2 weeks|
|3 -- Urgent||Yellow||The vulnerable technology exists in the environment, but the vulnerability is difficult to exploit||Within 1 week||Within 2 weeks|
|4 -- Important||Green||The vulnerable technology exists in the environment, but it is difficult to exploit, and the risk to the organizations systems is limited or low||Depending on availability, deploy a new service pack or update rollup that includes a fix for this vulnerability within 1 month||Deploy the software update within 2 months|
|5 -- Informational||Blue||The vulnerable technology does not exist in the environment||Depending on availability, deploy a new service pack or update rollup that includes a fix for this vulnerability within 3 months||Deploy the software update within 5 months or may choose not to deploy at all|
Maintaining the patch information within a change control system provides the required audit trail. It also provides a way to report on the status of each patch as it goes through the procedure. Once you have completed these steps you can proceed to the testing phase.
Step by Step: Best practices for security patch management
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.|