Short Incident Response Playbook for Ransomware

1.     Quick and Dirty Cheatsheet (Start here if needed)

This is a very short version of section six. It will help you get started quickly. This is not intended to be used alone as it skips important steps. Please refer to section 6. These instructions assume that the time is within a working day. Do your best to minimize the damage if it occurs after-hours. If possible, call your own staff. However, delays can be expected as the University isn’t a 24/7 environment. Attackers will choose times when the response time may be limited.

1. DO NOT PANIC. Panicking can cause more problems. Take a deep breath and relax. Then, proceed as methodically as you can.
2. If there are active events, we want the ‘Blast Radius of an attack to be reduced as soon as possible. This will reduce damage and the recovery time.
   1. Usually, the ransomware attack will result in a message appearing on the screen. If you see this message, take a picture and disconnect the device physically or logically from the network. Get it now should be turned off. It is best to not turn it on unless necessary, as this could damage any forensic evidence.
   2. If you suspect or are certain that a device has been infected by ransomware but have not received any message, disconnect it physically or logically from the network. Get it now should be turned off. It is best to not turn it on unless necessary, as this could damage any forensic evidence.
   3. It may be simpler to turn off all devices infected by the same virus than to deal with each one individually.
   4. Don’t allow any devices to connect to your network until you have the ransomware removed. Get it now. Include mirrors and disaster recovery versions.

You must ask before you can act. If this is the case, then proceed to step 3. Get that permission and make any necessary changes. The University Chief Information Security Officer expects infected devices to be removed from the network within minutes. If you take immediate action, he will assist you.

1. Don’t forget to let others know. Be prepared with a preliminary scope, but don’t waste time compiling a detailed listing of files and devices. If you have an incident response group, tell them.your Unit Administrator(s). Send an email to Central Incident Response to let them know.security.response@utoronto.ca
2. Collect and protect information about the infection. You should have a list of infected devices, file locations, network logs, system images, malicious executables, screenshots of infected files, and local or network logs.
3. Go back to the procedure in section five and work through that, verifying any steps you have already completed.

2.     Purpose

Information Technologies Services – Information Security (ITSIS) has created this playbook to provide a guideline and typical workflow for recovering from ransomware attacks.

Ransomware is a type of malware that’s used to carry out a cryptoviral-extortion attack. The malware encrypts victim’s files making them inaccessible. An attacker demands a ransom to unlock them. The attackers could also export the victim’s files before encrypting them and threaten to distribute the data if they don’t pay the ransom. Although there are slight variations to the attack, these are the most common.

In the context of this playbook, a ransomware attack is when one or more university-owned devices are infected by malware that has encrypted files and a ransom demand has already been issued.

3. Scope

Ransomware typically attacks Workstations (desktops or laptops) but can spread to servers. This playbook applies to all individuals who have or manage workstations and servers that are associated with the University of Toronto. These devices can be located physically on campus (on-prem), or remotely (in the cloud or anywhere else a person works). The devices can be physically or virtually removed from any environment.

4. Prerequisites

This document assumes that you have access to infected physical devices. Access to network devices that contain infected devices might also be necessary. Administrator-level access is required to the hypervisor if virtual machines are involved.

It is assumed that you are familiar with the operating system, software, hardware, hypervisor, and network environment of the server.

A Security Incident Response Plan should be developed to clearly define the roles and responsibilities of all parties involved and how communication is expected about the incident.

5. Responsibilities

These actions will be performed primarily by subject matter specialists (SMEs) who have the necessary access and skills. The process will also involve other non-technical people, such as Operational management or administrative staff.

For a complete list of roles and responsibilities, please refer to the Security Incident Response Plan (for your unit/environment). The University’s Security incident response plan that guides individual plans can be found here: Information Security Response Plan.

6. Procedure

This procedure is more about organization than it is about a timeline. The following steps can be performed simultaneously and that is fine. It is okay to do one step ahead of the others. As long as all necessary actions are taken. This is illustrated by the fact that initial containment usually occurs before identification is complete.

7. Refer to the References

security Incident Response Plan

Recently, the University published its Security Incident Response Plan( Information Security and Enterprise Architecture (utoronto.ca)

8. Definitions

This SOP uses the following terms:

CSIRT:

Computer Security Incident Response Team is an institution responsible for coordinating and supporting a response to a computer security incident. It is made up of both technical and business personnel from the University and affected units.

FIPP:

The Freedom of Information and Protection of Privacy Office (FIPPO) supports privacy protection and access to university records. This is in support of transparency and accountability. They are informed about the University’s privacy requirements and any other legislation that the University is subject to.

Hypervisor:

Hypervisor, also known as VMM, virtualizer, or virtual machine monitor, is a piece of software, firmware, or hardware that creates virtual machines. (https://en.wikipedia.org/wiki/Hypervisor).

Register of University Risks:

This list contains information technology risks that are known at the University of Toronto. It also includes ownership details and timelines to reduce or eliminate those risks.