Incident Response Process

What is an Incident?

An event is usually a planned thing, such as a scheduled upgrade or a system launch. An incident is usually unplanned and has a connotation of a problem, accident, or issue that requires review and perhaps further action. It is something that happens unexpectedly, and often there is a negative connotation.

We have defined the most likely incidents and process in our public notice posted at the UTS Policies and Guidelines - IT Incident and Risk Management site. In this document, we refer to incidents as “Information Technology Incident.”

How do we discover Incidents?

Incidents may be reported in any of the ways noted in Stage I: Notification of an Incident described in this document.

Roles and Responsibilities in the Event of an Incident

Organizational leadership is provided by the Chief Information Officer or the most senior (highest ranking) UTS employee available (“designee”). The CIO or designee is responsible for determining the scope and impact of an incident. Leadership may change hands over the course of an incident.

Based on the CIO or designee review, the CIO or designee may trigger initiation of the IT Disaster Recovery Plan and may convene the Data Security Breach Review Panel defined in Policy #860 Data Management and Information Security, as appropriate. Retrieve roles and responsibilities from the IT Disaster Recovery Plan as needed.

Per OU Policy #890, release of information to outside agencies, including any law enforcement groups, must be coordinated with the explicit permission of the Office of Legal Affairs. Decision to release information should follow the Guidelines For Responding To Compulsory Legal Requests and Other Investigative Requests For Information.

If review indicates that a data breach has occurred, the Data Breach Security Review Panel defined under Policy #860 Data Management and Information Security will be convened by the CIO or designee. Breach response guidelines from the insurance provider will be provided and reviewed by the panel. Immediate action will be taken by the CIO and University Risk Manager to contact the cyber liability insurance firm and all action steps will be directed under the university cyber liability insurance and consultant agreement. Documentation for working with the insurance provider is in the UTS Incident Access Response - Google Team Drive, Documentation folder.

To assist with incident identification University Technology Services maintains an Incident Response Triage Playbook, which is accessible to all members of the campus community.

If a data breach involving payment card data is discovered, the CIO or designee, working with the Information Security Officer and the university cyber liability insurance consultants, will immediately follow payment brand contact procedures before any action is taken:

Visa Responding to a Data Breach

MasterCard Account Data Compromise User Guide

Stage I: Notification of an Incident

An Information Technology Incident can be reported in several ways, including:

In all cases, a ticket is created in the internal UTS ticketing system. This ticket is used for all tracking, analysis, and reporting functions. All incidents will proceed to the next stage. This step provides documentation for all UTS staff members that an Information Technology Incident has been received and recorded. The Chief Information Officer and/or Information Security Officer will notify broadly by emailing [email protected] and calling the most senior available UTS staff member.

Stage II: Initial Incident Evaluation

After the initial notification, UTS staff will engage the necessary resources to perform a cursory evaluation to identify the scope and impact of the incident. Related to this are guidelines for Investigations. The following criteria are evaluated, in order of importance:

  1. Determine level of preservation required before any item is touched or reviewed. Do not turn a computer or other electronic device off; anything with an on/off switch should be left on. Note that even reviewing some files will corrupt the evidentiary quality of the material.
    1. Does active memory need to be imaged or captured?
    2. Does the system require immediate removal from the network?
    3. Are there accounts (user or system) that require immediate protection by disabling or password change?
  2. Determine severity and criticality. Assess the urgency of the event.
    1. Is it an active problem, a potential threat, or event-in-progress?
    2. Was the problem discovered after the fact?
    3. Is the intrusion or exposure dormant, active, or complete?
    4. Does this involve the safety or privacy of individuals, including personally identifiable information?

    5. Review criteria in the Disaster Recovery Plan; does the Disaster Recovery Plan need to be initiated?

  3. Determine scope and impact.
    1. Is there data loss or damage of data?
    2. Is there evidence of data breach, probability of access by unauthorized parties, or unauthorized exposure of data?

    3. What data are involved and what data classification covers the exposed data? Are original intellectual property or externally funded grant research data involved? Data loss can be classified as one of the following, per IT Policy #860 Data Management and Information Security definitions:

      1. Confidential Data, including Personal Health Information, Personally Identifiable Information, and Payment Cardholder Information.
      2. Operation Critical Data
      3. Unclassified Data
    4. Identify the method by which data loss or exposure occurred.
    5. Identify the time-frame of affected data loss or exposure.
    6. Approximate number of lost files or records.
    7. Assess probability that data were accessed by unauthorized parties.
    8. Is a single edge device (desktop computer, laptop computer, storage drive, smartphone) involved, or are multiple devices involved?
    9. Were the device or devices used in an University Organized event or registered to a University Event account?
    10. Is a server with multiple files involved?
    11. Is a single user or account involved, or are multiple accounts involved?
    12. Are system-level accounts involved?
    13. Is there a loss or attempted loss of service?
    14. Is there a loss or failure of hardware?
    15. Is there a breach of University IT Policy?
    16. Was a device lost or stolen?
    17. If there is a service interruption, post an informational message on the status of service on the UTS homepage, to be updated every two hours (unless specifically noted), until service is returned.

If none of the above conditions are met, then an incident did not take place. The tracking ticket is updated with all relevant information and analysis, and then closed.

Stage III: Response Activation

For any incident matching the criteria listed above:

  1. Notify the Data Security Breach Review Panel identified in University Policy #860 Data Management and Information Security. Note breach reporting deadlines in communications.

  2. For Confidential Data, identify the nature and extent of the data involved, the exposure to unauthorized individuals, the identity of unauthorized individuals, and whether Confidential Data were acquired, viewed, and utilized.

  3. If login credentials were compromised for an individual in the university community, initiate a Red Flags notice following the university Red Flags policy Policy #412 Detection of and Response to Identity Theft Red Flags. UTS will notify Student Business Services based on this policy.

  4. Involve necessary UTS personnel.
  5. Complete the Checklist for Lost, Stolen or Missing Computer, Table, Smartphone, or Other Media Storage Device found at the end of this document, if a device was involved.

  6. If the Disaster Recovery Plan is initiated, notify the campus Emergency Manager and the Chief Operating Officer, and follow the notifications in the Disaster Recovery Plan.

Stage IV: Incident Response and Containment

Please proceed to each section that applies to the incident, based on the criteria identified from the previous stages.

  1. All incidents:
    1. Consider compensating controls or any efforts that can immediately provide relief by returning services.
    2. Identify encryption strategies implemented and in use.
    3. Based on the identified data involved in the incident, create contact file for breach notification process, if applicable.
    4. Notifications will be created using the templates as a guideline, and distributed with the assistance of the Office of Risk Management.
    5. Gather and preserve all relevant information, disk images, access logs, system logs and any other material.
  2. Loss or Exposure of Data:
    1. Create an incident tracking record, with careful attention to incident handling and change-of-hands.
    2. Review the incident details with the Data Security Breach Review Panel and with counsel from the Office of Legal Affairs. These individuals will be kept informed during the Incident Review process.
    3. Determine the scope and impact of the data loss.
    4. Work with the Data Security Breach Review Panel on the appropriate notification plan for legal requirements, vendors, banks and other organizational entities.
  3. Loss of Service
    1. In the case of an attempted loss of service (such as a failed Denial of Service attack), take preventative measures to remove the issue attempting to cause the loss of service.
  4. Loss or failure of hardware
    1. If the hardware has been stolen, identify the data stored the stolen device. Handle incident as a loss of data incident. Complete the Checklist for Lost, Stolen, or Missing Computer, Smartphone, or Other Media Storage Device below.
    2. If there is a loss of service and data have been temporarily lost, but can be recovered from backup systems, place informational message on UTS homepage during the duration of the service loss when feasible.
    3. If data have been permanently lost, create and distribute a notification using the notification template.

Stage V: Return of Service

Preserve all material evidence as quickly as possible. Then return services to normal operations, unless under other orders from the Office of Legal Affairs. Document the extent of risk to Confidential Data, whether the risk has been mitigated, and note whether exposed data have been fully retrieved, destroyed, or reconfigured to be meaningless (i.e., changing identification numbers, changing passwords, closing accounts, etc.).

Stage VI: Assess and Comply with Mandated Reporting Requirements

Review data involved and execute mandated reporting requirements with the Data Security Breach Review Panel and the Office of Legal Affairs. This may involve Beazley for compliance efforts, as coordinated with University Risk Management. In particular, note reporting requirements for:

DOCUMENT: This document is authorized and maintained by the Office of the Chief Information Officer, University Technology Services.

Last update: September, 2020