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
| 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