Patching Principle

Univ of Hawaii - ITS Technical Architecture - Principle   

Patching

Principles

• Patches for all ITS infrastructure components should be implemented in a timely manner.
• Emergency and critical patches should be addressed as soon as possible, and other patches should be addressed on a planned schedule (see Remediation Timeline table below).
• To mitigate risk of introducing unintended problems into our systems, ITS will implement patches in non-production environments first and then after a short test period will implement patches in production systems.
• To the greatest extent possible, ITS should establish a standard window for when it completes maintenance such as patching.  (Specifics of this will be addressed in another principle document.)

Background

• Software vendors and open source communities regularly publish patches for their software products.  Some patches are released on a regular schedule, and some are released on an ad hoc basis.
• Some patches are targeted to address security problems in the software.  Sometimes these are well documented, other times they are only vaguely documented.
• The longer a security patch is not implemented, the larger the exposure to UH of a security incident.
• Non-security patches usually are not as time sensitive, but occasionally are time sensitive when the patch addresses a problem we are seeing in production.
• Implementing security patches should decrease the chance of security incidents, but increases the risk of introducing problems into our systems (e.g. performance problems or outages).
• The exact frequency of security patches will need to vary by infrastructure component and vendor, but we should have a firm timeframe established for all patching.
• ITS’ Change Management process should be used for all patching.
  
  

Patch Implementation

Vulnerability Scale

     The timeliness of ITS’ application of patches will be dependent on the criticality of the vulnerabilities that are being addressed.

These terms refer to ITS’ internal ratings. Some vendors may use similar terms when they classify their vulnerabilities, but ITS’ assessment and the vendor’s may not always be the same. Generally, the vendor’s highest rating (no matter what it is called) will be mapped to “critical” and all other lower ratings will be categorized as “other.”

Assignment of Vulnerability Rating 

• Each technical team will be responsible for documenting its standard procedure for reviewing patches and assigning a vulnerability rating.  The procedure used should involve a cursory review of each patch, but generally trust the vendor’s criticality rating.
  
  
• Some vendors release patches without providing any insight into the level of vulnerabilities that are being addressed.  When it is impossible to assess the vulnerability level, ITS will assign a vulnerability level of “other.”
  
  
• The TI Security team should review and sign-off on the vulnerability rating procedure used by each technical team that adequately addresses risk for the University.
  
  
• If a technical team and the TI Security disagree on the appropriate procedure, they should escalate the issue to the TI Director or another appropriate Director

Mitigation

There are several techniques to mitigate a security vulnerability including: 1) installation of security Patch; 2) adjustment of a configuration setting; 3) removal of the vulnerable component; 4) Implementation of compensating control (e.g. workaround).

ITS will use the most appropriate technique on a case-by-case basis.  Eventually though, all security patches should be applied to any infrastructure operated by ITS.

Remediation Timeline

 ITS teams should use the following table to determine when patches should be applied.

Patches should be applied no later than the number of days listed in the above table.  If for some reason it is impossible for an ITS team to meet this timeline, then an ITS director should be notified via email as soon as possible.  In some situations, governance groups may choose to extend the time before a patch is applied. (See governance below for information concerning this process.)

ITS teams should establish a standard patching schedule for their systems that occurs at least quarterly (unless quarterly patches are not available).  Such a standard schedule will greatly simplify the logistics of applying non-critical patches.

¹ For “Critical” patches, there may be situations where patches are announced too late to make our standard maintenance windows.  In that case, these “other” patches may take up to 9 days to be installed.

² For “Other” patches, there may be situations where patches are announced too late to make our standard maintenance windows or the monthly patch schedule.  In that case, these “other” patches should be installed in the following monthly patches.

Governance

The application of patches can have significant impact on business operations.  Because of this, it is critical that patch decisions are made within the context of any existing governance or operating structures.

This will be ensured in several ways including:

1. In a timely manner, ITS staff will use existing change-management and governance structures to plan the deployment of any patches.
   
2. Business owners of UH systems (informed by any existing governance groups) will have the ability to influence risk decisions regarding the deployment of standard patches.  They may elect to recommend the delay of patch deployment in situations where they deem the deployment of the patch is more risky to the University than the other potential impacts.  Given that the CIO ultimately bears the risk, in such situations the CIO or CIO-designee must also be informed.
   
3. Decisions to delay patch deployment will be documented in the appropriate ITS change management system.

Change History (most recent at top)

• Approved by CIO, Aug 2018

• Updated by TI Directory, Jul 2018

• Approved by CIO, Feb 2018

• Updated May 2015

• Approved by ITS Directors, Feb 2015

• First drafted, Dec 2014