Guidelines for Security Patch Management on Windows File Servers

Transcription

1 Guidelines for Security Patch Management on Windows File Servers Introduction The following notes offer guidelines and best practice with regards preparing, reacting and managing critical security patch rollouts across live services. These guidelines have come about as a result of a policy being agreed at the C&IT meeting of February 2004 where EUCS will advise each service provider on the criticality of the security patch and propose a schedule for the implementation of that patch. It is then the responsibility of the service provider to take that advice or run the risk of greater disruption should their system become compromised. The policy details can be viewed at Notification of release Through our support contract with Microsoft we are receiving advanced notification of the release of patches. This information is under our Non Disclosure Agreement. This notification is generally around 24 hours before release. At this point in time Microsoft will not inform us of what the patch is or the area it concerns. The information only helps us schedule staff work duties in readiness for its release. Once the patch has been released and made available for download to the Software Update Services Servers, notification of content change is ed out, alerting us that content on the SUS server has changed. This does not inform us of what the patch is or the area it is involved in. A check of the logs on the SUS server however will provide us with the relevant information. There is a Microsoft security update mailing list which sends subscribers an e- mail containing details of the patch. SUS Servers Amanda.ucs.ed.ac.uk is the parent SUS server. It is installed in the preproduction forest. It is configured to synchronise its content with Microsoft at 1:00 am on a daily basis. When notification of new content is received, the Architecture Services Team manually approve the updates on this server for release into the pre-production forest. File servers in the pre-production forest can then pull the latest approved updates from Amanda for testing. Flora.ucs.ed.ac.uk is a child SUS server installed in the production forest. There is no automatic update schedule set. In order for Flora to receive updates a manual sync with Amanda is carried out by the Architecture Services Team. File servers in production can then pull the latest updates

2 from Flora which have been approved on Amanda and tested in pre production. Sustain.ucs.ed.ac.uk is a child SUS server installed in the production forest. It is configured to synchronise its content with Amanda at 10:00 am on a daily basis. This server is used by Central Lab workstations and managed desktops for their approved updates. The fact that Sustain is synchronised with Amanda is an important one to be aware of. Updates are approved on Amanda as soon as the Architecture Services Team have read the notification. From this point we use the pre production forest servers for testing. The production infrastructure file servers are configured to receive their updates from Flora. In effect, workstations configured to receive their updates from Sustain can potentially install these updates earlier than those systems configured for Flora. Desktop Services have made the decision to prime the Central Labs to receive appropriate updates shortly after release. Note that the current version of SUS does not generally provide service packs. It is currently designed for security updates. This looks set to change with version 2 later in Having said that, service pack 4 for Windows 2000 and service pack 1 for XP can be made available via SUS. However, these service packs are not approved for release via the SUS service at the University of Edinburgh. It is felt that providing such large updates would be problematic in terms of time, performance and subsequent troubleshooting should a new release go out for download. If you are intending configuring systems for SUS, please ensure that those systems are up to date prior to joining the service from the Microsoft Windows Update site. Once this has been done, new security patches can then be obtained from the SUS service. Please note that general patches for other applications on your systems may not be available via SUS. At present the SUS service deals with critical security updates. Notification of patch availability The following majordomo mailing list is used to announce the availability of approved updates and the fact that the Domain Controllers will be patched and/or restarted with those updates. ad-announce Announcements relating to Active Directory changes In the event of a restart of the Automation Services, which the Automation Portal relies on, an alert will be ed to automation-portal Notification of changes to the Automation Portal

3 In the event of a restart of the Exchange server Quicksilver which runs the ediary service, an alert will be ed to ediary-users Announcement list for ediary Users In the event of a restart of the DFS file servers and the Profile servers, an alert will be ed to ucs-desktop-announce complabs In the event of a restart of the Call Management System CMS, an alert will be ed to cms-users If you wish to be notified about any of the above services then please ensure you have subscribed to the relevant majordomo list. Any alerts will also be viewable from the Computing Services Service Alerts web page at Determining when a patch should be installed Although security updates are given ratings by Microsoft, (Critical, Important, Moderate and Low) these are broad categories. Site specific issues have to be taken into account when rolling out patches. For example, a patch for IE can be announced as critical from Microsoft but if you are not running IE from a file server then such a patch can be rolled out when it is convenient to do so. Other security issues may not yet have been exploited in the wild, or perhaps rely on certain ports being open. Ideally when a patch is released, the Architecture Services Team will test it out in pre-production and then schedule for rollout throughout production servers. However, there will be times when an alert is so critical that the rollout has to take place in pre production and production on the same day. There is a trade off between how quickly a security update should be rolled out against how long testing can sensibly be done, balanced against maintaining uptime and access to systems during the day, or risking the loss

4 of file servers due to automatic patching out of hours. It is preferable to have qualified staff on hand in the event of systems failing to restart after patches. With this in mind the following guidelines have been drafted. Guidelines The Architecture Services Team will assess each security update as it comes in and advise on whether the recommended rollout timetable is urgent or non-urgent. will maintain a list of service providers and server administrators who will be contacted with security patch advice. will maintain a list of service providers on whose behalf the Architecture Services Team will patch and/or restart their servers. will notify the relevant mailing lists with the patch details and the recommended rollout timetable. maintain a list of server SUS settings and make these known and agree changes where and when required with service providers. Service Providers should provide sufficient contact names providing cover for their service. should determine the relevance of the advice to their service. confirm their decision with the Architecture Services Team. should notify the relevant mailing lists for their users with the recommended rollout timetable. should notify the Architecture Services Team once the patch and/or restart has been implemented if they are carrying out this work themselves. In the event of the Architecture Services Team advising on a patch and restart as per a recommended timetable, it is expected that service providers will make best efforts to comply with this advice. The responsibility lies with the service providers to act upon the advice given by the Architecture Services Team bearing in mind that once a patch has been released a service may effectively be left wide open to a potential security breach until the patch is in place.

5 It is important to appreciate that some security updates require a restart. Failure to do so can result in: a/. the patch not taking effect therefore not fixing the security issue b/. the server will not accept any more updates until the previous update has been successfully completed through a restart. Note that not all patches require a restart. These are referred to as hotfixes. Patch rollout timetables There are essentially two timetables the urgent and non-urgent. Urgent Timetable The implementation of the urgent timetable is determined by the critical nature of the security update and the rollout of the patch will be advised on the basis of an immediate implementation. Note that the urgent timetable does not necessarily mean a restart will be required. The Software Updates Services (SUS) settings on the file servers will be overridden with manual intervention from the Windows update site in order to implement the patch. The pre-production forest will be patched first, followed by the domain controllers in the production forest. From there all other servers will be dealt with. Non-urgent Timetable The non-urgent timetable is based on the nature of the security update and the SUS settings that have been pre-configured on all file servers and have been agreed with each of the service providers. The implementation of this timetable is determined by the manual synchronisation of Flora with Amanda and then a poll window over the next 22 hours by the production file servers using SUS. These file servers are set to one of either two settings: automatic download, install and restart if required This option requires no intervention. A potential drawback if this is scheduled during the night is the unavailability of qualified staff to deal with any problems should it fail to come up after a restart. automatic download and prompt/notify

6 This option relies on an administrator logging into the server, at which point they will be notified of a downloaded patch ready to install. A manual restart may then be required. The production forest has a mix of these settings which has been determined by the nature of the servers role, whether that role has redundancy built in, and whether it is necessary to have staff available on standby. The non-urgent timetable is more relaxed, provides for a longer test period, and enables service providers a greater degree of flexibility in scheduling the rollout. However, it should be viewed as no less important and the Architecture Services Team would expect patches to be implemented as per the agreed timetable within a few days of the patch being released. The responsibility for unpatched systems which run beyond the recommended timetable lies with the service provider. Garry Scobie Architecture Services Team April 2004