ARCHIVE - Patch Management Policy

Unable to render {include} The included page could not be found.

This is a draft page.

Contents

Overview

A process should be established for the deployment of system and software patches which includes:

Creation of an asset inventory
Defining roles and responsibility
Determining importance of systems and patch rankings
A documented patch management process

Asset Inventory

Comprehensive inventory of all system components, including:

Network devices and all supporting hardware and protocols
Operating systems within the development and production environments
Applications within the development and production environments
Any other mission-critical resources within the system environment that require patches and security updates for daily operations

The inventory should include supported versions of software, hardware, and third-party applications. Applications installed for an individual person or project should be included in the inventory.

Roles and responsibility

An individual should be identified to develop and oversee the patch and vulnerability management program in a department or unit.

This individual will be responsible for coordinating, facilitating and undertaking all necessary activities regarding security patch management policies and procedures. Additionally, this individual will have the necessary information technology and security expertise to successfully execute all steps as required, including:

Being aware of all known threats or vulnerabilities that could significantly impact system components within the system environment and any other IT resources.
Having a strong technical and business understanding of all critical systems within the unit’s IT infrastructure, as well as knowing which systems are essential for day-to-day operations

Systems and Patch Rankings

Patch Risk Analysis

Patching definition	High	Medium	Low
Vendor Patches and security updates defined as "high,” "critical" or "urgent" for all system components and other IT resources affected by threat	X
Vendor Patches and security updates with remote exploits actively spreading in the wild	X
Vendor Patches and security updates defined as "medium,” "moderate" or "important" for all system components and other IT resources affected by threat		X
Vendor Patches and security updates with remote exploits possible, but not actively in the wild		X
Vendor Patches and security updates defined as "low," "non-essential" or "non-urgent" for all system components and other IT resources affected by threat			X

Patch Risk Definitions

Ranking	Definition	Time To Patch requirement	Unscheduled Downtime Allowed
High	The threat source is highly motivated and sufficiently capable; controls to prevent the vulnerability from being exercised are ineffective.	Patches must be tested and applied as soon as possible	Yes, if necessary create emergency patch windows and may impact SLA. With approval, may be implemented with limited notification.
Medium	The threat source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability.	Patches must be tested and applied as soon as reasonable	Yes, but only if regular maintenance windows do not occur within a reasonable time frame. Must be sufficiently communicated first.
Low	The threat source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised.	Patches may be deferred	No, apply during regular maintenance windows.

Patch Management Process

The patch management process should:
a) determine methods of obtaining patches
b) specify methods of validating patches (e.g., ensuring that the patch is from an authorized source)
c) identify vulnerabilities that are applicable to the installation
d) assess the business impact of implementing patches (or not implementing a particular patch)
e) ensure patches are tested against known criteria
f) describe methods of deploying patches (e.g., using software distribution tools)
g) report on the status of patch deployment within the installation
h) include methods of dealing with the failed deployment of a patch (e.g., redeployment of the patch).