...
- 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 scheduleschedule (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.)
...
Grouping | Description |
Emergency | A very rare high profile security exposure that is specially designated by the CITSO (e.g. Heartbleed). |
Critical | A vendor (or patch provider) has denoted its highest rating for the patch. Generally this means that vulnerability that could be exploited by a remote unauthenticated attacker and could lead to system compromise without requiring user interaction. |
| Monthly | Operating System patches, such as RHEL and Windows. |
Other | All other patches. |
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.”
...
- 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 . The desire is to have a process that adequately addresses risk for the University, but is efficient with regards to staff resources. We expect these procedures to evolve over time as gaps or issues are identified.
- 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
...
Grouping | Time |
Emergency | ASAP (ideally within 24-48 hours) |
Critical | 7 days1 |
| Monthly | 30 days |
Other | 90 days2 |
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.
1 For “Critical Priority 1” “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.
2 For “Other” patches, there may be situations where patches are announced too late to make our standard maintenance windows or quarterly the monthly patch schedule. In that case, these “other” patches may take between 90 and 180 days to 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.
...
- In a timely manner, ITS staff will use existing change-management and governance structures to plan the deployment of any patches.
- 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.
- 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
...