Security Incidents Monitoring Procedure | Identifying and Reporting | Classifications and Management | Electronic Money and Authorized Payment Institution | Template for FCA Applications and Authorised Firms

← Return to the Table of Contents for all EMI and API pages

1 INTRODUCTION

HIRETT is committed to the protection of information and has in place a number of technical and organisational measures to safeguard the information it owns. This includes technical security ranging from secure passwords and system encryption, and organisational safeguards ranging from physical building and office security to procedural standards and requirements for the safe handling of information.

These procedures are mandatory and must be followed by all staff as part of the council’s Information Governance Framework the standard for managing information in the council and is one of the linked procedures in the Information Security policy aimed at all staff.

All reports of information security weaknesses or events relating to any of the HIRETT’s information assets are within the scope of this procedure. In addition, any events or weaknesses detected fall within the scope of this procedure.

2 PURPOSE

The Council recognises that from time to time ‘things go wrong’ and there may be a breach of security involving information or equipment holding information. The purpose of this procedure is to ensure that all actual or potential information security incidents are reported centrally to enable the Council to react quickly and effectively to minimise the impact.

The aims of the procedure are as follows:

• Timely advice on containment and risk management;
• Determine whether further controls or actions are required;
• Evaluate lessons learnt and areas for improvement.

All information security incidents will be dealt with by the HIRETT, which comprises of lawyers from the Council’s Corporate Legal Service (Group Members) with a nominated Incident Lead, who will review and advise on incidents and make recommendations on appropriate follow up and corrective action. Specialist input will be sought from ICT Security or Information Management where necessary.

3 SCOPE

This procedure applies to all employees, councillors, agency staff, contractors or any other persons who have access to, or use the Council’s information.
The Council requires commissioned services holding or processing information on its behalf to have in place internal reporting requirements equivalent to this procedure and for any third-party breaches to be reported using this procedure.

4 IDENTIFYING INCIDENTS

There is no simple definition of an information security incident but generally it will involve an adverse event which results, or has the potential to result in the compromise, misuse or loss of HIRETT owned or held information or assets.

Information in this procedure is used as a collective term and may include personal or sensitive personal data as defined under the Data Protection Act 1998 (or confidential personal data as commonly referred to in the health sector) and also business information.

Some examples of information security incidents include (but are not limited to) the loss or theft of information or equipment, incorrect handling of protectively marked information, poor physical security, hacking, information disclosed in error, unauthorised use or access to information or systems.
An incident can be caused by any number of reasons for example human error, lack of awareness or training, deliberate or accidental disregard for policy.

The impact of a security incident can vary greatly depending on the type of information or asset involved. It may for instance lead to an infringement of privacy, fraud, financial loss, service disruption or reputational damage. The purpose of reporting an incident is not to apportion blame but to ensure that any impact is minimised and lessons learnt can be identified and disseminated.

5 REPORTING INCIDENTS

A direct line manager or supervisor should always be made aware of any information security incident and the incident reported in line with this procedure.

All information security incidents should be reported promptly (within 24 hours) by completing an incident reporting form, which can be accessed by via the Information Management incident page and once complete should be emailed to incidentgroup@Hirett.com.uk.

Any incidents involving lost or stolen equipment or a network security issue should be reported to the ICT Service Desk immediately on __________________ and ICT will notify the Incident Lead. For the purposes of this procedure lost or stolen hardware will be logged and may be subject to further investigation depending on the circumstances giving cause to the incident.

The Police should be notified immediately of any incidents involving stolen information or equipment and a crime reference number obtained.

The broad principles of this procedure also apply to cyber incidents i.e. any incident that could or has compromised information assets within the Council’s digital network for e.g. phishing emails or hacking attacks. Any cyber-related incident should be reported in line with this procedure but will be handled in accordance with HIRETT’s Cybersecurity Incident Response Procedure in Appendix D by the Information Assets Cyber Security Incident Response Team (CERT).

In the event that a cyber incident also involves a data breach then it shall remain subject to this procedure and the Incident Lead (or Group Member) will work in conjunction with the CERT Team to resolve the incident and report to regulators as necessary.

6 INCIDENT CLASSIFICATIONS

The severity of an information security incident will be determined in accordance with the incident levels set out in Appendix A.

An incident will be rated in accordance with the Council’s corporate strategy to risk management, which is based on agreed criteria for assessing the likelihood and impact of risk for e.g. detriment to people, financial or legal implications, and reputational damage. A traffic light approach is then used to plot risk whereby red is ‘high’ or ‘very high’ risk, amber is ‘medium’ risk, green is ‘low’ risk and for the purposes of this procedure white is ‘no’ risk.

It is difficult to provide a definitive list of incidents by level as each case varies depending on the circumstances, including containment and recovery, which may reduce or escalate the level at any given point. An initial incident rating will be awarded upon incident notification and may change once the facts and impact of risks has been determined.

Generally the less serious incidents will involve encrypted data or low level data including near misses whereby the severity is reduced due to fortunate events. The more serious incidents will involve high level data which pose actual or potential risk for e.g. through the loss or release of highly sensitive personal or confidential business information.

7 NOTIFICATIONS

Aside from the initial reporting mentioned above internal notifications will be determined in accordance with the incident rating as set out in Appendix A.

It is important to notify key senior staff of the more serious incidents. Human Resources should be notified in the event of disregard for policy or Facilities Management in the event of building security. All incidents involving health and social care data must be reported to the relevant Caldicott Guardian.
Any incidents categorised as medium or high risk may amount to a ‘serious’ breach under the Data Protection Act 1998 and require notification to the Information Commissioner’s Office (ICO) or, where public health or adult social care data is involved the incident may amount to a ‘serious’ incident requiring investigation (SIRI) and require notification to the Department of Health (DoH) using the HSCIC IG Toolkit.

The Incident Lead (or Group Member) will provide advice on any other notifications as appropriate for e.g. affected people or stakeholders. Monitoring Officer approval will be will be sought in relation to any incidents requiring notification to a regulator.

8 INCIDENT MANAGEMENT

An incident flowchart can be found in Appendix B.

Stage 1: Incident Notification

• Any actual or suspected incident must be promptly reported within 24 hours using the incident reporting procedure.
• The incident reporting form requires the notifying officer to provide key details of the incident including what happened, when it occurred, what information or assets were compromised, number of people affected and any immediate action taken.
• Once the incident reporting form or notification via the ICT Service Desk is received then it will be logged centrally by the Incident Lead (or Group Member).

Stage 2 – Incident Assessment

• The severity of an incident will be determined by the incident rating.
• Upon notification, an initial assessment of risk will be undertaken by the Incident Lead (or Group Member) to determine a provisional incident rating and appropriate internal notifications will be made as per the applicable rating.
• Where incidents are rated as medium or high-risk consideration shall be given to notifying the ICO or DoH (for public health and adult social care data using the HSCIC IG Toolkit assessment tool as an initial assessment within 24 hours and within 3-5 days subject always to Monitoring Officer approval.
• An incident rating may change once the full facts and impact of risks has been determined and the status of the incident will be kept under review accordingly.

Stage 3 – Incident Investigation

• Not all incidents will require an in-depth investigation to establish the facts and determine what went wrong.
• The level of detail required in section 1 of the incident reporting form should be sufficient to resolve the incident.
• If any additional information is required then the Incident Lead (or Group Member) will contact the notifying officer or any other persons involved in the incident to seek clarification or further information.
• Any incidents rated as medium or high risk may require a full-scale investigation in which case the relevant Head of Service will be asked to assign a senior manager to investigate the incident and terms of reference will be agreed by the Incident Lead (or Group Member).
• The investigation should be completed and returned within 72 hours.

Stage 4 – Incident Review

• The completed incident reporting form and any additional information or investigation report will be reviewed by the Incident Lead (or Group Member).
• A final incident report will be produced within 5-10 days setting out (i) observations and conclusions about any information governance non-compliance issues, risks, adverse consequences or implications; and (ii) remedial recommendations to mitigate the risks and impact including preventative measures to address areas for improvement and training needs.
• Any repeat or previous similar incidents will be flagged in the final incident report and may result in additional or escalated action.
• This procedure is independent of a locally commissioned disciplinary investigation but the final incident report may inform any consequential action taken or considered.

Stage 5 – Incident Resolution

• The final incident report will be sent to the relevant Head of Service to sign off and accept the recommendations by appointing a responsible officer and target dates for implementation.
• It will also be shared with other key staff or specialist units in accordance with the incident rating.
• The signed report should be returned within 1 week.
• If for any reason a recommendation is rejected then the Head of Service must specify the reasons why. The Incident Lead (or Group Member) may escalate the matter in order to enforce implementation.

Stage 6 – Incident Monitoring & Closure

• The responsible officer will be required to update a monitoring log for the relevant Service to indicate when recommended action has been implemented by completing the ‘actions taken’ and ‘date action complete’ fields.
• HR and Facilities Management will be required to feedback any action taken following disciplinary investigations and facilities or building security checks.
• The Incident Lead shall report to the Information Governance Steering Group (IGSG) with any recommendations for changes to corporate policies, procedures and training including lessons learnt, and shall provide quarterly incident data to Heads of Service and IGSG Representatives.
• An incident will only be closed when all aspects including the monitoring log updates have been completed.

Note:

The Incident Lead (or Group Member) may become involved in an incident at any stage if the investigation is not proceeding to a satisfactory outcome, and the matter may be escalated to Strategic Director/SIRO/Monitoring Officer if the procedure is not being followed or making adequate progress.

APPENDIX A – INCIDENT LEVELS

Key:

• ICT-SD: ICT Service Desk
• IG: Incident Group
• HS: Head of Service
• HR: Human Resources Advisory
• FM: Facilities Management
• CG(s): Caldicott Guardians for Health or Social Care
• SD: Strategic Director
• SIRO: Senior Information Risk Owner
• MO: Monitoring Officer

APPENDIX B – INCIDENT FLOWCHART

APPENDIX C – INCIDENT GROUP TERMS OF REFERENCE

A HIRETT ‘Incident Group’ will set out a standard procedure for dealing with information security incidents and the reporting and escalation of such events.

All information security incidents will be dealt with by the Incident Group, which comprises of lawyers from the Council’s Corporate Legal Service (Group Members) with a nominated Incident Lead, who will review and advise on incidents and make recommendations on appropriate follow up and corrective action. ICT security will implement any immediate infrastructure actions required.

Group Membership

Legal Services, Corporate & Commercial Team:

1. Solicitor (Incident Lead)
2. Legal Support (Group Member & Coordinator)
3. Senior Solicitor (Group Member)
4. Solicitor (Group Member)
5. Information Assets, ICT:
6. ICT Security (Group Member)

Terms of reference

• develop corporate and consistent response to information incidents;
• oversee, develop terms of reference for, incident investigations;
• offer guidance on data incidents and on best practice;
• make recommendations for remedial actions and improvements;
• link to HR for any possible disciplinary action;
• link to Caldicott Guardians for health or adult social care data;
• link to ICT Security or Information Management for any corrective action;
• link to Facilities Management for office security and CCTV;
• link to Risk and Assurance for corrective action and risk awareness;
• report to Senior Information Risk Owner and / or Monitoring Officer;
• report to Information Governance Steering Group;
• report to regulators as appropriate;
• monitor implementation of remedial actions and improvements;
• identify trends and areas for greater local or corporate focus.

APPENDIX D – CYBERSECURITY INCIDENT RESPONSE PROCEDURE

Identification

Potential cybersecurity incidents are investigated by the Information Assets Computer Emergency Response Team (CERT) using information from the following sources:

1. Contact from users: A user or system administrator of a computer system on the HIRETT network contacts Information Assets and reports indications that their system has been compromised.
2. Contact from external users: Users from remote sites contacts Information Assets CERT with reports that systems under their control have been compromised, and forensic analysis reveals that they had been used to launch attacks against systems on the HIRETT network.
3. Contact from external organisations: Incident reports/notifications from external security/notification organisations that indicate that a system under our control has been compromised and is launching attacks against systems external to the HIRETT network.
4. Trouble reports/passive monitoring: Complaints about network performance or routine network analysis reveal excessive or suspicious traffic originating from one or more computers on the HIRETT network.
5. Active network monitoring: Reports from Intrusion Detection Systems indicates inappropriate, incorrect, or anomalous activity.

Assessment

Once a potential problem has been identified, Information Assets CERT will analyse and attempt to confirm that it is the result of a security incident. This may include traffic flow recording, packet capture and/or contacting the user of the affected system(s).

This allows Information Assets CERT to determine the likelihood that a security incident has occurred and what level of threat it poses to the network as a whole. Occasionally, this process will result in very brief interruptions of network service, but Information Assets CERT will make every effort to minimize these.

Incidents can be broadly categorized as a:

1. Compromised computer is actively causing widespread problems affecting a number of networks or computers either at HIRETT or elsewhere.
2. Computer is transferring confidential and/or sensitive information to an unauthorized user.
3. Computer, critical to the business functions of HIRETT, is compromised but is not actively causing problems.
4. Violation is reported to Information Assets CERT via external organisations.
5. Computer is believed to be vulnerable to a known exploit.

Contain and Eradicate

Once a security incident has been positively identified, Information Assets CERT will act to isolate the affected machine(s). Compromised hosts are often the source of DoS attacks, which greatly degrade the performance of the HIRETT network, and can also be used as launching points for attacks against other systems, potentially opening the Council to legal liability. Consequently, Information Assets CERT must act to remedy security problems immediately.

In serious cases, Information Assets CERT may be required to work with the Police as directed by the Council.

Notification

In the case of a compromised computer that is actively causing widespread problems affecting networks or computers at HIRETT or elsewhere, Information Assets CERT will take immediate steps to disconnect the computer from the network, notifying and working with the user.

In the case of a computer which is compromised but not actively causing problems, Network staff will immediately notify the user and request that he/she disconnect it from the network.

In the case of a violation report from an external organisation, Information Assets CERT will disconnect the computer from the network, and request that the user explain their actions and/or allow Information Assets CERT to analyse the system.

Follow up

Once a computer has been disconnected from the network, it is then Information Assets’ responsibility to get the disks re-formatted and/or arrange reinstallation of software on the machine and take any other steps necessary to secure it from future attacks. This would depend on factors such as acquaintance with the system in use and whether it had been supplied and configured originally by I.A.
Once the computer is secured, it is the owner’s responsibility to contact Information Assets CERT, who will then allow it to be reconnected to the network. At this point, a security scan will be run to verify that the system has been sec0.ured. Results will be forwarded to the computer owner.

Refusal by the system’s owner to fully co-operate with requests from Information Assets CERT will be notified to their Head of Service and relevant Strategic Director.

The CERT Team

The CERT Team will be made up from representatives from all relevant areas that need to be involved; this will include (but not limited to):
1. The relevant Business Partner from Information Assets;
2. The Technical Security Team;
3. Relevant network personnel;
4. ICT Communications;
5. Senior representative to make strategic decisions efficiently;
6. Device Support/ICT Service Desk.

← Return to the Table of Contents for all EMI and API pages