NOT PROTECTIVELY MARKED. A087 Version 1.0

Transcription

1 POLICY Security Classification Disclosable under Freedom of Information Act 2000 Yes POLICY TITLE Vulnerability & Patch Management POLICY REFERENCE NUMBER A087 Version 1.0 POLICY OWNERSHIP DIRECTORATE BUSINESS AREA ENABLING SERVICES INFORMATION AND COMMUNICATIONS TECHNOLOGY POLICY IMPLEMENTATION DATE June 2015 NEXT REVIEW DATE: June 2016 RISK RATING EQUALITY ANALYSIS HIGH HIGH Warwickshire Police and West Mercia Police welcome comments and suggestions from the public and staff about the contents and implementation of this policy. Please write to the Business Planning Manager, Strategic Service Improvement, at Hindlip Hall, PO Box 55, Worcester, WR3 8SP or 1

2 1.0 POLICY OUTLINE Information Communication Technology (ICT) is key to Warwickshire Police and West Mercia Police (WPWMP) being able to deliver services to the public. Vulnerabilities in software and firmware present a risk to availability, confidentiality and integrity of systems and their data. The forces have an obligation under the Public Service Network Code of Connection (PSN CoCo) and the Police Community Code of Connection (CoCoCo) to undertake vulnerability management including the application of security patches. 2.0 PURPOSE OF POLICY This policy and its accompanying procedure are directly linked to the overarching Information Assurance policy. This document, details vulnerability & patch management and is intended for use by all ICT support staff, business units and management. The procedure is contained within a separate document, not disclosable under FOI. 3.0 IMPLICATIONS of the POLICY The implications of this policy are considered as being: The organisation has a regulatory obligation under the PSN CoCo and CoCoCo to develop and operate a Patch Management policy and to apply patches with minimal delay to ensure compliance with the policy. Application of patches promotes improved availability, integrity and confidentiality of force information. Implementation of this policy has both resourcing and financial implications, namely, the cost of provisioning specialist tools and staff resources including training, to operate the policy. For unsupported systems that cannot be patched, the organisation will manage related risks. 4.0 CONSULTATION Consultation has taken place with Data Protection Officers, Information Security Officer, Head of Forensics, Head of MIU, Head of Territorial Policing, Head of Operational Support Services, Head of Crimes Management, Head of Finance, Head of Procurement, Head of Estates, Head of ICT and key internal ICT stakeholders 5.0 DOCUMENT HISTORY The history and rationale for change to policy will be recorded using the following chart: 2

3 Date Author / Reviewer Amendment(s) & Rationale Date of Approval / Adoption Paul Williams V0.1 Initial draft version N/A Paul Williams V0.2-V0.5 numerous internal N/A revisions and consultation within ICT Paul Williams V0.6 migrate to Force N/A Template Paul Williams V0.7 incl Invest, Maintain, N/A Retire rationale, & split procedure out to separate doc (non-foia) Paul Williams V0.8 incorporating feedback N/A from ICT stakeholders Paul Williams V0.9 incorporating feedback N/A from critical friends Paul Williams V1.0 for approval JNCC 03/06/2015 Document References: Ref 1: Cabinet Office. (2012). Common Standard for Patch Management. Available: Common Standard for Patch Management 6.0 KEY PRINCIPLES 6.1 The policy promotes a risk-managed approach to vulnerability assessment and application of patches and adopts the following key principles: The policy applies to all supported software & firmware installed on electronic assets in the WPWMP ICT estate including server, End User Devices (e.g. PCs, Winterms, Laptops etc), networking components and IP telephony All key ICT Systems will be classified by ICT, where necessary in liaison with relevant Information Asset Owners, as either INVEST, MAINTAIN or RETIRE (See Annex A) depending on their lifecycle status. In principle, systems classified as INVEST or MAINTAIN should be patched where as systems classified as RETIRE, are not mandated for patching but could be risk managed instead. This policy applies to security vulnerabilities and related security patches and service packs only. To minimise the risk of a loss of service availability the number of changes to a system must be kept to a minimum therefore non-security related patches should not be applied unless the patch addresses a specific issue or requirement. There should be a means of monitoring for new vulnerabilities; prioritisation of patches based on risk to infrastructure, and identification of which patches need to be/have been applied to which ICT assets (Ref 1); Only software necessary to deliver the organisation s business should be installed (to minimise the need to patch) and it should be configured such that it minimises the vulnerabilities available to potential attackers (the attack surface ) (Ref 1); 3

4 Only the latest stable release of software should be used, not necessarily the latest released version (sometimes the latest version has more vulnerabilities and should not be used until the first service update release, e.g. service pack) (Ref 1); The sources of patches should be confirmed and those patches should be evaluated and regression tested before deployment into a live ICT infrastructure (Ref 1); Updates and patches should be deployed into the ICT infrastructure as quickly as possible to minimise exposure times to known vulnerabilities (particularly if a critical vulnerability) (Ref 1); The update and patching process should be integrated between operational and security management functions to achieve an effective decision-making process and minimise and resolve delays caused by conflicts in business priorities (Ref 1); A retrieval and deployment architecture for updates and patches should be implemented that is appropriate for their use informed by the output of a technical risk assessment and organisational risk appetite (Ref 1); Good update and patch management processes and regimes should be enforced to make it more difficult for potential attackers to successfully attack an ICT infrastructure and therefore the information held on it (Ref 1). 6.2 Further reading /support Further guidance on patch management can be found in the PSN Technical Standard, Common Standard for Patch Management. 6.3 Policy Review This policy & procedure must be reviewed on an annual basis. 6.4 Procedure The procedure is a restricted document 7.0 ASSESSMENT AND ANALYSIS The Equality Analysis (EA), Health & Safety Assessment (HAS) and Risk Assessment (RA) associated with this document are available on request. 4

5 Annex A: 1.1 System Classification & Prioritisation For the purpose of supporting compliance obligations, systems should be prioritised in terms of their business criticality, placement in the infrastructure, supportability and the data and services held within them. The objective should be to place them in one of three groupings: Invest Maintain Retire These groupings reflect a system life-cycle, where new systems are sourced, approved, funded and implemented under INVESTMENT, age and enter a static state under MAINTAIN and ultimately become legacy applications, which when listed for replacement move to RETIRE INVEST Systems in this category will generally have the following characteristics: Support core business activities Operate current, supportable software Operate on current supportable hardware, or virtualised platforms Have a defined lifecycle, with an end-of-life date of greater than 5 years. INVEST systems reflect the current or planned systems which will form the operational infrastructure of the organisation for the next 5-10 years. They are often active projects and may still be under development or implementation. New systems and software introduced into the estate will initially fall under the INVEST category. INVEST systems will normally be easy to develop a business case for further expenditure and should form the core of a well managed estate MAINTAIN Systems in this category will generally have the following characteristics: Support core or non-essential business activities Run software which is approaching end of life within 2 years, or may have recently expired (normally less than 12 months) Operates on hardware which is approaching end of life within 2 years, or may have recently expired (normally less than 12 months) May be patchable only through use of specialist support agreements or bespoke development MAINTAIN systems reflect existing systems forming part of the operational infrastructure of the organisation, but are understood to have a finite (if not yet documented) lifetime. 5

6 These systems are not generally related to active projects, unless under a replacement programme, and will generally be considered to be static systems operating under a BAU model. MAINTAIN systems may have an operating life between 2-10 years, and it is not uncommon for major systems (such as databases, financial systems) to have operational lifecycles extending to 20 years, through incidences of these are becoming rarer. MAINTAIN systems will not normally be easy to develop a business case for further expenditure RETIRE Systems in this category will generally have the following characteristics: May support some business activities, which are non-core in nature Run out of support software and/or operating systems, which may be expensive or difficult to find skilled resource to manage Operate on unsupportable and end of life hardware Cannot be patched or maintained in a secure state even with specialist support Will generally be depreciated investments that can be removed from asset registers with no financial penalty RETIRE systems reflect aged or obsolete technologies which previously formed the operational infrastructure of the organisation, but which are no longer operationally required. RETIRE systems will often reflect a high cost operation due to their size, power consumption and inability to migrate to current modes of operation (i.e. Cold Corridor, virtualisation or cloud). They represent a major area of vulnerability on an estate due to the availability of public exploits and inability to patch. 1.2 General Approach The general approach should be to maximise current supportable INVEST technologies, minimise and actively manage MAINTAIN technologies and work to eliminate RETIRE technologies. 6