Tip

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?
These questions should be answered and documented along with the details of each patch planned for deployment. This will provide the organization with an audit trail of what patches where installed, when and why.

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

    Requires Free Membership to View

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

This was first published in February 2009

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

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.