Patching Policy

Prepared by: Created: Edmund Lim 5 July 2011

Description
The policy outlines the strategy to successfully implement and maintain organisational information technology system, confidentiality and integrity of information assets. This results in a simplistic model that provides many benefits, namely: Keeping all systems up to date with fixes for security vulnerabilities and other known problems or bugs. Prevent system downtime due to a security exploit or bug which may cause unplanned service downtime. Provide stakeholders ample time with scheduled patch management cycles and testing periods before deployment in production environment

Modification History
Version Number Version 1.0.0 Version 1.0.1 Version 1.1.0 Date 20/02/2009 14/03/2009 11/04/2009 Author Edmund Lim Edmund Lim Edmund Lim Comments First Draft, Refer For Comments IT Security Second Draft, Refer For Comments ESS Final Version

1
Last modified: 6 July 2011 CRICOS No. 00213J

Enterprise System Services Patching Policy

Policy Statement
This policy defines a patch management process for deploying patches and firmware updates, to maintain existing high levels of IT security and business requirements.

What this policy addresses

Enterprise System Services (ESS) have a responsibility to provide a secure network environment for its corporate services. It is ESS policy to ensure that all systems managed by ESS have the most recent operating system updates, security patches and firmware updates installed. This policy aims to assist the process in maintaining operational efficiency and effectiveness, mitigating security vulnerabilities, and maintaining the stability of the organisations production environment. ESS will also perform the appropriate backups and snapshots before a QA or Production Service is scheduled for patching for rollbacks to minimise risk and service disruptions.

Affected Services
ESS is responsible for the overall patch management implementation, operations and procedure. ESS ensures all known and reasonable defences are in place to reduce system vulnerabilities. To comply with this, Stakeholders will have to agree to the following:

Environment
Development and Test: Systems in this category can/will be patched on the last Tuesday of every month. It is also the responsibility of the stakeholder to check their application/services after this patch cycle. QA Environment: Systems in this category will be patched 1 week after its Development and Test systems have been patched or with consultation with its stakeholders for a suitable time. Production Environment: Systems in this category will be patched after QA systems have been successfully patched in consultation with the stakeholders. If there are no QA systems, it is the stakeholders responsibility to check that the patches to be applied will not effect its application and potentially cause a service disruption. This must be performed during scheduled maintenance windows and consent from the QUT Change Management Process, i.e. SCMG or CAB.

2
Last modified: 6 July 2011 CRICOS No. 00213J

Enterprise System Services Patching Policy

Category
The following table details a four-point priority scale, together with time frames for implementation.
Category Emergency / Critical Priority Emergency High Non-Emergency Medium Low Prescribed Time Frame Within 24 hours Within 1month Depending on availability, within 1-2 months or scheduled patch cycle Within scheduled patch cycle

Table 1 Update Priorities and Recommended Deployment Timeframe If high-value or high-exposure asset(s) is/are impacted by the vulnerability or attackers have historically targeted the affected assets, then there may be a case for raising the priority of the response from that originally calculated. Conversely, if extensive mitigating factors are in place, such as countermeasures that minimise the risk of compromise, or only low business impact assets are affected, then there may be a case for lowering the priority of the response from that originally calculated. If the vulnerability update addressed is already being exploited or is imminently likely to be exploited, or if the update addresses a system instability being encountered in the production environment, then there is a case for classifying the request as an emergency. This categorisation may give priority over all other changes happening within the production environment.

Patch Cycle
A patch cycle gives the organisation control over how and when software patch releases are deployed into the operational environment. ESS would undertake the following patch cycle process. Risk Evaluation / Assessment: The purpose of this phase is to evaluate and assess the severity and risk of the vulnerability and a priority level will be assigned to each patch. Communication: The purpose of this phase is to identify the stakeholders and communicate with them on how and when the deployment will take place and allowing sufficient time for both parties to respond. Testing: The purpose of this phase is to decide, for any given patch, whether to deploy patches from the test environment into the production environment. Scheduled Cycle/Time: The purpose of this phase is to develop a patch cycle schedule for all hosts to ensure that all systems are patched regularly in a managed fashion. Deployment: The purpose of this phase is to successfully roll out the tested patches and updates into the production environment whilst minimising impact on system users.

3
Last modified: 6 July 2011 CRICOS No. 00213J

Enterprise System Services Patching Policy

Risk Evaluation / Assessment

Communication

Severity Rating
Emergency 24hrs High Within 1month Medium Within 1-2months Low Within scheduled patch cycle *refer to Table 1

Scheduled Patch Cycle

Testing

Deployment

Figure 1 Patch Cycle

4
Last modified: 6 July 2011 CRICOS No. 00213J

Enterprise System Services Patching Policy

Definitions
Maintenance is work that is done to a host that improve operating system or application security and/or functionality. Host is a platform that consists of hardware or a virtualised platform and an operating system that allows at least one application to provide a service to users. Application is any utility or service that provides some functionality to remote or local users Development Hosts are used to develop new applications for the production environment. Test hosts are used to test developed application prior to release in the QA environment. QA hosts are the latest stable application developed from the test environment and is kept synchronised with its relevant production host. Production Hosts provide live corporate services to users. Updates can apply to software, device drivers or firmware, which provide enhancements or fixes bugs.

Roles/ Responsibilities/Guidelines
The role of the ESS Security team is to ensure that all outstanding updates and packages are evaluated and assessed according to the security risks that affect the overall function of an application or service provided by ESS. The role of the ESS System team is to ensure all updates and packages evaluated and assessed by the ESS Security team are deployed to the relevant hosts according to the level of risk, and priority as evaluated by ESS Security team. The ESS System team will follow the procedures below (also refer to section 2.3): 1. The stakeholders or application administrators are notified of the ESS approved updates and patches to be deployed in the appropriate Development and test environment. Backups and snapshots will be taken as a precaution to prevent data loss and any disasters. This process will be tested appropriately in liaison with stakeholders or application administrators. Patches and updates will be installed (where such hosts exist) on development hosts, then test hosts, then QA hosts and finally with Service Change Management approval, onto production hosts. However, the timeframe of deployment will depend on its severity rating (refer to Section 2.2, Table 1) Installation on production hosts must be performed during scheduled maintenance windows and stakeholders will be notified of the scheduled time and date. Unless the patches and updates are of Emergency severity rating, such a critical vulnerability may then be performed during business hours.

2.

3.

5
Last modified: 6 July 2011 CRICOS No. 00213J

Enterprise System Services Patching Policy

4.

Patches with Emergency severity rating will be patched within 24 hours after sufficient testing on a test host. Stakeholders will be informed and all appropriate backups and snapshot scheduled before patches are deployed.

Related Documents
QUT Manual of Policies and Procedures, Chapter F, F/1.2 Information Security Policy
http://www.mopp.qut.edu.au/F/F_01_02.jsp

AS/NZS ISO/IED 17799:2005 Information System development and Maintenance, Compliance. Chan, Jason, Patch Management Essentials, January 2004, PatchManagement.org, URL:
http://www.patchmanagment.org/pmessentials.asp

Payne, Shirley C., A Guide to Security Metrics, 11 July 2001, SANS GSEC, URL:
http://www.sans.org/rr/papers/5/55.pdf

6
Last modified: 6 July 2011 CRICOS No. 00213J