Univ of Hawaii - ITS Technical Architecture - Principle
Patching
PrinciplePrinciples
- 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.
- 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
...
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. 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
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 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” 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.
...
This will be ensured in several ways including:
...
- 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 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)
...