Information Security Incident Procedure

(1)

NOT PROTECTIVELY MARKED

Information Security Incident Procedure

Document Type: Procedure

Parent Policy: Force Information Standards Policy (FISP) - 016/2.8 Document Owner: Head of Corporate Services

Department: Corporate Services

Document Writer: Head of Information Standards & Compliance Effective Date: 21/04/11 (last amended 9/11/2015)

Review Date: 09/11/17

Version Author Changes Ratification

1.1 Head of IS&C Minor change made 17/03/10. Contact IS&C.

Ratified on 6/12/09 at Change

Committee

1.2 Head of IS&C Amendments to take account of Force structure changes.

Change Committee 21/4/11

1.3 Head of IS&C Cosmetic changes to reflect transition from Police Authority to Police & Crime Commissioner

CIO

1.4 Head of IS&C Annual Review & changes to take account of Information Commissioner requirements regarding data loss. Procedure renamed to include the word ‘Information’ in its title.

CIO

1.5 Head of IS&C Changes to take account of PSNP Code of Connection IA requirements.

ISB 15/12/14

1.6 NPCC Office Minor amendments to reflect name change from ACPO to NPCC

03/08/2015

1.7 Head of IS&C Review. General minor updates.

(2)

NOT PROTECTIVELY MARKED 1. INTRODUCTION

1.1 The purpose of this procedure is to provide guidance concerning the management and reporting of information security incidents. This document underpins the Force Information Standards Policy (FISP) and should be read in conjunction with the FISP and other relevant legislation, national guidance and Force Policy. Please contact Information Standards & Compliance (IS&C) with any queries.

1.2 All Police Officers and Police staff, Special Constables, volunteers and staff of the Office of Police & Crime Commissioner (OPCC) users are required to comply with the requirements in this Procedure at all times, wherever they work, and take all reasonable steps to prevent the occurrence of information security incidents. Every member of North Wales Police (NWP) should be aware of what a security incident is in order to recognise when an actual or suspected breach of security has occurred, treat it seriously and follow the correct procedure.

1.3 Any Security Incident should be reported through the appropriate channels (see Section 4) as soon as possible, whether it has already occurred, is suspected or seems likely to happen.

1.4 It is also important to report any vulnerabilities (see Section 2.2).

2. WHAT IS A SECURITY INCIDENT?

2.1 A Security Incident is any suspected failure in information security, namely: -

a) Accidental or deliberate unauthorised destruction of information b) Accidental or deliberate modification of information

c) Accidental or deliberate unauthorised disclosure of information d) Deliberate and unauthorised non-availability of any system e) Unauthorised access to any system

f) Misuse of data

g) Theft or suspected theft of information assets (examples of an information asset: Laptop/Blackberry/Body Worn Camera/Airwave terminal/CD/DVD/USB memory stick or other USB

device/camera/digital voice recorder).

h) Loss or suspected loss of an information asset

i) Loss or suspected loss of information/data or inappropriate disclosure/disposal of data/information.

j) Major unplanned outages, malicious software, virus alert, use of unauthorised equipment

k) Any other event that affects data security, including the physical security of buildings.

(3)

2.2 N.B. Sometimes a security incident has not occurred but it may be noticed that a security incident has the potential to happen if a weakness in Force security is not addressed promptly – this is known as a “vulnerability” and should also be reported, as prevention is always better than cure.

2.3 IT systems are not the sole source of Security Incidents. Incidents fall into the categories of:

• Physical, • Technical, • Procedural or

• Personnel-related breaches.

Appendix D offers examples of each type; you may find it helpful to familiarise yourself with these.

2.4 Remember the information security incident may have occurred in an external organisation who may be a contractor/data processor to NWP or it may be an organisation to which NWP has legally disclosed NWP information e.g. Information Sharing Partners. It is important that, as soon as NWP are made aware of such an incident, that IS&C are notified along with the Dept which ‘owns’ the process/contract/ information sharing procedure.

2.5 Data Losses - the potential scope of information/data losses is wide: they can be accidental or deliberate; they can involve anything from a single item to millions of records; they can involve information with any of the Government Protective Marking Scheme (GPMS)/Government Security Classification(GSC) classifications; they can occur through information being lost in transit or inappropriately accessed or disclosed and they can result from technological failures or failures or non-compliance by people.

3. WHY REPORT A POTENTIAL OR ACTUAL SECURITY INCIDENT?

3.1 The main reasons for reporting incidents / vulnerabilities are to enable NWP to: -

• Take preventative measures

• Ensure that immediate and appropriate action is taken to contain the situation, reduce the impact and remedy the situation

• Learn from them and so prevent recurrence or development of the problem

• Protect its officers and staff • Protect its business.

(4)

3.2 Failure to protect our information could endanger the safety of colleagues, seriously impair our operational effectiveness or cause severe embarrassment or damage to the Force or to others.

4. WHAT SHOULD I DO IF I SUSPECT THAT A SECURITY INCIDENT HAS OCCURRED?

4.1 Data losses, security threats to NWP IT systems and NWP information, vulnerabilities in NWP information security measures are likely to come to the notice through an almost infinite number of routes, at any time of the day or night and at any time during the year. They could be small or catastrophically impactive.

4.2 It is important that you take immediate action. Where local procedures already exist, you should follow them e.g. system procedures, IT helpdesk, Facilities, Departmental procedures etc.

4.2 If there are no existing procedures in your Department, you should: -

1) Inform your supervisor of the incident immediately

2) If he/she is not available, contact the relevant departments e.g. ICT/IT helpdesk for IT issues, Facilities for physical security/damage issues etc.

3) Contact the Force Incident Manager (FIM), Force Communications Centre (FCC) if it is a serious incident which involves a potentially significant harm to Force interests.

4.3 Always inform IS&C, by emailing the mailbox as soon as reasonably practicable, or by telephoning if necessary. This is particularly important where an incident involves the Force’s Public Sector Network for Policing (PSNP) connection.

4.4 Informing the appropriate people is of great importance. The sooner we know the sooner we can do something about it. The Force also has the responsibility to inform other police forces/organisations about an incident which may affect them.

4.5 If warrant/ID cards or temporary staff visitor passes are lost or stolen, this must be reported to the line manager (or FCC out of office hours) as soon as possible after their disappearance is noticed. He/she will e-mail all internal e-mailboxes advising of the loss – the purpose is not to embarrass any individual but to increase the likelihood of the missing item being recovered. Recovery should be notified by the same means. If you become aware that someone is using a false ID, this is very serious and should be reported immediately.

(5)

NOT PROTECTIVELY MARKED 5. INCIDENT HANDLING

5.1 Handling a security incident can be categorised into the following stages: -

• Identification of the problem

• Notification (who should be notified about the incident)

• Logging (IS&C provide this service) and maintain a database of all incidents reported to IS&C.

• A Single Point of Contact (SPOC)/Data Loss Manager should be appointed; a lead person who co-ordinates and manages NWP’s response to an information security/data loss incident. This is often IS&C but can also be a person nominated within the relevant department, ICT, Chief Information Officer (CIO), PSD, FCC, relevant Information Asset Owner (IAO) or where necessary, the Senior Information Risk Owner (SIRO).

• Risk/Damage Assessment – this may be accomplished by one person (SPOC) or IS&C, or as part of a group, dependant on the nature of the incident/data loss. Appendix A contains points which will be helpful in making a risk/damage assessment.

• Investigation, Containment, Recovery. See Appendix B.

• If the incident concerns data loss, consideration of informing individuals that a data loss has occurred, plus consideration of informing the Information Commissioner, must take place. IS&C will lead on this aspect with the Head of IS&C making this decision at low and medium severity level. At high severity level the Head of IS&C will provide advice to the CIO, who will make the decision (see Appendix C for further information).

• Organisational Learning. IS&C review all incidents reported to them, for this purpose. Quarterly reports are also provided to the Information Security Board (ISB) chaired by the CIO. National statistical reporting is also provided to the Home Office by IS&C. • Eradication of the problem (how to eliminate the reasons for the

incident). IS&C consider this issue during their regular debrief sessions and will consult with ICT, CIO, IAOs & PSD where necessary.

• Protection of the system (what records should be kept from before, during, and after the incident)

• Recovery (how to re-establish the appropriate system of work)

• Follow-up analysis (what lessons can be learnt to prevent future occurrences).

5.2 People from various departments may need to be involved during the course of an active security incident. The handling of each incident should follow the same basic strategy: The following people may comprise the team although it will vary depending on the nature of the incident.

• IS&C often lead or deal with an incident, dependant on the circumstances and severity level. This is considered on a case by

(6)

case basis. On other occasions they will provide advice to and request updates from the SPOC/data loss manager or Gold Command when an incident warrants such attention.

• Departmental Heads or the relevant IAO may lead the team where there is a serious incident. Gold Command may also become involved (see Section 5.4).

• System Administrator – leads local enquiries with regard to their system.

• ICT – involved in all IT and Communications related matters. ICT will coordinate with IS&C in relation to any IT-related incidents and provide expert advice as required.

• Facilities – involved in all matters involving building maintenance / security and the provision of utilities.

• FCC – where all out of hours major incidents are initially reported to and on these occasions, where an analysis is made as to the next step.

• Corporate Communications – Responsible for dealing with any requests from the media regarding security incident information. Information relating to security incidents must not be released unless authorised by the CIO or an NPCC officer.

5.3 Each IAO/System Administrator/Departmental Manager must devise a procedure for the reporting, investigation and management of security incidents occurring within their area of responsibility. They must ensure that all users within their jurisdiction are aware of the procedure, understand their responsibilities under it and comply with it. They must

also ensure that Heads of Departments/IAOs or NPCC members are advised when this is deemed necessary (see Section 5.4).

5.4 In the event of a serious security incident, such as a major virus infection on the IT network, this must be notified to Gold Command

at the earliest possible opportunity, once the seriousness of the situation is apparent - NWP will also immediately inform the national

PSNP Security Manager, via PolWARP reporting, of all Security Incidents with a security severity level of ‘Major’ or ‘Emergency’. It may be necessary to consider disconnecting from the Public Sector Network for Policing (PSNP). Suitable advice will be provided to Gold Command to enable a speedy decision to be made. Decision-making at this level also allows consideration of disaster recovery and business continuity issues. If a decision to disconnect is made by an NPCC member, the Head of IS&C will report the disconnection and all users will be made aware of the situation. Subsequent consideration of reconnection when relevant issues have been sufficiently addressed will follow the same process. Relevant NWP personnel will also be required to participate in the national Joint Major Incident Team (JMIT) calls convened by the national PSNP Authority to diagnose and resolve Major Incidents involving NWP, and undertake any actions that have been assigned by the JMIT and accepted by NWP.

5.5 Any major incidents that the Force ICT Department or Managed Service Provider is unable to resolve within the service level agreement

(7)

(SLA), or which require the coordination of multiple parties or for which no owner is found should be escalated to the national PSNP Service Bridge via PolWARP reporting by IS&C or via ICT. NWP will also notify any Forces or other organisations with which NWP shares a PSNP Service of all relevant incidents that have been communicated to NWP by the Service Provider.

5.6 It is essential that robust business continuity and disaster recovery plans are in place to enable the continued operation of essential services in the event of disruption by a security incident. These plans must identify relevant roles & systems and should be tested at regular intervals. Staff must be made aware of these plans and should ensure that they understand their role in the event of an incident.

6. RECORDING INFORMATION

6.1 Logging of information is critical for all security incidents. The implications of a security incident are not always known when it occurs or as it is being managed, so a written log should be kept for all significant security incidents that are under investigation. The information should be logged, by the data loss manager, in a location that cannot be altered by others. The information logged should include: -

• Dates and times when incident-related events were discovered or occurred.

• Names of systems, programs or networks that have been affected. • Dates and times of incident-related phone calls

• People you have contacted or have contacted you. • Amount of time spent working on incident-related tasks. • Does it involve personal data?

6.2 This information should be compiled in a report to be submitted to IS&C in hard copy form or by e-mail to the Information Security Incidents Mailbox.

6.3 In addition, information collected as part of normal system monitoring activities must be collated and reviewed to identify long-term trends and any vulnerabilities to enable them to be addressed in a timely manner. Such reviews will be carried out by IAOs/local system administrators and ICT but the resulting reports will be provided to IS&C for further consideration in relation to any issues.

7. RISK/DAMAGE ASSESSMENT

7.1 An assessment of the actual or potential damage to Force property, systems, operations etc. must be carried out by the SPOC/Data Loss Manager or a suitably qualified person appointed by them. In the event of a serious incident involving potentially significant harm to Force

(8)

interests, the assessment must be submitted to the FCC for the attention of the FIM as soon as possible so that the implications can be considered quickly and an appropriate response formulated. Gold Command should also be made aware of any major issues in a timely fashion.

8. TAKING APPROPRIATE ACTION

8.1 It is very important to take appropriate action to contain or mitigate the effects of a security incident. For example, procedures should be in place for reporting software malfunctions which should include: -

• The symptoms of the problem and any message appearing on screen should be noted.

• The computer should be isolated, if possible, and use of it should be stopped. IT helpdesk should be informed immediately and if the equipment is to be examined, it should be disconnected from the network before being started up again – CDs/USB sticks should not be transferred to other computers.

• The matter should be reported to IS&C.

8.2 Under no circumstances should users attempt to test suspected weaknesses in the network or its component systems as it might be thought that they were deliberately misusing the system.

9. ENSURING A TIMELY RESPONSE

9.1 A computer security incident can occur at any time of the day or night. Time and distance considerations in responding to the incident are very important.

9.2 Departmental disaster recovery & business continuity plans must clearly identify relevant postholders to be contacted in the event of a security incident. This information will be made available to members of staff in the department and will also be provided to the FIM to enable a rapid response to any incident.

9.2 If the first person on the call list to be notified cannot respond within a reasonable time frame, then the backup person must be called in addition to the first. It will be the responsibility of the people on the call list to determine if they can respond within an acceptable time frame.

10. CRIMINAL OR DISCIPLINARY IMPLICATIONS

10.1 Where the Security Incident appears to involve possible criminal or disciplinary offences, the person receiving the report will ensure appropriate action is taken in accordance with the FISP.

(9)

11.1 After an incident has been dealt with fully and normal operation has resumed, a follow-up post-mortem analysis should be performed.

11.2 After informing IS&C initially, a detailed report about any major incidents must be collated by the SPOC/Data Loss Manager as soon as possible and within 3 weeks of the date of the occurrence. A copy must be sent to IS&C who will keep records of all Security Incidents and will advise on measures to be implemented to prevent future recurrences.

11.3 IS&C will also receive and analyse reports resulting from system or network activity reviews and monitoring e.g. anti-virus monitoring.

(10)

NOT PROTECTIVELY MARKED Appendix A

Risk/Damage Assessment

Risk/Damage Assessment – this may be accomplished by one person (SPOC) or IS&C, or as part of a group, dependant on the nature of the incident/data loss.

The content of the risk/damage assessment will depend on the type of incident. The following are a guide (see also Section 6):

1. What has occurred?

2. What IT system/information asset/data is involved?

3. Have the relevant people been notified e.g. IS&C, IAO, ICT.

4. What is the Protective Marking or sensitivity of the IT systems/information asset/data?

5. How many people or areas of business will it affect or have potential to affect? Will it affect members of the public e.g. website deface or loss of an individual’s personal data.

6. Has it or will it lead to a permanent or semi-permanent impact e.g. virus with no current anti-virus to apply.

7. Is it a criminal offence or potentially a criminal offence? E.g. unauthorised disclosure of information/modification of data/deliberate introduction of a virus.

8. Are there any protections in place e.g. encryption, antivirus, firewalls.

9. Can it be contained and the harm kept to a minimum?

(11)

Appendix B

Investigation, Containment, Recovery

1. The SPOC/data loss manager will need to consider if the information security incident requires investigation e.g. data loss or forensic investigation and balance that against the need to for example recover an IT system quickly.

2. Where necessary, a recovery plan needs to be put into place and damage limitation must be considered. This may require input from specialists across the Force e.g. IS&C, CIO, ICT, IAO, HR, PSD, Legal, Facilities.

3. Is there a need to advise Corporate Comms (wider public impact or adverse publicity/loss of public confidence in NWP, for example)?

(12)

NOT PROTECTIVELY MARKED Appendix C

1. There is no legal obligation to report data losses of any scale to the Information Commissioner. However NPCC’s (national) position is that police forces should comply with the Information Commissioner’s ‘Notification of Data Security Breaches to the ICO’ guidance, when a data loss occurs that results in a ‘serious breach’.

2. When the data loss does not result in a ‘serious breach; NPCC’s (national) policy is there is no need for it to be reported to the Information Commissioner.

3. Where a data loss has been voluntarily reported to the Information Commissioner, he/she will take this into consideration when deciding on the most appropriate course of action which could be:

- No further action

- A requirement on the data controller to undertake a course of action to prevent further data losses

- Formal enforcement action, turning such a requirement into a legal obligation

- Where there is evidence of a serious, deliberate or reckless breach of the Data Protection Act 1998, the serving of a monetary penalty on the Organisation up to the value of £500,000

4. There is no definition of a serious breach but factors to be considered are:

- The potential harm to data subjects

- The volume of personal data lost/released/corrupted

- The sensitivity of the data lost/released/unlawfully corrupted

- Potential harm to other individuals apart from the data subjects (person/s whose personal data it is) and the level of harm to policing

5. When a data loss is reported the Information Commissioner will be expected to be told:

- The type of information and number of records

(13)

- Action to be taken to minimise/mitigate the effect on individuals including whether they have been informed

- Whether any other regulatory body has been informed and their response

- Remedial action taken to prevent future occurrence

- Whether the media are award of the data loss so they can manage any increase enquiries from the public

- Any other information the force feels may assist the Information Commissioner in making an assessment (this could include proactive measures designed to reduce the risk of data loss occurring in the first place.

Be aware that when an incident is reported to the Information Commissioner, the Force are likely to receive a number of further searching questions about the incident, which will necessitate IS&C to liaise with the appointed SPOC to glean the answers for a NWP response.

6. On a quarterly basis each police force provides a statistical return to the Home Office on the numbers of incidents recorded. Each force is subsequently provided with an analysis of national trends. These statistics are reviewed by IS&C and reported on to the ISB to inform risk assessments.

(14)

NOT PROTECTIVELY MARKED Appendix D

Examples of security breaches

The following list is not exhaustive but it does provide a number of examples of security breaches and should provide a general guide to the type of circumstances that constitute a security incident.

Physical Technical Procedural Personnel

Examples • Theft/loss of warrant/ID cards, Blackberries, Airwave terminal, Body Worn

Cameras, USBs or laptops • Loss/theft of building access

fobs or IT tokens

• Unlocked doors, desks and filing cabinets when not in the office.

• Loss of Protectively Marked waste.

• Unlocked, unattended workstation

• “Shoulder-surfing” – where an unauthorised person looks over your shoulder whilst you are working on a workstation

• Tailgating where someone follows you into the building • Inadequate supervision of

• External alerts and briefings • Worms, viruses etc.

• Denial of service attacks • Hackers gaining access to

system and viewing, modifying or destroying information. • Sending sensitive information via inadequately secured media. • Introducing unauthorised software (including screensavers) onto NWP workstations and laptops.

• Compromise of your single user logon details (accidentally or deliberately), • Displaying sensitive operational information on noticeboards or computers in areas to which unauthorised

persons have access • Carrying out

unauthorised PNC checks for yourself or others

• Contravention of clear desk policy • Taking or sending

NWP information to a home computer.

• Discussing work information with family and friends. • Accessing

information where there is no “need to know”.

• Misuse of the email system. • Misdirected e-mail/letters leading to accidental disclosure of information. • Use of CD/DVDs from external sources in NWP machines without authorisation and thorough pre-use anti-virus checks.

(15)

visitors/inadequate identification/authority to gain access to premises. • Lost or stolen Airwave

terminals or mobile phones • Loss of data on USB sticks

or CDs

Leaving radios in unattended vehicles or having the volume loud enough to be overheard

• Storage of NWP data on non police issue CDs and other storage media.

N.B. Data Losses - the potential scope of data losses is wide: they can be accidental or deliberate; they can involve anything from a single item to millions of records; they can involve information with any of the Government Protective Marking Scheme (GPMS)/Government Security Classification(GSC) classifications; they can occur through information being lost in transit or inappropriately accessed or disclosed and they can result from technological failures or failures or non-compliance by people.