Incident Response Process
Topic: Incident Response Process
Audience: Students, Faculty and Staff
Revision Date: January 13, 2014
Author: Theresa Rowe
Roles and Responsibilities in the Event of an Incident
Organizational leadership will be provided by the Chief Information Officer or designee. The CIO or designee are responsible for determining the scope and impact of an incident, and will trigger initiation of the IT Disaster Recovery Plan or the Data Security Breach Review Panel defined in Policy #860 Information Security, as appropriate.
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.
If review indicates that a data breach has occurred, the Data Breach Security Review Panel defined under Policy #860 Information Security will be convened by the CIO or designee.
If a data breach involving payment card data is discovered, immediately follow payment brand contact procedures before any action is taken:
Stage I: Notification of an Incident
An Information Technology Incident can be reported in several ways, including:
An email to the University’s abuse contact at firstname.lastname@example.org
An email to the University Technology Services contact at email@example.com
A telephone call or in-person visit to any university helpdesk location will be transferred to firstname.lastname@example.org UTS Projects.
- A request from the OU Police Department or authorized law enforcement agency
- A request from the Office of Legal Affairs
- An observation or analysis performed by a systems administrator, system engineer or other UTS professional
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.
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. The following criteria are evaluated, in order of importance:
- 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.
- Does active memory need to be imaged or captured?
- Does the system require immediate removal from the network?
- Are there accounts (user or system) that require immediate protection by disabling or password change?
- Determine severity and criticality. Assess the urgency of the event.
- Is it an active problem, a potential threat, or event-in-progress?
- Was the problem discovered after the fact?
- Is the intrusion or exposure dormant, active, or complete?
- Does this involve the safety or privacy of individuals, including personally identifiable information?
- Determine scope and impact.
- Is there data loss or damage of data?
- Is there evidence of data breach, probability of access by unauthorized parties, or unauthorized exposure of data?
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 Information Security definitions:
- Confidential Data, including Personal Health Information, Personally Identifiable Information, and Payment Cardholder Information.
- Operation Critical Data
- Unclassified Data
- Identify the method by which data loss or exposure occurred.
- Identify the time-frame of affected data loss or exposure.
- Approximate number of lost files or records.
- Probability that data were accessed by unauthorized parties.
- Is a single edge device (desktop computer, laptop computer, storage drive, smartphone) involved, or are multiple devices involved?
- Is a server with multiple files involved?
- Is a single user or account involved, or are multiple accounts involved?
- Are system-level accounts involved?
- Is there a loss or attempted loss of service?
- Is there a loss or failure of hardware?
- Is there a breach of University IT Policy?
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:
Notify the Data Security Breach Review Panel identified in University Policy #860 Information Security
- 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.
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.
- Involve necessary UTS personnel.
Stage IV: Return of Service
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. Preserve all material evidence as quickly as possible. Then return services to normal operations, unless under other orders by the Office of Legal Affairs. Document the extent to which the risk to Confidential Data 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 V: Incident Response and Containment
Please proceed to each section that applies to the incident, based on the criteria identified from the previous stages.
- Identify encryption strategies implemented and in use.
- Based on the identified data involved in the incident, create contact file for breach notification process, if applicable.
- Notifications will be created using the templates as a guideline, and distributed with the assistance of the Office of Risk Management.
- Gather and preserve all relevant information, disk images, access logs, system logs and any other material.
Loss or Exposure of Data:
- Create an incident tracking record, with careful attention to incident handling and change-of-hands.
- Review the incident details with the Data Security Breach Review Panel, with counsel from the Office of Legal Affairs. These individuals will be kept informed during the Incident Review process.
- Determine the scope and impact of the data loss.
- Work with the Data Security Breach Review Panel on the appropriate notification plan for legal requirements, vendors, banks and other organizational entities.
Loss of Service
- 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.
Loss or failure of hardware
- If the hardware has been stolen, identify the data stored the stolen device. Handle incident as a loss of data incident.
- 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.
- If data have been permanently lost, create and distribute a notification using the notification template.
DOCUMENT: This document is authorized and maintained by the Office of the Chief Information Officer, University Technology Services.