Good Practice Guide Author: A Heathcote Date: 22/05/2017 Version: 1.0 Copyright 2017 Health and Social Care Information Centre. The Health and Social Care Information Centre is a non-departmental body created by statute, also known as NHS Digital.
Contents 1 Purpose 3 2 Scope 3 3 Applicability 3 4 Guidance 3 4.1 General Approach 3 4.2 Information Security Incidents 4 4.3 Information/Data Breach 5 4.4 Information Security Incident Response Management 5 4.4.1 Information Security Incident Reporting 6 4.4.2 Information Security Incident Analysis 7 4.4.3 Information Security Incident Response 8 4.4.4 Reporting and Closure of Incident 9 4.5 Learning from Incidents Lessons Identified 9 4.6 Follow on Actions 9 4.7 Specific Reporting Requirements 10 5 Testing 10 6 Further Reading and Advice 10 7 Key Words 11 Copyright 2017 Health and Social Care Information Centre. 2
1 Purpose The purpose of the Information Security Incident Good Practice Guide (GPG) is to provide guidance on how information security incidents should be managed. This guidance will enable the production of a process that: Clearly identifies information security incident types. Has a reporting methodology. Identifies roles and responsibilities. Has a methodology for assessing the severity of the incident. Has a procedure for investigating/responding to the incident. Identifies how evidence should be collected. Is able to identify lessons learnt. Has clear follow on actions. A sound information security incident response process will minimise the immediate and long term business impact of incidents that have the potential to affect the confidentiality, integrity or availability of NHS data and other UK Government information. It will also enable the organisation to react to incidents in a structured and cohesive manner. 2 Scope The Information Security Incident GPG relates to information security incidents affecting the NHS organisation s (large or small) IT systems or services (in electronic or hard copy physical form) used for storing, processing and transmitting NHS and other UK Government information. 3 Applicability This GPG is applicable to and designed for use by any NHS, health and social care or associated organisations that use or have access to NHS systems and/or information at any level. 4 Guidance This GPG supplements the Example Policy on producing an Information Security Incident Policy and provides greater detail on how the policy requirements can be achieved. It is not prescriptive and it is realised that different organisations will require different levels of management and response. This GPG provides the minimum that should be considered. The guidance provided should be scaled according to the size of the organisation. 4.1 General Approach To have an effective information security incident response process it is necessary to: Define what constitutes an information security incident. Define what constitutes a data breach. Copyright 2017 Health and Social Care Information Centre. 3
Design and implement an incident response process (i.e. management process identifying roles and responsibilities); aligning this with other (e.g. IT) incident response processes. This should include: A reporting methodology. An analysis and response methodology. A mechanism or support process for the collection of evidence. Have a process for learning from incidents; i.e. lessons identified or lessons learnt to reduce the risk of re-occurrences. Have defined follow on actions, where required, with clear identification of any onward reporting (i.e. to National bodies) that is required for types of incidents. To ensure that the information security incident response process is fit for purpose it should be tested regularly, at least once a year, and be reviewed against HMG and NHS requirements, including legislative criteria. This GPG provides guidance and, where applicable, examples on: Defining information security incidents and data breaches. Producing an information security incident response management process. Being able to identify lessons from incidents. Testing process to ensure the process is fit for purpose. The information security incident response procedure or process for any organisation should be tailored to and complement the processes in place for business continuity, disaster recovery and, where evidence is required for administrative or criminal investigations, the forensic readiness processes. 4.2 Information Security Incidents An Information Security Incident is an event, or chain of events, that could compromise the confidentiality, integrity or availability of information. Examples of information security incidents can include but are not limited to: Potential and suspected disclosure of NHS or other UK Government information to unauthorised individuals. Loss or theft (attempted or actual) of paper records, data or IT equipment on which data is stored. Disruption to systems and business processes. Inappropriate access controls allowing unauthorised use of information. Attempts to gain unauthorised access to computer systems, e.g. hacking. Records altered or deleted without authorisation by the data owner. Virus or other malicious (suspected or actual) security attack on IT equipment systems or networks. Blagging offence where information is obtained by deception. Breaches of physical security e.g. forcing of doors or windows into secure room or filing cabinet containing NHS sensitive or other UK Government information left unlocked in accessible area. Copyright 2017 Health and Social Care Information Centre. 4
Leaving IT equipment unattended when logged-in to a user account without locking the screen to stop others accessing information. Human error such as emailing data by mistake. Covert or unauthorised recording of meetings and presentations. Damage or loss of information and information processing equipment due to theft, fires, floods, failure of equipment or power surges. Deliberate leaking of information. Insider fraud. It is recommended that the organisation categorises information security incidents into types so that the response and reporting processes can be as simple and manageable as possible. This could be: Hard copy information security incident deliberate (i.e. stolen or destroyed) or accidental (lost or destroyed). Malware attack e.g. virus attack, ransomware, denial of service, etc. Accidental electronic breach emailing sensitive data by accident, emailing incorrect personnel, etc. Unauthorised access to user account. Loss of hardware (lost or stolen) e.g. laptop, smartphone, USB pen Drive, DVD, etc. 4.3 Information/Data Breach As the NHS handles considerable amounts of personal and sensitive data (Person Identifiable Information [PII]), losses of this nature are particularly damaging not only to the patient or person concerned but also to the reputation of the NHS as a whole. Therefore, within information security incidents there should be a category (or more if there is the need to sub categorise) for information/data breaches that relate to PII. An information/data breach is defined as a security incident where sensitive, protected or confidential data has intentionally or unintentionally been released or obtained by persons who are not authorised to view or access it. Therefore, in addition to the incident responses mechanisms outlined in this GPG these types of incident must include regulatory and legislative reporting and response activities as required by the Data Protection Act 1998 (DPA 98), the forthcoming EU General Data Protection Regulations (GDPR 2018) and the Data Guardian requirements (Caldicott principles, data security standards and data security recommendations). 4.4 Information Security Incident Response Management To be able to manage and respond to information security incidents a comprehensive process with clear procedures for reporting, assessment and areas of responsibility is required. For each organisation this will be different; for larger organisations there may be dedicated teams but for smaller organisations the functions may be secondary to their primary roles or the process may need to be included within a contract to the third party provider for IT related issues. This GPG provides guidance and some examples of what should be considered for inclusion in the process. Copyright 2017 Health and Social Care Information Centre. 5
As a minimum, the information security incident response process should cover the below and be captured in one document i.e. an information security incident response plan or procedure. Information security incident reporting. Roles and responsibilities. Analysis of incident. Response to incident. Reporting and closure of incident. Onward reporting internal and external. Follow-on actions. Lessons learnt or identified. Testing. The information security incident management process should be fully documented both as a Plan or Procedure and also during the reporting and reaction to any incident. Where third party/outsourced IT providers are utilised the contract should include the requirement for the provider to have an information security incident management process. The guidelines in this GPG can be used to frame the contractual requirements. 4.4.1 Information Security Incident Reporting In order to avoid confusion and maximise the speed of response to incidents it is important that the reporting process is simple and clear. Larger organisations may utilise a bespoke incident reporting IT system/software package. The information security incident process could, and should, be integrated into this. However, notwithstanding the use of a bespoke software package the principles and approach outlined in this GPG should be used to ensure the software (if utilised) and the associated processes capture the necessary information and manage the process appropriately. Within the organisation it is suggested that the below approach is taken and tailored to the specific size and outsourced providers to the organisation: Have a single reporting point by telephone (essential) and e-mail (optional addition). This reporting point should be clearly displayed on IT systems (affixed to the front of monitors for instance) and on notice boards as well as within the organisation s general operating procedures. For notice boards and operating procedures, it is recommended that a short synopsis of the types of issue that constitute an information security incident are listed to enable users to realise when an incident has occurred. This single reporting point will be required to assess the report and then, if required, pass it on to the NHS National Service Desk. Have a single, simple reporting form this should be no more than 2 pages but preferably only one page with as few questions as possible. It should be in hard copy (in case the incident affects the IT system the user is operating from) and also available from the organisation s IT system/intranet. The required information is suggested to be no more than: Copyright 2017 Health and Social Care Information Centre. 6
Date. Location. Short summary of what occurred. Type of incident e.g. e-mail, lost USB device or paper. Contact details for obtaining further information. In the Plan or Procedure, it should also be stated, preferably as a mandate, that all staff are responsible for reporting security incidents. 4.4.2 Information Security Incident Analysis An essential element of the information security incident response plan is the assessment of the severity of the incident as early as possible. This will enable the most appropriate response to be enacted and a priority allocated for their resolution. The analysis of an incident is likely to require the skill and expertise of various groups within the organisation (IT, operations, legal and human resources) as well as external agencies (police authority, forensic specialists). For larger organisations the internal elements should be available and links to the external ones already established. The plan should allocate the roles (rather than named individuals) to meet the internal analysis process and for the external links details of telephone numbers, e-mails and points of contact clearly outlined. For smaller organisations there may not be specific roles or personnel with the necessary skills. However, there will be the need for an initial analysis before either the outsourced provider is required to react or external assistance is invoked. A role within the organisation with the closest set of skills should be identified; this may be as simple as the person to take the issue forward (most likely the information governance lead within the organisation) with the outsourced provider or contracted assistance. The analysis, either by the organisation itself or via the outsourced provider and identified in the contract with them, should include the following processes: Assessment of the severity of the incident against an agreed defined, severity scaling. This could be one taken from industry best practice, such as Information Technology Infrastructure Library (ITIL), or one designed by the organisation. Identification of type of incident paper loss, e-mail, portable IT media. Assessment of scale of incident in terms of data size e.g. Gb of data or number of pages lost or distribution list. Identification of classification or type of data e.g. OFFICIAL, OFFICIAL- SENSITIVE, NHS CONFIDENTIAL or NHS PROTECT. Identification of whether the information is PII. Identification of whether it is a potentially criminal activity and requires local Civil Police involvement. If this is the case it will also require the collection of evidence in a forensically sound manner this may require external or internal forensic computing support. All decisions, i.e. the analysis against the above criteria, made during the response to incidents should be recorded. If the data breach is identified as PII then the involvement of the organisation s Data Protection Officer and Caldicott Guardian will be required. Copyright 2017 Health and Social Care Information Centre. 7
4.4.3 Information Security Incident Response The response to an incident is likely to require the skill and expertise of similar groups to those who undertook the analysis. For larger organisations, the majority of this is likely to be internal (i.e. IT operations, HR department, etc.) with the use of external support if the incident merits it (i.e. civil police or NHS forensic computing teams from NHS Protect NHS Business Services Authority if the offence is potentially a criminal one or one that will require NHS disciplinary action). For smaller organisations, the response is likely to be undertaken by the third party IT provider or via a separate contract with a provider to provide incident response. Whether the response is to be completed from within the organisation s resources or through contracted third party services the response activities should consider the inclusion of the below as a minimum: Date, time and location of the incident. Identification of who (role) is responsible for the investigation. Identification of expected outcomes. Identification of stakeholders involved and/or impacted. Preservation mechanism for evidence. Investigation process for the incident (main criteria of process shown below): Appointment of investigating officer. Engagement of appropriate specialist assistance e.g. IG, IT, Security, external specialists, etc.). Coordination requirement if the incident is between organisation boundaries or involves more than one organisation. A root cause analysis of the incident. Inclusion of rules of evidence, interviews, preservation of evidence, etc. to ensure findings can be used by Civil Police (if required) or internally for disciplinary matters. Documentation of all investigative activities. Maintaining of an audit trail of events and evidence supporting decisions taken during the incident Where appropriate external informing and internal escalation, such as: Information Commissioner. Data Protection Officer. Caldicott Guardian. Department of Health, NHS Trust, Primary Care Trust etc. NHS Protect NHS Business Services Authority for forensic computing support. Civil Police for criminal investigation. Informing of the impacted data subjects (patients, staff). Copyright 2017 Health and Social Care Information Centre. 8
Identification and management of the consequent risks of the incident (these may be IG-related or involve risks to patient safety, continuity of treatment etc.) Implementing recovery actions to the incident. Invoking the organisation s disciplinary procedure as appropriate. Identification of appropriate counter-measures to prevent recurrence. Lessons identified. All actions and decisions made during the response to incidents shall be recorded 4.4.4 Reporting and Closure of Incident An initial report should be raised as early as possible into the incident to qualify the severity of the incident and outline the proposed response and investigation activities. This will assist in determining what resources are required to respond. This report should be briefed to senior management within the organisation for the endorsement of the proposed response and investigation activities. Once the full analysis and response, including the investigation element has been completed, a draft report should be produced and reviewed by the relevant stakeholders (e.g. the person managing the response, the investigating officer and the relevant information asset owner, senior information risk owner or chief executive/senior manager) before being finalised and signed off. The report should include the following: Summary of the incident. Findings of the investigation. Responses undertaken. Onward reporting requirements. Further follow-on actions. Lessons identified. 4.5 Learning from Incidents Lessons Identified As essential and useful part of any information security incident response is the identification of where lessons can be learnt to improve the security posture and to reduce the risk of the same type of incident occurring again. As outlined under Section 4.4.3 (Information Security Incident Response) the investigation of the incident and the response/recovery from the incident will enable lessons to be identified and these should be included as a specific section in the Incident Report. Incidents should also be analysed to determine if there are trends or patterns. The result of these reviews and lessons identified may result in technical or procedural changes or specific user guidance/awareness; termed follow-on actions. 4.6 Follow on Actions Post the issue of the report and the assessment of the lessons identified follow-on actions may be required to: Update or change the incident response process. Copyright 2017 Health and Social Care Information Centre. 9
Update or change the IT System configurations (hardware or software). If these are required, then they should be implemented through the organisations Change Management process. Update or design training either as specific training for a nominated role (e.g. on a software product for a system administrator) or as general user awareness training. Change the procedures, policies, standards or guidelines or introduce new ones to reduce the risk of that type of incident re-occurring. 4.7 Specific Reporting Requirements In the response to information security incidents and the identification of any escalation or onward reporting of the event the below table summarises those external agencies that are to be informed and for the type of event concerned. Incident Type Technical events (hacking, Denial of Service, malware, hardware or software vulnerabilities Criminal event Loss of personal data Compromise of CESG/NCSC approved Crypto products or Keymat Reported To GovCertUK for information sharing purposes or national security investigation Police authority Information Commissioner s Office, Dept of Health and respective Caldicott Guardian CINRAS (Comsec Incident Notification Reporting and Alerting Scheme) 5 Testing As best practice, regular testing of the information security incident response/management process should be completed to check that it is fit for purpose. This is particularly required if it is not utilised often for real. Different levels of testing can be done and it is recommended that each of the below is undertaken at least annually. For smaller organisations, where the response is undertaken by an outsourced third party provider, this will need to be included in the contract. It is suggested that where outsourced providers are involved the testing is completed with a representative for the health organisation (probably the information governance lead) present or involved. Table Top Walkthrough Real-time Live Test 6 Further Reading and Advice In addition to the documents listed under Related References, Links and Documents further details and advice on information security incident management can be found at https://www.ncsc.gov.uk/. This GPG does not list the particular references as Copyright 2017 Health and Social Care Information Centre. 10
these change on a frequent basis, however, searches under the below headings will help to locate the current applicable HMG policy and standard or a suggested methodology: Data breach. Incident. Incident management. Incident response. Incident severity. Security incident. Security investigation. This GPG is supported by other GPGs, which should be used in tandem. This includes, but is not limited to: Information Security Incident Business Continuity Policy Disaster Recovery Policy Forensic Readiness Policy Information Security Classification 7 Key Words Analysis, Data Breach, Forensic, Information Security Incident, Investigation, PII, Reporting, Response, Severity Copyright 2017 Health and Social Care Information Centre. 11