Definitions

Event

An event is any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending an email, and a firewall blocking a connection attempt.

Adverse events (Alerts)

Adverse events (alerts) are events with a negative consequence, such as system crashes, packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and the execution of malware that destroys data.

Machine or human analysis triggers Alerts, and those alerts can lead to security incidents.

Security Incident

A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

Examples of incidents are:

• An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash.
• Users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host.
• An attacker obtains sensitive data about the organization and threatens to release the details publicly if it does not pay a designated sum of money.
• A user provides or exposes sensitive information to others through peer-to-peer file-sharing services.

In the University of Toronto context, incidents may be violations of the Policy on Information Security and the Protection of Digital Assets, Policy on the Acceptable Use of Information and Communication Technology, other University policy, security standards, or code of conduct, or threatens the confidentiality, integrity, or availability (CIA) of Information Systems or Institutional Data.

Incidents are established from many vectors, including but not limited to:

• Monitoring systems,
• Reports from faculty, staff and students,
• Outside organizations,
• Service degradations or outages.

Discovered incidents shall be declared and appropriately documented. IT security-related incidents may also cause service outages.

Data

Data in the context of an incident is the data that has been or could have been accessed, exfiltrated, or publicly exposed due to the incident.  The data could reside on a compromised device or in another directly connected device or another device in the same network environment. 

The University of Toronto Data Classification Standard identifies four data levels and what data types are included in each level.

Depending on the type of data exposed, the University may be responsible for different notification levels to the government or private bodies.  These are the three primary Laws’ or agreements related to data that the University may need to report to are:

Personal Health Information Protection Act (PHIPA)

PHIPA is specific to health information and, in this context, the security of that data.

Freedom of Information and Protection of Privacy Act (FIPPA)

FIPPA is related to personal data, and many things can fall under its purview, including communications with students, UTORids, Employee records and research data.  IS and the FIPP office can help clarify what does or doesn’t fall under FIPPA as data is identified.

Payment Card Industry Data Security Standard (PCI DSS or PCI)

PCI is explicitly associated with credit card information and disclosure.  In particular, exposure of full credit card numbers and expiry dates or magnetic stripe data is of concern.

Overview of the Incident Response Process

Severity Ratings of Incidents

Categorization of Incidents is based on the potential for exposure of sensitive data or the resource’s criticality using a High-Medium-Low designation. The severity rating initially applied can be adjusted during the plan’s execution as identification of the scope and contents of the systems involved progresses.

Security Incidents – Severity Categories

High: 

Significant fines, penalties, regulatory action, civil or criminal violations could result from disclosure. It could also cause significant harm to Institutional Information, major impairment to the Location’s overall operation, or the impairment of essential service(s). This impact level also includes lower-level impact items that, when combined, represent an increased impact. A security incident is severity “high” if any of the following characteristics are present: 

1. Threatens to impact (or does impact) systems critical to the University’s ability to function normally. This includes but is not limited to email, courseware, human resources, financials, internet connectivity, or portions of the campus network.
2. It poses a serious threat of financial risk, reputational damage or legal liability.
3. Threatens to expose (or does expose) a significant amount of Level 3 or Level 4 data as defined by the Data Classification Standard.
4. Significant threat to propagate to or attack other networks or organizations internal or external to the University. 
5. Terroristic threats or other threats to human life or property.

Medium:        

Unauthorized use, access, disclosure, acquisition, modification, loss, or deletion could: (a) result in moderate damage to UofT, its students, employees, community or reputation; (b) result in moderate financial loss; or (c) require legal action. This impact level also includes lower-level impact items that, when combined, represent an increased impact. A security incident is severity “medium” if any of the following characteristics are present: 

1. Threatens to impact (or does impact) a significant number of systems or people. The University can still function, but a group, department, Unit, or building may not be able to perform its mission.
2. Systems impacted may contain any level of data as defined by the data classification standard; however, only a limited amount of Level 3 or Level 4 data.
3. Moderate threat to propagate to or attack other networks or organizations internal or external to the University.

Low:   

Unauthorized use, access, disclosure, acquisition, modification, loss or deletion could result in minor damage, small financial loss or affect the privacy of an individual or small group. Low severity incidents tend to have routine solutions and have no characteristics from the “medium” or “high” categories and may include the following: 

1. It impacts only a small number of people or systems.
2. Impacted systems contain a limited amount of only Level 1 or Level 2 data or a minimal amount of Level 3 data as defined by the data classification standard.
3. Little to no risk of the incident spreading or impacting other organizations or networks.

Computer Security Incident Response Team (CSIRT)

Given the federated nature of the University, there may be two main models to organize the incident response teams:

Unit Incident Response Team – Units need to have staff and resources identified to manage security incidents on behalf of that Unit. Among other things, they will perform analysis, investigation, and coordination of activities for the Unit to contain and remediate risks derived from security incidents.  They will act solely on behalf of a particular Unit and within the boundaries of their own Incident Response Plan. Unit Incident Response Team will be formed for most low severity incidents.

Institutional Computer Security Incident Response Team (CSIRT) - The CSIRT is a cross-functional team dedicated to managing security incidents on behalf of the University. It will coordinate various resources during the incident. The CISRT comprises members from both the affected Unit and institutional university departments. These are the people actively working on the incident and led by the incident manager. Among other things, they will perform analysis, investigation, and coordination of activities for multiple constituencies to contain and remediate risks derived from security incidents.

The CSIRT will be formed mostly to respond to medium and high-severity incidents. However, it may be called for resolution of non-routine low severity incidents as well.

As part of CSIRT, there are permanent and ad-hoc members who are engaged depending on the incident’s needs.

The CSIRT team will act on behalf of Units if they do not have an in-place incident response team structure within the Incident Response Plan’s boundaries.

CSIRT Activation

The following are the criteria for activation of the CSIRT

Severity	CSIRT Activation Criteria
High	There will always be a CSIRT associated with High Severity incidents
Medium	A CSIRT might be activated upon the request of the Chief Information Security Officer (CISO). It is discretionary, and it depends on the merit of the incident
Low	For low severity incidents, a CSIRT may be activated for non-routine incidents and upon the request of the Incident response team

 

CSIRT Membership

In general, the team comprises one or more members from the following types of staff depending on the severity of the incident:

Role	Function	Tenure	Responsibilities
Incident Manager	Management	Permanent	Coordinate incident response activities with internal and external stakeholders to the University and leads the Incident Response.
Associate Director, Information Security Operations (ISEA, IT&S)	Management	Ad-hoc (Mostly engaged on Medium/High Severity Incidents)	Point of escalation on security incidents. The Associate Director may assist the Incident Manager with communication efforts or other coordination activities.
CISO	Management	Ad-hoc (Mostly engaged on High Severity Incidents and certain kinds of medium severity incidents)	The CISO may provide authorization to disconnect critical and high visibility systems if they pose a significant reputational, financial or operational risk to the University.
Division/Department/Faculty Manager	Management	Permanent	Provides coordination of internal faculty resources to aid in the resolution of the incident.
Information Security	Investigator	Permanent	Conduct investigations on security incidents leveraging multiple detective and investigative tools.
Technical Subject Matter Experts (SME) familiar with the environment and applications	Investigator	Ad-hoc (Mostly engaged on Medium/High Severity Incidents)	Aids in containing, mitigating the impact of and recovering from the incident.   Collects evidence and relevant information to aid in the investigation.
Third-Party forensics firm staff	Investigator	Ad-hoc (Mostly engaged on High Severity Incidents)	Perform in-depth investigations on the cause of incidents, the extent of the compromise, the likelihood of data exfiltration, lateral movement or any other effects of cyber-attacks.
Divisional/Departmental/Faculty Information Security or IT	Investigator	Permanent	Provide necessary evidence in the investigation of security incidents. The team will also perform tasks required to mitigate the impact and risks related to the incident.
Campus Police	Legal	Ad-hoc (Mostly engaged on certain kinds of High Severity Incidents)	May be engaged at times to investigate security incidents and enforce the University of Toronto Student Code of Conduct
Freedom of Information and Protection of Privacy (FIPP)	Legal	Ad-hoc (Mostly engaged on High Severity Incidents and certain kinds of medium severity incidents)	Provides advice on protecting the privacy of students, staff and faculty of the University of Toronto and how to address breaches of their privacy.
Legal Counsel	Legal	Ad-hoc (Mostly engaged on High Severity Incidents and certain kinds of medium severity incidents)	Provide advice on legal obligations emanating from incidents that impact the University of Toronto.
Human Resources	Business	Ad-hoc (Mostly engaged on certain kinds of High Severity Incidents)	Provide advice on personnel matters arising from impacts of certain security incidents.
Communications	Business	Ad-hoc (Mostly engaged on certain kinds of High Severity Incidents)	Provide liaison and external communication services for incidents that may significantly impact the University’s reputation.
Applications or data owners	Business	Permanent	Provide business leadership and support in the resolution of security incidents impacting their respective applications or data.

The list above is not exhaustive and other members not listed may be added if they need to be involved or bring value to the investigation or response.

Meetings

An initial meeting of the CSIRT shall happen as quickly as possible. In all likelihood, this may happen before all the details about the incident are available but will ensure that everyone understands what is happening and what their role is.

Depending on the severity, daily meetings are typically better to ensures good communication and instills the sense of urgency needed to remediate the incident quickly. Working to people’s schedules is ideal; a Security incident takes priority over most things, so be aware you will not find perfect meeting times each day.  It is better to be consistent and schedule meetings where people can provide the best new information, typically late morning or afternoon.

Communication

Wherever possible, it is essential to keep all (or as much as possible) communication in one place.  Incident Response Teams shall set up private channels of conversation if the scope and severity warrant it where discussions about the incident and artifacts from the investigation can be kept in one place.  Launching meetings from this channel also ensures that information in the chat for those meetings also stays in the same place.

These procedures would need to work by bringing in each necessary key area and would also leverage more detailed response/work plans in each of those areas.

Additionally, officials from any area; Faculty, other divisions, departments, etc., affected by an incident would need to be fully involved.  This is not only as part of the response and possible remediation but also because of local leaders’ responsibility for these actions, the results of an incident, and because local leaders might likely control many resources necessary for responses.

Each key area would need to develop its own detailed response/work plan, as should each Division (at a minimum).

Divisions/Departments, etc., responsible for sensitive and/or extensive data holdings should have particularly well-developed plans, proportionate and responsive to the risk associated with the data holdings.

Procedures could comprise at least the following components, depending on the nature of the incident—first for incident response, then for subsequent steps, and each of these components would have several steps/parts:

• • Detection/reporting
  • Assessment
  • Containment
  • Documentation
  • Briefing Notification
  • Standards check/update
  • Remediation
  • Training
  • Process/system redesign
  • Assess the efficacy of remediation

Methodology

This plan outlines the most general tasks for Incident Response.  It will be supplemented by specific internal guidelines and procedures that describe the use of security tools and communication channels. These internal guidelines and procedures are subject to amendment as technology changes. It is assumed that these guidelines will be documented in detail and kept up-to-date.

Incident Response Process

In addition to documenting procedures, all Information Technology managers shall become familiarized with the incident response process to recognize and report incidents as quickly as possible. All faculty and staff are encouraged to report suspected information security incidents as quickly as possible.

Incident Management guidelines and supporting Incident Management (IM) toolkit is provided below:

• Toolkit - IM – Response Guide
• Toolkit - IM - Leadership Summary
• Toolkit - IM - Email Leadership Summary
• Toolkit - IM - Manager Activity Tracking Sample
• Toolkit - IM - Technical Investigation Report
• Toolkit - IM - Checklist of significant steps for Incident Response and Handling

Incident Identification

The Information Security department maintains and utilizes several tools that scan the University’s environment and network traffic, looking for threats. Depending on the severity of found threats or vulnerabilities, they may warn affected users, disconnect affected machines, or apply other mitigations.  In the absence of indications of sensitive data exposure, the information security department communicates vulnerabilities to the network/IP owner identified in the IPAM database (http://ipam.utoronto.ca/) and pursues available technology remedies to reduce that risk.

Additionally, the University at large may identify and report suspicious activities, adverse events, or running malicious code. The affected Unit may call an incident on their own or may work with Information Security to formalize the incident if required.

 

Containment of the incident and preservation of evidence

Where any data or other artifacts are collected in the investigation, it is imperative to retain those for forensic review and establish a chain of custody. This evidence might be used in litigation should it become necessary.

Communication Plan and Prioritization

All units shall make the first attempt in classifying incidents according to the severity matrix listed in previous sections of this plan. If incidents are deemed medium or high severity, they need to be reported to the Institutional Security Response Team ( security.response@utoronto.ca.) for awareness, assistance and/or escalation to the CISO. The Insititutional Team can also assist in the classification of the incident if required.

Incident Response teams shall document their guidelines for interactions with stakeholders regarding incidents and prioritize incidents with the highest severity level. During incident handling, the organization will need to communicate with multiple stakeholders. Because these communications often need to occur quickly, Incident Response teams shall predetermine communication guidelines.

The incident manager will typically have the responsibility to handle communications as part of the incident response  process. In case a CSIRT was established to handle a particular incident, the incident manager will prepare the communication in coordination with the team and target the appropriate audience. The workflow and table are below.

Incident Severity	Target Response Time*	Incident Manager	Who to notify?	Incident Reporting Required?
High	Immediate	IT Security Officer or Delegate	·      IT Security Officer ·      IT Administrator ·      Unit administrator ·      Unit Representative ·      CIO ·      CISO ·      Privacy Officer ·      Institutional Incident Response team ·      Others on a need-to-know basis	Yes (daily emails informing progress, formal incident report upon closure, lessons learned report)
Medium	4 hours	IT Security Officer or Incident Response Lead	·      IT Security Officer ·      IT Administrator ·      Unit Representative ·      CISO ·      Institutional Incident Response team ·      Privacy Officer ·      Others on a need-to-know basis	If requested by IT Security Officer, CIO, or another administrator   (Ad-hoc emails informing progress and/or formal incident report or lessons learned report)
Low	As soon as practicable (No more than one business day)	Incident Response Lead	·      Unit Representative ·      Others on a need-to-know basis	(Ad-hoc emails informing progress)

 

Role Equivalency Table (Institutional X Units)

Role	Institutional Teams	Divisional (Unit) Teams
Information Security Officer	·      Associate Director, Information Security Operations	·      Division, Information Security Lead ·      Division, IT Manager ·      Division, IT Leader or delegate
Incident Response Lead	·      Incident Response Architect ·      Security Analyst	·      Division, Information Security Lead ·      Division, IT Manager ·      Division, IT Leader or delegate
IT Administrator	·      N/A	·      Division, IT Director ·      Division, IT Manager ·      Division, IT Leader or delegate
Unit Administrator	·      N/A	·      Division, CAO ·      Division, Dean, Associate Dean ·      Division, Business Manager or delegate
Unit Representative	·      N/A	·      Division, Business Manager or delegate
CIO	·      CIO or delegate	·      N/A
CISO	·      CISO or delegate	·      N/A
Institutional Incident Response Team	·      Institutional Incident Response Team	·      N/A
Privacy Officer	·      FIPPA Office	·      FOIL (Freedom of Information Liaison)
Others on a need-to-know basis	·      Institutional IT teams’ representatives ·      Any other relevant person to inform or resolve the incident.	·      Other IT teams’ representatives ·      Any other relevant person to inform or resolve the incident.

 

Common Incident Types

The Incident Response program’s primary objective is to mitigate and contain the risk associated with computer security incidents. Some of the most common types of incidents are:

• • Phishing attacks,
  • Malware and viruses,
  • Denial of resources or services,
  • Unauthorized access or attempts to gain unauthorized access,
  • Inappropriate use of network resources,
  • Ransomware
  • Data breaches
  • Changes to system hardware, firmware or software without owner’s knowledge,
  • Any other unlawful activity involving computer networks and processing equipment.

Playbooks

Following the list of common incident types, playbooks are generally created to handle security incidents systematically and consistently. Incident response teams should leverage “Playbooks” as much as possible.  Some examples are provided below:

UTM - Ransomware playbook

Training, Awareness & Annual Assessment

General security incident response training, awareness and practices that shall be followed by Units:

• Review and adopt the Incident Response Plan (this document) or use it to create your own plans.
• Familiarize with the methodologies associated with the incident response process, including incident containment and playbooks.
• Review plans once a year and train team members as appropriate for operational readiness.
• Submit incident response plans to be incorporated in the DAI-IRSA annual assessment process.

Incident Response Handling (Practical Guide)

1. Review checklists and toolkits
2. CSIRT
3. Communication Plan
4. Incident Reporting
5. Tabletop Exercises

In addition to documenting procedures, units shall provide training and awareness to  staff and faculty to recognize and report incidents as quickly as possible.

Reporting an Incident

When reporting an incident to information Security, follow the procedure detailed on the page linked below:

IRP Main Web Page  

Additional External Resources

External resources may be required depending on the severity of the incident and the data types or assets involved. The engagement of those resources would typically incur additional costs to the Unit.   These may include:

Breach Coach	A breach Coach is functionally a project manager for an incident.  For significantly extensive or severe incidents, the services of a Breach Coach may be needed. In addition to project incident management services, they can also arrange access to the other resources listed below. In many cases, the breach coach role can be subsumed by sufficiently expert external counsel, who can offer breach coaching services/functions as part of their legal advice and guidance.
Credit monitoring services	Where a threat of identity theft is possible for one or many people, the Unit may need to offer identity theft protection insurance to those people.    At a minimum, any breaches involving SIN numbers are typically the low watermark for this, but this may still need to be offered if there is enough other personal data involved.    The offer to the affected individual is typically for an enrollment period of three months, with coverage provided for a year.
Specialized Legal Counsel	Where large breaches of data have occurred, or there is a threat of legal challenges against the University due to the breach, it may be necessary to engage Specialized Legal Counsel.  These specialists are often more experienced with issues and challenges posed by a security incident than the University’s General Counsel may be.
Forensic Analysis Firm	A forensic analysis firm provides specialized investigators to review the devices and systems involved in an incident.  They will attempt to determine the root cause of the incident, the attackers’ activities after they gained access, and what, if any, data was exfiltrated and how it happened. Forensic analysis can be a costly proposition, so ideally, internal staff, assuming they have the skills to do so, will independently investigate the devices and systems involved first. This internal review serves to either mitigate the need for Forensic Analysis or limit the scope to a minimal number of devices and systems. The University has entered into a contract with a Forensic Analysis Firm to limit the cost involved as much as possible.  Information Security can help arrange this service for a Unit should it become necessary.

Tabletop Exercises

Institutional and Unit incident response teams shall regularly organize tabletop exercises with several key operational areas and run through exercises to regularly test, develop, and refine incident response procedures, materials, and skills.

As part of the exercises, divisions/departments/faculties responsible for conducting or involving information security investigations shall actively participate when requested.

Additionally, other IT professionals at the University may be requested to participate as needed.

Table Top Scenario Examples

Table Top Exercise Scenarios and Notes

 

Downloads

• Incident Security Response Plan
• UTM Ransomware Playbook
• Tabletop Exercise Internal Notes
• Tabletop Exercise Scenarios
• Toolkit - IM – Response Guide
• Toolkit - IM - Leadership Summary
• Toolkit - IM - Email Leadership Summary
• Toolkit - IM - Manager Activity Tracking Sample
• Toolkit - IM - Technical Investigation Report
• Toolkit - IM - Checklist of significant steps for Incident Response and Handling