Establish a patch management policy

Patch management is an issue that will always plague your organisation's network. There will always be patches, updates, and security fixes to apply. Unfortunately, there will not always be unlimited time to evaluate and distribute fixes to close a security hole that attackers are currently exploiting.

Given the current state of security, patch management can easily become overwhelming. That's why it's a good idea to establish a patch management policy to define the necessary procedures and responsibilities.

Usually, I would discuss the components of a patch management policy and go over what such a policy needs to address, but this time I want to do something different. Rather than talking about which potential issues a policy should cover, let's look at a sample policy you can adapt to fit your organisation's needs.

Sample patch management policy

Here's a sample patch management policy for a company we'll call Example.com Networks. If you don't have such a policy in your organisation, you can use the following as a starting point.

Goal

It is the chief information officer's (CIO's) responsibility to provide a secure network environment for Example.com Networks' automated applications, staff, business partners, and contractors. As part of this goal, it is Example.com Networks' policy to ensure all computer devices (including servers, desktops, printers, etc.) connected to Example.com Networks' network have proper virus protection software, current virus definition libraries, and the most recent operating system and security patches installed.

NetOps Responsibility

The Network Operations (NetOps) division is responsible for the overall patch management implementation, operations, and procedures. While safeguarding the network is every user's job, NetOps is the division that ensures all known and reasonable defences are in place to reduce network vulnerabilities while keeping the network operating. This responsibility includes the tasks detailed below.

Monitoring

NetOps will monitor security mailing lists, review vendor notifications and Web sites, and research specific public Web sites for the release of new patches. Monitoring will include, but not be limited to, the following:

|> Scanning Example.com Networks' network to identify known vulnerabilities.
|> Identifying and communicating identified vulnerabilities and/or security breaches to Example.com Networks' chief information security officer (CISO) and CIO.
|> Monitoring CERT, notifications, and Web sites of all vendors that have hardware or software operating on Example.com Networks' network.

Review and evaluation

Once alerted to a new patch, NetOps will download and review the new patch within four hours of its release. NetOps will categorise the criticality of the patch according to the following:

|> Emergency -- an imminent threat to Example.com Networks' network
|> Critical -- targets a security vulnerability
|> Not Critical -- a standard patch release update
|> Not applicable to Example.com Networks' environment

Regardless of platform or criticality, all patch releases will follow a defined process for patch deployment that includes assessing the risk, testing, scheduling, installing, and verifying.

Risk assessment and testing

NetOps will assess the effect of a patch to the corporate infrastructure prior to its deployment. The department will also assess the affected patch for criticality relevant to each platform (e.g., servers, desktops, printers, etc.).

If NetOps categorises a patch as an Emergency, the department considers it an imminent threat to Example.com Networks' network. Therefore, Example.com Networks assumes greater risk by not implementing the patch than waiting to test it before implementing.

Patches deemed Critical or Not Critical will undergo testing for each affected platform before release for implementation. NetOps will expedite testing for critical patches. The department must complete validation against all images (e.g., Windows, UNIX, etc.) prior to implementation.

Notification and scheduling

NetOps' management must approve the schedule prior to implementation. Regardless of criticality, each patch release requires the creation and approval of a request for technical change (RTC) prior to releasing the patch. Example.com Networks' CISO will decide when notifying staff is necessary.

Implementation

NetOps will deploy Emergency patches within eight hours of availability. As Emergency patches pose an imminent threat to the network, the release may proceed testing. In all instances, the department will perform testing (either pre- or post-implementation) and document it for auditing and tracking purposes.

Here is a sample timeline for releasing critical patches:

Available              (A) = 0                     Monday
Submit for testing     < A+ 1 day                  Tuesday
Approved               < A + 3 days                Thursday
Release                < A + 5                     Saturday

NetOps will obtain authorisation for implementing Critical patches via an emergency RTC and Example.com Networks' approval. The department will implement Not Critical patches during regularly scheduled preventive maintenance. Each patch will have an approved RTC.

For new network devices, each platform will follow established hardening procedures to ensure the installation of the most recent patches.

Auditing, assessment, and verification

Following the release of all patches, NetOps staff will verify the successful installation of the patch and that there have been no adverse effects.

User responsibilities and practices

It is the responsibility of each user -- both individually and within the organisation -- to ensure prudent and responsible use of computing and network resources.

Final thoughts

While this policy is simple, it spells out the details -- specifically, who, why, when, and how -- that all policies should address. Once you have established your patch management policy in place, don't let it be just a piece of paper -- make sure the company follows it.