Incident Response Policy

(ISP07)

2

Issue Date: December 2014 Version:3.0 DOCUMENT CONTROL ............................................................................................................................................3

1 POLICY STATEMENT ............................................................................................................................................4

2 POLICY AND PROCEDURE ..................................................................................................................................4

3 INCIDENT DEFINITIONS........................................................................................................................................5

3.1 UNAUTHORISED ACCESS...............................................................................................................................5 3.2 UNAUTHORISED ACQUISITION......................................................................................................................5 3.3 SEVERITY AND CRITICALITY..........................................................................................................................6

4 INCIDENT RESPONSE TEAM…………..................................................................................................................6

4.1 TEAM OBJECTIVES..........................................................................................................................................6 4.2 INCIDENT RESPONSE TEAM STRUCTURE...................................................................................................6 4.2.1 PRIMARY TEAM ............................................................................................................................................7 4.2.2 SECONDARY TEAM.......................................................................................................................................7 4.2.3 REPORTING A SECURITY INCIDENT..........................................................................................................7 4.2.4 ACTIVATION OF TEAM..................................................................................................................................7

5 KEY COMPONENTS OF INCIDENT RESPONSE PROTOCOL.............................................................................8

5.1 ASSESSMENT...................................................................................................................................................8 5.2 NOTIFICATION/COMMUNICATION..................................................................................................................8 5.2.1 INTERNAL COMMUNICATION (WITHIN THE COLLEGE)............................................................................8 5.2.2 EXTERNAL COMMUNICATION (OUTSIDE THE COLLEGE.........................................................................8 5.2.3 CUSTOMER/USER/CLIENT NOTIFICATION.................................................................................................9 5.2.4 INCIDENT STATUS........................................................................................................................................9 5.3 CONTAINMENT.................................................................................................................................................9 5.4 CORRECTIVE MEASURES...............................................................................................................................9 5.5 CLOSURE..........................................................................................................................................................9

6 POST-INCIDENT REVIEW....................................................................................................................................10

GLOSSARY..............................................................................................................................................................11

APPENDICES...........................................................................................................................................................12

A – PROCESS FLOW............................................................................................................................................13

B – INCIDENT SEVERITY AND CRITICALITY LEVEL.........................................................................................14

C – PRIMARY AND ALTERNATIVE CONTRACT LIST........................................................................................15

D – NOTIFICATION TREE………………………………........................................................................................16

E – GUIDELINES FOR LISD IT HELPESK……………........................................................................................17

F – INCIDENT ASSESSMENT CHECKLIST.........................................................................................................19

G – INCIDENT CONTAINMENT ACTIVITIES…………........................................................................................21

3

Document Control

Policy Version:-

3.0

Policy Review Interval:-

Annually by Information Security Group from the date of authorisation

Author:-

Director of LISD

Authorised By:- ISG Group Members:-

Information Security Group Director of Estates (Chairperson) Head of IT Infrastructure Services Director of Library and Information Services Division LISD IT and Development Manager

Authorisation Date:-

December 2014

4

1 Policy Statement

A rapid response to incidents that threaten the confidentiality, integrity, and availability (CIA) of College information assets, information systems and the networks that deliver the information is required to protect those assets. Without a rapid response, those assets could be compromised and the College could be in breach of UK Legislation, JANET acceptable use policy and our own stated policies. Information Security incidents will occur that require full participation of Information Services Division and IT Infrastructure Services personnel as well as management leadership to properly manage the outcome. To accomplish this, an incident response policy is necessary to articulate the procedures necessary to ensure appropriate leadership and technical resources are involved to: o assess the seriousness of an incident o assess the extent of damage o identify the vulnerability created o estimate what resources are required to mitigate the incident It will also ensure that proper follow‐up reporting occurs and that procedures are adjusted to reflect lessons learnt to improve responses to future incidents.

2 Policy and Procedures

This Policy and associated procedures necessitate the establishment and on-going deployment of an incident response team, formed with the purpose of managing information security incidents at the College. This effort is undertaken to improve the response time to incidents, to provide consistentcy of response and to improve incident reporting. The purpose of the Information Security Incident Response Procedure is to establish procedures in accordance with applicable legal and regulatory requirements and College policy to address instances of unauthorised access to or disclosure of College Information, to be known as an Incident. This policy applies to IT Information Systems and Services for which it is responsible. These policies and procedures specifically exclude the following: o Non‐electronic information including paper mail.

o Copier and fax.

o Physical security.

o Contingency Planning, Business Continuity and Disaster Recovery are governed by a different set of

policies. An event may initially be declared an ‘Information Security Incident’ and subsequently

declared to be a ‘Disaster’ by the appropriate body. In this case, an Incident Response Team (IRT)

would be included into the Disaster Recovery process and, if necessary, the Business Continuity Plan.

In addition to all the defences that have been installedin protection of the infrastructure and the information processed within, conventional wisdom recommends a high level of preparedness for an information security incident. This policy and procedures describes the response to such events, the conditions whereby this process is invoked, the resources required and the course of recommended action. Central to this process is the Incident Response Team, assembled with the purpose of addressing that particular circumstance where there is credible evidence of an incident. See “Appendix A Process Flow –” for a graphical representation of the information flow and decision process.

5

3 Incident Definitions

An Information Security Incident is generally defined as any known or highly suspected circumstance that results in an actual or possible unauthorised release of information deemed sensitive by the College or subject to regulation or legislation, beyond the College’s sphere of control. Examples of an Information Security Incident may include but are not limited to:

o the theft or physical loss of computer equipment known to hold files containing financial/confidential

details

o a server known to hold sensitive data is accessed or otherwise compromised by an unauthorised party

o an outside entity is subjected to a Distributed Denial of Service (DDoS) attack originating from within

or outside the College network

o a firewall is accessed by an unauthorised entity

o a network outage is attributed to the activities of an unauthorised entity

3.1 Unauthorised Access

Characteristics of security incidents where unauthorised access might have occurred include but are not limited to: o Evidence (e‐mail, system log) of disclosure of sensitive data

o JANET alerts

o Unexpected changes in resource usage

o Increased response time

o System slowdown or failure

o Changes in default or user‐defined settings

o Unexplained or unexpected use of system resources

o Unusual activities appearing in system or audit logs

o Changes to or appearance of new system files

o Regular user lock out

o Appliance or equipment failure

o Unexpected enabling or activation of services or ports

o Protective mechanisms disabled (firewall, anti‐virus)

3.2 Unauthorised Acquisition

Characteristics of security incidents where unauthorised acquisition might have occurred include but are not limited to: o Theft of computer equipment where sensitive data is stored

o Loss of storage media (CD‐Rom, DVD, flash drive, magnetic tape) Illegal entry (burglary)

o Suspicious or foreign hardware is connected to the network

o Normally‐secured storage areas found unsecured

o Broken or non‐functioning locking mechanisms of storage areas

o Presence of unauthorised personnel in secured areas

6

3.3 Severity and Criticality

Incidents are further defined by the actual and potential impact on the business of the College. For additional information on severity assignments and associated symptoms, see“Appendix B Incident Severity and Criticality Levels,”. The primary focus of this policy is the handling of Severity 1 ‘S1’ incidents.

4 Incident Response Team

The Incident Response Team (IRT) is comprised of individuals with decision‐making authority from within Information Services Division, IT Infrastructure Services and chaired by the Director of Estates with the responsibility of assisting in the process described within this document.

4.1 Team Objectives

The Information Response Team Chair (Director of Estates) or delegated Incident Manager (IM) will lead the Incident Response Team; the objective is to:

o Coordinate and oversee the response to Incidents in accordance with the requirements of UK

Legislation, JANET and College policy

o Minimise the potential negative impact to the College, Customers and 3rd Parties as a result of such

Incidents

o Where appropriate, inform the affected Customer and 3rd Party of action that is recommended or

required on their behalf

o Restore services to a normal and secure state of operation

o Provide clear and timely communication to all interested parties

To ensure an appropriate and timely execution of this protocol, the Incident Response Team Chair (or designated Incident Manager) is required to:

1. Confirm the occurrence of an Information Security Incident requiring the execution of this protocol.

2. Confirmation activities include but are not limited to:

o Examination or analysis of irregularities

o Review of system logs or audit records

o Direct conversation with Customer, 3rd Party, Service Desk, ISD or ITIS personnel, “on call”

engineer, IRT members or others having information about the event collection of any evidence

supportive of the event

o Supervise and direct the consistent, timely, and appropriate response to an Information Security

Incident

o Provide appropriate communication to parties having a vested interest in the incident

o Offer support to the Customer or 3rd Party as appropriate until the Incident is resolved

o Conduct a Post‐Incident Review

o Maintain the procedures contained in this document

4.2 Incident Response Team Structure

The IRT consists of a Primary Team and if deemed necessary a Secondary Team. Each member of the Primary Team will designate an Alternate member to participate if the Primary Member is unavailable. See Appendix C “Primary and Alternate Contact List” for a listing of individual members. The Primary Team will consist of representatives from the following areas:

7

4.2.1 Primary Team

o Director of Estates (Chair) o Director of Library and Information Services o LISD IT and Development Manager o Head of IT Infrastructure Services o LISD Customer Services Manager (Hawkshead) o LISD Customer Services Manager (Camden)

4.2.2 Secondary Team

The circumstances surrounding each incident may differ and require personnel with expertise or skills beyond that of the Primary Team. Members of the Primary Team will determine what, if any, additional resources are required and a Secondary Team may be established with:

o Individuals with decision‐making authority identified to have a vested interest in the resolution of the

incident.

o Individuals identified as subject matter experts or having skills required for resolution of the incident.

4.2.3 Reporting a Security Incident

Anyone receiving notification of an Incident must contact the Information Services Division immediately. ISD personnel will provide the customer and the user with a Single Point of Contact (SPOC). The ISD own the Incident Management Process and as such will be responsible for monitoring and escalation according to all SLA’s o The e‐mail addresses is helpdesk@rvc.ac.uk Note: The email address may be used but is less effective than the direct notification to the Information Services Division via the telephone. o Telephone Ext: 5181 o Direct Dial from outside the College 0207 468 5181

4.2.4 Activation of Team

Once the Incident Response Team Chair has determined an Information Security Incident has occurred, the Chair or delegated IRT Incident Manager will activate this protocol within 24 hours after Incident determination. Notification to the Primary Team member or alternate should occur via a direct communication by telephone or face‐to‐face contact. Voice‐mail and e‐mail are not considered direct notification. Respective Primary and alternate Team members should exchange information frequently to ensure their knowledge of the information security incident is current.

5 Key Components of Incident Response Protocol

The Incident Response Protocol consists of four key components: 1. Assessment 2. Notification/Communication 3. Containment, 4. Corrective Measures 5. Closure

8

5.1 Assessment

The Incident Response Team Chair or IRT Incident Manager will determine the category and severity of the Incident and undertake discussions and activities to best determine the next best course of action, i.e., decide if protocol execution is required. Once the IRT is assembled, the Assessment Checklist is executed and reviewed to ensure all relevant facts are established. All discussions, decisions and activities are to be documented.

See “Appendix E – Guidelines for LISD IT Helpdesk” for more detail.

5.2 Notification/Communication

Designated persons will take action to notify the appropriate internal and external parties, as necessary. See “Appendix D – Notification Tree”.

5.2.1 Internal Communication (Within the College)

All Internal Notification and communication must be approved by the Primary IRT Chair or IRT Incident Manager.

Primary Team members notify Alternate Team members (and vice‐versa). The IRT will notify members of Secondary Team (if assembled).

1. IRT Chair will notify College Senior Management as necessary and provide on-going status.

2. IRT Chair will issue or direct all “sensitive” internal communications.

3. The Director of LISD or nominated representative will issue all public internal communication, MoTD

etc.

5.2.2 External Communication (Outside the College)

All External Notification and communication must be approved by SMG or nominated representative.

o 3rd Party ‐ IRT Chair or IRT Incident Manager and/or the COO will establish communication with any

3rd Party, as appropriate for the circumstance.

o Law Enforcement ‐ HR in consultation with IRT Chair or IRT Incident Manager to notify Law

Enforcement as appropriate.

o Regulatory ‐ IRT Chair or COO notifies the appropriate regulatory agencies.

o IRT members will assist in determining if other parties should be notified.

o Media Interest ‐ COO and HR will determine if, how and when media interest should be notified, and

respond to all inquiries from the media.

o Other affected parties – The IRT will determine if there are other parties of interest, with

communications issued accordingly (e.g., JANET)

5.2.3 Customer/User/Client Notification

o The Customers should be informed that the Incident has been reported, recorded and an

investigation underway.

o The Customer shall be kept abreast of the status of the Incident investigation in a timely manner.

o The Customer shall be notified of results, closure of investigation, and recommendations.

5.2.4 Incident Status

o IRT Chair assumes responsibility for preparing and issuing timely communication to IRT members,

Administration and other interested parties.

9

o Communications may include meetings, video conferencing, teleconferencing, e‐mail,

telephone/messaging, voice recordings or other means as deemed appropriate.

o Frequency and timeliness of communications will be established and revised throughout the life

cycle of the incident.

5.3 Containment

The IRT will determine and cause to be executed the appropriate activities and processes required to quickly contain and minimise the immediate impact to the College, Customer and 3rd Party. Containment activities are designed with the primary objectives of:

o Counteract the immediate threat

o Prevent propagation or expansion of the incident

o Minimise actual and potential damage

o Restrict knowledge of the incident to authorised personnel

o Preserve information relevant to the incident

See “Appendix G – Incident Containment Activities” for more detail.

5.4 Corrective Measures

The IRT will determine and cause to be executed the appropriate activities and processes required to quickly restore circumstances to a normal (secure) state. Corrective measures are designed with the primary objectives of: o Secure the processing environment

o Restore the processing environment to its normal state

See “Appendix G – Incident Containment Activities” for more detail.

5.5 Closure

The IRT will stay actively engaged throughout the life cycle of the Information Security Incident to assess the progress/status of all containment and corrective measures and determine at what point the incident can be considered resolved. Recommendations for improvements to processes, policies, procedures, etc. will exist beyond the activities required for incident resolution and should not delay closing the Information Security Incident.

6 Post-Incident Review

A review of Information Security Incident‐related activities is a required element of this policy. All members of the IRT primary and secondary teams are recommended participants. Discussion The IRT Chair or IRT Incident Manager will host a Post-Incident Review after each Incident has been resolved; this discussion should be scheduled within 2‐3 weeks of the Information Security Incident’s remediation. The review is an examination of the Incident and all related activities and events. All activities performed relevant to the Incident should be reviewed with the aim of improving and honing the over‐all incident response process. Recommendations The IRT’s recommendations on changes to policy, process, safeguards, etc. are both an input to and by‐product of this review. “Fix the problem, not the blame” is the focus of this activity. All discussions,

10

recommendations and assignments are to be documented for distribution to the IRT and follow‐up by IRT Chair. Follow-up The IRT Chair will follow‐up with the Client and 3rd Party or other parties, as required and appropriate.

11

Glossary The following terms should be used to assure commonality of reporting:

Confidentiality. “Confidentiality provides the ability to ensure that the necessary level of security is enforced

at each junction of data processing and prevention of unauthorised disclosure. This level of

confidentiality should prevail while data resides on systems and devices within the network,

as it is transmitted, and once it reaches its destination.”

Integrity. “Integrity is upheld when the assurance of accuracy and reliability of information and

systems is provided, and unauthorised modification of data is prevented.”

Availability. “Systems and networks should provide adequate capacity in order to perform in a

predictable manner with an acceptable level of performance.”

Vulnerability. “Vulnerability is a software, hardware, or procedural weakness that may provide an

attacker the open door he is looking for to enter a computer or network and have

unauthorised access to resources within the environment. Vulnerability characterises the

absence or weakness of a safeguard that could be exploited”.

Threat. “A threat is any potential danger to information systems. The threat is that someone or

something will identify a specific vulnerability and use it against the organisation or

individual”. Harris 2003, p. 56.

Risk. “A risk is the likelihood of a threat agent taking advantage of vulnerability. A risk is the

possibility and probability that a threat agent will exploit vulnerability”.

Exposure. “An exposure is an instance of being exposed to losses from a threat agent. Vulnerability

can cause an organisation to be exposed to possible damages”.

Countermeasure. “A countermeasure, or safeguard, mitigates a potential risk. A countermeasure is a

software configuration, hardware, or procedure that eliminates vulnerability or reduces the

risk of a threat agent from being able to exploit vulnerability”.

12

Appendices

A – Process Flow

B – Incident Severity and Criticality Level

C – Primary and Alternative Contact List

D – Notification Tree

E – Guidelines for LISD IT Helpdesk

F – Incident Assessment Checklist

G – Incident Containment Activities

13

Appendix A – Process Flow

ITIS Report Incident

ISD IT Helpdesk Receives Incident Report

JANET/External Bodies Report Incident

Users/Client/Customers

Internal/External Report Incident

ISD IT Helpdesk Conducts analysis &

assigns Incident number

Does this problem meet criteria of Incident?

YES

NO ISD IT Helpdesk team follows normal problem

procedure and resolution

ISD IT Helpdesk notifies member of IRT or available ITIS staff

Does this problem meet

criteria of Incident?

YES

NO ISD IT Helpdesk team notified of non-incident

IRT member or ITIS staff contacts IRT

Incident Manager

IRT Incident Manager reviews incident, consults

& decide on execution

YES

IRT Chair notifies IRT and ITIS staff.

Protocol is Executed

NO ISD IT Helpdesk team

and ITIS staff notified of non-incident

14

Appendix B – Incident Severity and Criticality Level

Incident Category Sensitivity* Description

Denial of service S1 o DoS or Distributed DoS attack.

Compromised Information S1 o Attempted or successful destruction, corruption, or

disclosure of sensitive College information or Intellectual Property.

Compromised Asset S1, S2 o Compromised host (root account, Trojan, rootkit), network

device, application, user account. This includes malware‐infected hosts where an attacker is actively controlling the host.

Unlawful activity S1 o Theft / Fraud / Human Safety / Child Pornography. Computer‐related incidents of a criminal nature, likely involving law enforcement or Loss Prevention.

Internal Hacking S1, S2, S3 o Reconnaissance or Suspicious activity originating from inside the College network, excluding malware.

External Hacking S1, S2, S3 o Reconnaissance or Suspicious Activity originating from outside the College network (partner network, Internet), excluding malware.

Malware S3 o A virus or worm typically affecting multiple College devices.

This does not include compromised hosts that are being actively controlled by an attacker via a backdoor or Trojan. (See Compromised Asset)

Email S3 o Spoofed email, SPAM, and other email security‐related events.

Forensics S1 o Any forensic work to be done by IRT.

Policy Breaches S1, S2, S3

o Sharing offensive material, sharing/possession of copyright material.

o Deliberate violation of Information Security policy. o Inappropriate use of College asset such as computer,

network, or application. o Unauthorised escalation of privileges or deliberate attempt to

subvert access controls. * Sensitivity will vary depending on circumstances.

Incident Sensitivity Classification

Sensitivity Level

Sensitivity Level Definition

Typical Incident Categories Required On Case Communications **

S1 Extremely Sensitive

Global Investigations Initiated Forensics Request Destruction of property Compromised asset Compromised Information Unlawful activity Inappropriate use of property Policy violations

IRT Chair or IRT Incident Manager or ISD IT Helpdesk

S2 Sensitive External Hacking Internal Hacking Unauthorised Access

IRT Chair or IRT Incident Manager or ISD IT Helpdesk

S3 Not Sensitive Denial of service Virus / Worm Email

IRT Chair or IRT Incident Manager or ISD IT Helpdesk SPOC

Appendix C – Primary and Alternative Contact List

15

Primary Contact List

Job Title Full Name Email Address

Director of Estates Alasdair Esson aesson@rvc.ac.uk

Director of Library and Information Services Division

Simon Jackson sjackson@rvc.ac.uk

Head of IT Information Services Farukh Zeeshan fzeeshan@rvc.ac.uk

LISD IT and Development Manager Dan Messum dmessum@rvc.ac.uk

LISD Customer Services Manager (Hawkshead)

Sally Burton sburton@rvc.ac.uk

LISD Customer Services Manager (Camden)

Gwyn Jervis gjervis@rvc.ac.uk

Alternative Contact List

Job Title Full Name Email Address

Deputy Director of Estates Richard Cartwright rcartwright@rvc.ac.uk

LISD Project Manager John Sumner jsumner@rvc.ac.uk

IT Infrastructure Engineer Rees Gates rgates@rvc.ac.uk

IT Infrastructure Systems Engineer David Maruta dmaruta@rvc.ac.uk

Information Services Division - IT Helpdesk helpdesk@rvc.ac.uk – ex 5181

+44 207 468 5181

16

Appendix D – Notification Tree

ISD IT Helpdesk Owns the Incident

If problem meets criteria of Incident – ISD IT Helpdesk notifies Primary IRT

IRT Chair informs ISG - Also Director of Estates if major incident

Director of Estates

Information Security Group

Incident Manager is appointed by the IRT Chair. IM contacts engineers for

incident resolution.

IRT Chair provides frequent incident updates to affected user or group.

Affected user or group/department

Incident Manager confirms resolution to IRT Chair – IRT Chair informs ISG

Information Security Group

HR / Registry

Head of Departments

17

Appendix E – Guidelines for LISD IT Helpdesk

When a problem is reported to the Helpdesk which suggests that a possible security breach may have taken place, the following steps should be taken:

1) Determine if the incident that has occurred does have any security implications 2) Establish available facts 3) Record details 4) Forward to responsible parties

1) Determine if the incident that has occurred does have any security implications Examples of problems that should be treated as ‘security incidents’ are those that involve either unauthorised access or unauthorised acquisition relating to the RVC network or RVC owned hardware or software. Including but not limited to:

o Reports of virus infections o Spam originating from RVC email accounts o Changes in default or user‐defined settings o Unexplained or unexpected use of system resources o Changes to or appearance of new system files o Regular user lock out o Unexpected enabling or activation of services or ports o Protective mechanisms disabled (firewall, anti‐virus) o Theft of computer equipment where sensitive data is stored o Loss of storage media (CD‐Rom, DVD, flash drive, magnetic tape) Illegal entry (burglary) o Suspicious or foreign hardware is connected to the network o Normally‐secured storage areas found unsecured o Broken or non‐functioning locking mechanisms o Presence of unauthorised personnel in secured areas

2) Establish available facts No set of questions will address every circumstance; previous experience with an individual or department may also be relied on to help determine if a security incident has occurred. Examples of useful questions to ask in order to establish if a breach of security has occurred may be:

o Were network account details and/or passwords accessed or released? o Were banking details or other financial information disclosed? o Were personal details such as medical information disclosed? o Were RVC client records accessed? o Was any research data compromised? o Did physical theft of computer equipment or storage media occur? o Did unauthorized use of the network take place?

3) Record details Helpdesk should record details of the incident on the TraceOn Helpdesk system in the normal way in order to establish a record as early as possible:

o Obtain and record the contact information for the individual reporting the problem (name, telephone numbers, email address)

o Record relevant information about the incident (e.g., time/date of suspected occurrence, type of information compromised, location of the compromise)

o Inform the individual to expect contact from a member of the Incident Response Team o Request the individual to treat the incident as a confidential matter o Contact a member of the IRT team for further assistance (out of hours if necessary, the NorMAN

service also having been supplied with contact numbers).

4) Inform a member of the Incident Response Team (IRT)

18

Having established the initial circumstances and people involved with the issue, Helpdesk staff who regard any problem as having security implications should contact one of the following: Director of LISD, IT & Development Manager, Customer Services Managers, LISD Project Manager, Director or Deputy Director of Estates.

19

Appendix F – Incident Assessment Checklist

Once the information which has been initially gathered is received, the following checklists should be carried out to make a full assessment of the incident: 1. Description Of Incident Relevant Information should be collected for use in determining incident level and the escalation required. 1.0 Record the current date and time. 1.1. Provide a brief description of the Incident. 1.2 Who discovered the Incident? Provide name and contact information. 1.3. Indicate when the incident occurred and when it was discovered. 1.4. How was the Incident discovered? 1.5. Describe the evidence that substantiates or corroborates the Incident (e.g., eye‐witness, time stamped logs, screenshots, video footage, hardcopy, etc.). 1.6. Identify all known parties with knowledge of the Incident as of current date and time. 1.7. Inform all parties with knowledge of the Incident to treat information as “sensitive or confidential” 2. Types Of Information, Systems And Media Provide information on the nature of data involved in the incident 2.0. Provide details on the nature of the data (e.g., student information, research data, personnel information etc.). 2.1. Does the information (if compromised) constitute a breach of of regulatory requirements (e.g., Data Protection or College IT User policy? Describe what is known. 2.2. Was the compromised information maintained by a College Client or a third party? Provide details. 2.3. How was the information held? Identify the types of information systems and/or the media on which the information was stored (e.g., hardcopy, laptop, CD‐Rom, etc.). 2.4. If the information was held electronically, was the data encrypted or otherwise disguised or protected (e.g., redacted, partial strings, password required, etc.)? If so, describe measures taken. 2.5. If a customer held the information:

o Establish the customer point of contact. (e.g. JANET ) o Assign responsibility to IRT member to contact the customer.

2.6. If a third party held the information:

o Identify the individual within the College who best represents the third party. If there is no suitable College contact, an IRT member will be assigned responsibility for directly contacting the third party.

o Assign responsibility to IRT member to contact that individual. o IRT member will work with the University contact or third party to obtain a copy of any contract or

confidentiality agreement and ascertain what knowledge of the Incident the third party might have and what action if any has been taken.

2.7 Who currently holds evidence of the Incident? Provide name and contact information. 2.8 What steps are required or being taken to preserve evidence of the Incident? Describe. 3. Risk/Exposure Attempt to determine the extent of risk or exposure presented by the incident 3.0. Can we reasonably determine the risk or exposure? 3.1. To what degree are we certain that the data has or has not been released? 3.2. Do we have contact with someone who has “firsthand” knowledge of the circumstance (e.g., the owner of a stolen laptop)? Provide name and contact information. 3.3. What firsthand knowledge have we determined? Describe what is known. 3.4. Can we identify and do we have contact with the party that received the data or caused the compromise? Describe what is known. 3.5. Identify the impacted parties, if possible. Are they College Customers or third parties? Provide estimated number, if known. 3.6. What is the risk or exposure to the College? Describe. 3.7. What is the risk or exposure to the Customer? Describe. 3.8. What is the risk or exposure to the third party? Describe. 3.9. Can we determine to what extent the media may know of this Incident? Describe.

20

4. Next Steps Establish what information or course of action is required to best address or further assess the incident. 4.0. Do we have enough information to establish the category and severity of the Incident (see RVC Incident Response Policy for levels and categories)?

• If “yes”, declare the Incident category and severity. • If “no”, describe what else might be required.

4.1. If additional data collection data is required, assign responsibility to IRT member for collection and reporting to IRT. 4.2. Is there any deadline or reporting requirement (self‐imposed or regulatory) we need to address? Provide details. 4.3. Based on current knowledge, do we require resources of the Secondary Team? If so, determine the makeup and assign responsibility for contact to IRT members. 4.4. What communications need to be established? Provide details. 4.5. Are there any immediate issues that have not been addressed? Describe. 4.6. Recap all work and responsibility assignments. 4.7. When do we meet again to follow‐up? Provide details. Notification/Communication checklist As soon as an assessment of the incident has been made by a member of the IRT, decisions should be taken on the notification and communication necessary to escalate the incident further within the IRT and/or to inform other interested parties. 1. Information Dissemination Relevant information should be passed whilst the incident is being resolved (but without risking exacerbating the initial problem or raising undue alarm). 1.0 Notify the rest of the IRT/IRT Chair to be aware of the incident? 1.1 Inform LISD Helpdesk or ITIS teams of interim advice and request that further reports are flagged? 1.2 Consider contacting supervisors or HoDs of any parties involved in the incident 1.3 Consider placing Messages of the Day or sending all staff/student emails advising of action that should

be taken (eg phishing scams etc.) 1.4 Update relevant parties whilst resolution of the incident progress 1.5 Distribute confirmation that the incident has been concluded Produce and distribute report and analysis into the incident with recommendations to avoid repetition

21

Appendix G – Incident Containment Activities

The IRT will determine and execute the appropriate activities and processes required to quickly contain and minimise the immediate impact on the RVC, its clients or associated third parties. Containment activities are designed with the primary objectives of: • Counteract the immediate threat • Prevent propagation or expansion of the incident • Minimise actual and potential damage • Restrict knowledge of the incident to authorised personnel • Preserve information relevant to the incident 1. Containment Activities Activities that may be necessary to contain the incident: 1.0. Disconnect the system or appliance from the network or access to other systems. 1.1. Suspend accounts of users involved (eg. hacked email accounts) 1.2 Isolate the affected IP address from the network. 1.3. Power off the equipment, if unable to otherwise isolate. 1.4. Disable the affected application(s). 1.5. Discontinue or disable remote access. 1.6. Stop services or close ports that are contributing to the incident. 1.7. Remove drives or media known or suspected to be compromised. 1.8. Where possible, capture and preserve system, appliance and application logs, network flows, drives and removable media for review. 1.9. Notify IRT of status and any action taken. Corrective measures checklists The IRT will determine and cause the execution of the appropriate activities and processes required to quickly restore circumstances to a normal secure state. Corrective measures are designed with the primary objectives of:

• Secure the computing environment • Restore the computing environment to its normalized state

Corrective Measures – Unauthorised Access Actions that may be required to return conditions to a normal and secure state in the event of unauthorized access: 1.0. Change passwords on all local user and administrator accounts or otherwise disable the accounts as appropriate. 1.1. Change passwords for all administrator accounts where the account uses the same password across multiple appliances or systems (servers, firewalls, routers). 1.2. Re image systems to a secure state. 1.3. Restore systems with data known to be of high integrity. 1.4. Apply OS and application patches and updates. 1.5. Modify access control lists as deemed appropriate. 1.6. Implement IP filtering as deemed appropriate. 1.7. Modify/implement firewall rule sets as deemed appropriate. 1.8. Ensure anti‐virus is enabled and current. 1.9. Make all personnel “security aware”. 1.10. Monitor/scan systems to ensure problems have been resolved. 1.11. Notify IRT of status and any action taken. Corrective Measures – Unauthorised Acquisition Actions that may be required to return conditions to a normal and secure state in the event of unauthorised acquisition: 2.0. Retrieve or restore assets where possible. 2.1. Store all sensitive materials in a secure manner (e.g., lockable cabinets or storage areas/container). 2.2. Install/replace locks and issue keys only to authorised personnel. 2.3. Restore security devices and/or apparatus to working condition. 2.4. Remove and retain unauthorised equipment from network/area. 2.5. Implement physical security devices and improvements (e.g., equipment cables, alarms) as deemed

22

appropriate. 2.6. Make all personnel “security aware”. 2.7. Notify IRT of status and any action taken.

Closure checklist The IRT should confirm that the secure computing environment has been restored before declaring the incident closed and moving on to considering any implications and the longer term actions needed to prevent reoccurrence. 1.0 Members of the IRT who are involved in the resolution should reach unanimous agreement that threat from the incident has been eliminated and the secure computing environment restored. 1.1 A log of the incident and steps taken in resolution should be produced and distributed IRT members (and in a major incident Security Group, ITSG and SMG if required). 1.2 A ‘lessons learned’ session should take place with discussion of the incident and its resolution conducted by IRT members and other interested parties.