Patch management is an issue that will always plague your organization'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 organization's needs.
Sample patch management policy
Here's a sample patch management policy for a company we'll call XYZ Networks. If you don't have such a policy in your organization, 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 XYZ Networks' automated applications, staff, business partners, and contractors. As part of this goal, it is XYZ Networks' policy to ensure all computer devices (including servers, desktops, printers, etc.) connected to XYZ 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 defenses are in place to reduce network vulnerabilities while keeping the network operating. This responsibility includes the tasks detailed below.
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 XYZ Networks' network to identify known vulnerabilities.
- Identifying and communicating identified vulnerabilities and/or security breaches to XYZ Networks' chief information security officer (CISO) and CIO.
- Monitoring CERT, notifications, and Web sites of all vendors that have hardware or software operating on XYZ Networks' network.
Once alerted to a new patch, NetOps will download and review the new patch within four hours of its release. NetOps will categorize the criticality of the patch according to the following:
- Emergency — an imminent threat to XYZ Networks' network
- Critical — targets a security vulnerability
- Not Critical — a standard patch release update
- Not applicable to XYZ 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 categorizes a patch as an Emergency, the department considers it an imminent threat to XYZ Networks' network. Therefore, XYZ 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. XYZ 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
NetOps will obtain authorization for implementing Critical patches via an emergency RTC and XYZ 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 organization — to ensure prudent and responsible use of computing and network resources.
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.
Mike Mullins has served as an assistant network administrator and a network security administrator for the U.S. Secret Service and the Defense Information Systems Agency. He is currently the director of operations for the Southern Theater Network Operations and Security Center.Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.