---

PATCH MANAGEMENT GUIDELINES

This document describes internal procedures with regards to the notification, testing, and installation of security-related patches for both software products and operating systems. While non-security-related patches are important, their installation and testing is very system and application dependant, and is not covered by this general guideline relating specifically to security related patches. System and application administrators are responsible for maintenance and assessment of security patches which impact systems under their management and supervision.

NOTIFICATION OF SECURITY PATCHES

OIT system and application administrators subscribe to various email lists (such as advisory mailing lists of CERT and BugTraq), and regularly visit web sites relating to systems and software that run on the various servers they are responsible for. If a security vulnerability, or patch availability is determined to be of interest to other OIT system administrators and technical staff, the availability of the patch is disseminated through internal channels. This information is typically communicated via an internal mailing list or at a weekly meeting that the various technical coordinators attend.

DETERMINATION OF APPLICABILITY

Just as with any software installation or configuration change, security patches should not be applied in a blanket fashion. Changes in software functionality introduced by patches that also fix a security issue may also impact the correct functionality of other dependant applications in the complex software and hardware systems that are commonplace. The applicability of a security patch will be determined after the consideration of various factors, such as (but not limited to) the patch?s compatibility with vendor applications, the severity of the security issue, and the compatibility of the patch?s functionality changes with the installed environment. Additionally, the particular configuration of a system or service may, by design, make it immune to the addressed security vulnerability, and in the interests of system stability, the patch may not be applicable.

In the case where a security patch is found not to be compatible with an application or the environment, appropriate measures will be taken to mitigate the risk of continuing to run a vulnerable service, such as network filtering or other restrictions on access to the affected application or system.

TESTING OF PATCHES

Good system engineering practice dictates that security patches, just like any other system update or modification, should be tested in a non-production environment or, on a system where the impact to user and application functionality would be minimal if the patch were to adversely impact system functionality. System administrators should install patches on a non-production system, if available, to verify to the best of their ability that the security patch will not adversely impact the users and software which may interact with it. In the case that a non-production system is not available, appropriate measures shall be taken to verify the patch's correct functionality when placed into production, and, if necessary, backed out if appropriate.

AUTOMATED PATCH INSTALLATION

In situations where it is available, system administrators will use tools such as Windows Update, SUS, HFNetCheck, and cfengine to automate the installation on clusters of systems. Usage of these tools assists in the uniform application of configurations, policies, and patches at an enterprise-wide level.