How to prepare for security patch testing

Organizations can ensure successful testing of a security patch by first taking the following steps:

1. 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?

2. 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.
Table 1: Rating Criteria of Patches

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

3. 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.

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

  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.

Rate this Tip To rate tips, you must be a member of SearchMidmarketSecurity.com. Register now to start rating these tips. Log in if you are already a member. Digg This!     StumbleUpon     Del.icio.us    RELATED CONTENT Configuration and patch management Take four steps toward Macbook security Hackers targeting unpatched Microsoft DirectShow flaw Adobe shifts to Microsoft patching process, incident response plan PCI DSS requirement: Building and maintaining a secure network How to fill patch management gaps using Microsoft MBSA Assess your security state in five steps Internet Explorer 8 includes a bevy of security features Adobe issues patch to block zero-day flaw Determine when to use a workaround rather than patch systems Auto shutoff switches save money, tighten security RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.