Procedure: Patch management
- This procedure applies to all University owned, leased or ICT managed services.
- All services are subject to a patch management plan to maintain the reliability and security of ANU resources.
- All patch management plans adhere to the requirements laid out in this procedure.
- All patch management plans are approved by the Director, ITS or nominated delegate and integrate into the enterprise’s ICT function. In the case of externally hosted services, patch management is incorporated into contracts with the relevant external party.
- Repeated non-compliance with the approved patch management plan is escalated.
- The Chief Information Security Officer or Director, ITS may, at their discretion, require any or all system owners to patch the services under their control within a defined timeframe, in response to an imminent threat which indicates this response.
- For each service or class of services, the patch management plan contains, or links to:
- An accurate inventory of every ICT asset and configuration item in the service and identification of which security patches need to be applied whenever suppliers issue them. This includes operating systems, applications, drivers and firmware.
- Clearly established methods for identifying new patches as they are released by suppliers or internal developers and timetabling their application.
- Methods for downloading patches from the supplier’s primary download source location and verifying the integrity and authenticity of patches.
- A periodic schedule for patches to be assessed, tested and deployed to the service.
- A rollback plan, or applicable rollback methods.
- A deployment plan consistent with the University’s change management processes and procedures.
- Deployment tools which enable the centralised and managed distribution and installation of patches.
- Options for risk mitigation to be applied to services in an emergency situation where a patch is not available or cannot be applied.
- Identified alternative mitigation strategies that are implemented as part of the vulnerability management processes. These strategies are subject to a full risk and mitigation planning assessment if required.
- Additional triggers, periodic reviews, and criteria for initiating major upgrades or product replacement in accordance with the security posture assessment and end of life determination.
- The timeliness of patching reflects the risk and operational requirements of the service. Updates for business critical and internet facing services are considered critical. The timing of all other patches are to consider:
- operational impact of the service if unavailable;
- threat risk rating of the service; and
- the sensitivity of the information stored in the service.
- Patches are deployed on a schedule that minimises the impact on the function of the service. For example, the following weekly maintenance windows are applied for ITS managed services:
6am – 8am
Updates resulting in potential network disruption.
2pm – 5pm
For services that are patched during business hours without risk of significant outages.
6pm – 3am
Service maintenance for systems and devices.
2pm – 5pm
For services that are patched during business hours without risk of outages.
- Critical security patches that are urgent and do not fit into established release cycles are applied within 48 hours of a patch release or some alternative mitigation is applied. These changes are considered Emergency Changes by the Change Advisory Board (CAB) and require approval by the Director, ITS. For critical patches on complex services, the patch process commences within 48 hours and takes no longer than two weeks to complete.
- For the deployment of non-critical patches across large groups of services, or for complex services with multiple environments (such as test, development and production), the patch management plan spreads the patching across available maintenance windows to ensure all levels are updated on a monthly basis. For example:
Patching across a sample of low risk services
Patching of a larger sample of services once issues are identified and resolved from the previous week
The bulk of patching will occur
Final round of monthly patching and clean-up from previous groups
- Following each patch window, successes and failures are assessed with root cause analysis completed for failures when required. In the case of failures, assessment is made to determine whether the patch is applied in the next cycle.
System owner responsibilities
- System owners:
- comply with this procedure;
- are responsible for the establishment and operation of a patch management plan; and
- are accountable for patching their services.
- This procedure triggers a requirement for patching, but the decision of whether to patch remains with the system owner except where item 6 of this procedure is applied.
- Should the system owner choose not to patch, then this decision is made immediately visible to the Director, ITS and Chief Information Security Officer.
Change Advisory Board
- Prior to implementation, all patch management plans are approved as standard changes by CAB.
- Deviations from the patch management plan are approved in advance by CAB as a non-standard change. Deviations are considered on a case-by-case basis.
- Other common administrative tasks related to patch management that require restarts are added as a standard change through CAB and in accordance with the patch management plan.
- Patching is reported to CAB including progress, successes and failures in accordance with the patch management plan. Automated tools are used where practical, to assist with this reporting. Monthly patching reports are provided to the ITS Executive.
- Identified breaches of this policy and related documents are investigated under the following:
|Printable version (PDF)|
|Title||Patch Management Procedure|
|Purpose||The policy document is a procedure for the management of patches to IT systems University wide.|
|Topic/ SubTopic||Information Technology - Security|
|Effective Date||23 Aug 2019|
|Review Date||22 Aug 2022|
|Responsible Officer:||Director, Information Technology Services|
|Approved By:||Chief Operating Officer|
|Contact Area||Information Technology Services|
Information Infrastructure and Services Rule 2015
Discipline Rule 2018