Title: Patch Management Andrew Marriott andrew.marriott@fylde.gov.uk 01253 658578 PATCH MANAGEMENT PROCEDURE.DOCX Version: 1.1
Contents 1. Introduction... 4 2. Objectives... 4 3. Context... 4 4. Responsibility... 4 5. Monitoring... 4 6. Review and Evaluation... 5 7. Risk Assessment and Testing... 5 8. Notification and Scheduling... 5 9. Implementation... 5 10. Auditing, Assessment, and Verification... 6 11. Virtual Desktop Environment... 6 12. User Responsibilities and Practices... 6 13. Violations... 6
Document Control Title of Document Patch Management Purpose of Document To provide clear guidance to all employees regarding the installation of software updates. Date of Document August 20 th, 2013 Document Review Date August 2015 Document Author Andrew Marriott Document Version History Date Version Section Description Author 18/07/2008 0.1 All First Draft Andrew Marriott 22/04/2009 0.2 All Revised for Gov Connect compliance. Andrew Marriott 15/09/2009 1.0 - Published. Andrew 20/08/2013 1.1 Section 8 Appendix A New section for VDI. Added reference to the virtual desktops. Marriott Andrew Marriott References None. Distribution List All staff and agents of the Council. Notes None.
1. Introduction 1.1. As software becomes increasingly more powerful, the programming techniques used in its development becomes more complex. This complexity can lead to the introduction of flaws or bugs in the software. Occasionally these flaws can be exploited by third-parties to compromise a computer and, therefore, the integrity of the network and all computers attached to it. 1.2. To mitigate the risks associated with software flaws, vendors release software patches to remove these vulnerabilities. 2. Objectives 2.1. The objective of this procedure is to ensure that computer systems do not pose an unmanaged security risk for the Council. One important step in achieving this goal is ensuring that all applicable and required software patches are applied in a timely and effective manner, taking into account the risks associated with the software being patched. 3. Context 3.1. This procedure applies to all IT equipment used by members, officers and agents of the Council. 4. Responsibility 4.1. The IT Team is responsible for the overall patch management implementation, operations, and procedures. While safeguarding the network is every user s job, the IT Team have the responsibility to ensure that all known and reasonable defences are in place to reduce network vulnerabilities while keeping the network operating. This responsibility includes the tasks detailed below. 5. Monitoring 5.1. The IT Team will monitor security mailing lists, review vendor notifications and Web sites, and research specific public Web sites for the release of new patches. Monitoring will include, but not be limited to, the following:- Scanning the Council s network to identify known vulnerabilities. Identifying and communicating identified vulnerabilities and/or security breaches to GovCertUK.. Monitoring GovCertUK, notifications, and Web sites of all vendors that have hardware or software operating on Fylde Borough Councils network.
6. Review and Evaluation 6.1. Once alerted to a new patch, the IT Team will download and review the new patch within the following timescales:- MS Windows two working days of its release. Linux one week of its release. Other best endeavours. 6.2. IT will categorize the criticality of the patch according to the following: Emergency an imminent threat to Fylde Borough Councils network Critical targets a security vulnerability Not Critical a standard patch release update Not applicable to Fylde Borough Councils environment 6.3. Regardless of platform or criticality, all patch releases will follow a defined process for patch deployment that includes assessing the risk, testing, scheduling, installing, and verifying. 7. Risk Assessment and Testing 7.1. IT will assess the effect of a patch to the corporate infrastructure prior to its deployment. The Team will also assess the affected patch for criticality relevant to each platform (e.g., servers, desktops, printers, etc.). 7.2. If IT categorizes a patch as an Emergency, the team considers it an imminent threat to Fylde s network. Therefore, the Council assumes greater risk by not implementing the patch than waiting to test it before implementing. 7.3. Patches deemed Critical or Not Critical will undergo testing for each affected platform before general implementation. IT will expedite testing for Critical patches against a group of test devices representative of the IT estate, prior to implementation. 8. Notification and Scheduling 8.1. Regardless of criticality, each patch release will require the creation of a helpdesk ticket prior to its release. The IT manager will decide when notifying staff is necessary. 9. Implementation 9.1. IT will deploy Emergency patches within two working days of availability. As Emergency patches pose an imminent threat to the network, the release may precede testing. In all instances, the team will perform testing (either pre- or post-implementation) and document it for auditing and tracking purposes.
9.2. Where possible patches classed as Critical will be implemented outside of normal office hours whilst those classed as Not Critical will be implemented during scheduled preventive maintenance. Each patch will have an approved Helpdesk ticket. 9.3. For new network devices, each platform will follow established hardening procedures to ensure the installation of the most recent patches. 9.4. Appendix A details the target implementation times for the various classifications of patches. 10. Auditing, Assessment, and Verification 10.1. Following the release of all patches, IT staff will monitor helpdesk calls to verify the successful installation of the patch and to monitor any potential adverse effects. 11. Virtual Desktop Environment 11.1. The guidance laid out in this also applies to the Virtual Desktop Environment and applications provided using the ThinApp system. 12. User Responsibilities and Practices 12.1. Users of equipment being patched must not knowingly hinder or stop the update process and, if requested must restart the equipment at the earliest convenient time. 13. Violations 13.1. Failure to comply with this will be dealt with through the Council s disciplinary process and may potentially lead to the termination of employment.
Appendix A Patch Deployment Target Timescales Emergency IT will deploy Emergency patches within two working days of availability. As Emergency patches pose an imminent threat to the network, the release may precede testing. In all instances, the team will perform testing (either pre- or post-implementation) and document it for auditing and tracking purposes. Classification Critical Public Facing Servers (DMZ) Private Servers (LAN) PCs (including virtual desktops) Within five working days of release. Within eight working days of release. Within ten working days of release. Within five working days of release. Within eight working days of release. Within fifteen working days of release. Within five working days of release. Within eight working days of release. Within fifteen working days of release. Not Critical All Servers PCs (including virtual desktops) Within ten working days of release. Within fifteen working days of release. Within twenty working days of release. Within ten working days of release. Within fifteen working days of release. Within twenty working days of release. Not Applicable Patch will not be approved for installation.