This Cybersecurity Incident Response Plan establishes the procedures for identifying, reporting, and responding to a cybersecurity event. It establishes the basic language to discuss such events, identifies roles and responsibilities involved in responding to and recovering from these events, and provides a playbook for handling these events from the time an event is detected to the post incident report and event closing.

Purpose

Cybersecurity incidents must be reported promptly through the proper University and/or Department Information Technology channels and resolved by designated professionals in a manner that is consistent with University policies, applicable laws, and this plan.

This Cybersecurity Incident Response Plan establishes the procedures for identifying, reporting, and responding to a cybersecurity event.  It establishes the basic language to discuss such events, identifies roles and responsibilities involved in responding to and recovering from these events, and provides a playbook for handling these events from the time an event is detected to the post incident report and event closing.  The objectives of this Plan are to:

• Enable the University to respond to a cybersecurity incident without delay and in a coordinated manner.
• Enable assessment of mitigation measures that can be taken to protection information, assets and privacy, and limit or prevent impact during an active cybersecurity incident.
• Provide a framework that supports the protection and preservation of evidence in the event of illegal or criminal activity.
• Ensure provision of timely notification of those who need to know, including but not limited to University leadership, Federal and/or State agencies, and Business Partners.
• Ensure that communications with the public/media are handled appropriately by designated University personnel.
• Support completion of all required investigation, documentation, appropriate notification, and remediation in a timely and organized manner.
• Continuously improve the way the University responds to cybersecurity events.

Scope

This plan applies to all University of Oklahoma and Rogers State University Faculty, Staff, or Student, contractors, and their associated contractors, as well as temporary workers and those given access to IT systems and/or services.  This plan applies to all campuses, all access locations, and remote or off-site locations.

Maintenance

The Cybersecurity Incident Response Plan shall be reviewed annually, and more often as needed.

Roles and Responsibilities

Security is everyone’s responsibility.  To support OU’s distributed Information Technology (IT) environment and to accomplish the objectives and goals of this Plan, OU IT GRC proposes the following roles and responsibilities for governance, risk, and compliance activities at OU.

• Users: Report potential cybersecurity incidents immediately and complete tasks assigned by the incident commander.
• Tulsa Information Technology:  Designates an incident commander, maintains the cybersecurity incident response playbook, and monitors networks and systems to identify and report new threats.
• IT Security Operations: Designates an incident commander, maintains the cybersecurity incident response playbook, and monitors networks and systems to identify and report new threats.
• IT Governance, Risk, and Compliance (GRC): Maintains and exercises the Cybersecurity Incident Response Plan, provides notification to internal stakeholders, facilitates Post Incident Reviews, provides quarterly cybersecurity incident reports to governance, and uses security incident data to inform risk analysis decision-making.
• IT Training, Education, and Awareness (TEA): Develops training, education, and awareness content to inform users of their role and responsibility for security incident response.
• OU IT, Distributed IT, and Independent System Administrators (ISA):  Respond immediately to reports of cybersecurity incidents, provide swift action to notify internal stakeholders of planned containment activities, complete tasks assigned by the incident commander, serve as the system-level subject matter expert to support the incident commander for the duration of the incident.
• Data Owner (Dean or Vice President): Respond immediately to reports of cybersecurity incidents and provide resources, as needed, to ensure cybersecurity incident containment occurs.  
• HIPAA Security Official: Reviews security incident summary and determines if communication/notification to the Office for Civil Rights is necessary.
• Vice President for Research: Reviews security incident summary and determines if communication/notification to research sponsors is necessary.
• Office of Legal Counsel: Reviews security incident summary and determines if communication/notification to the regulatory bodies is necessary.
• ITESC: Reviews and approves the program plan reviews quarterly cybersecurity incident reports to governance and uses security incident data to inform risk analysis decision-making.
• CIAC:  Aligns IT strategies, projects, and capabilities with domain goals; actively communicates and collaborates with campus advisory bodies to execute governance risk or policy objectives within their domain; reviews quarterly cybersecurity incident reports to governance and uses security incident data to inform risk analysis decision-making.
• Director for Rogers State University Academic Computing Services:  Ensures appropriate resources to support the program plan are in place; review and/or approve IT security compliance exceptions; provides notice to units external to IT upon activation of the Plan; provides post incident reports to institutional leadership.
• CISO:  Ensures appropriate resources to support the program plan are in place; review and/or approve IT security compliance exceptions; provides notice to units external to IT upon activation of the Plan; provides post incident reports to institutional leadership.
• CIO:  Ensures appropriate resources to support the program plan are in place; review and/or approve IT security compliance exceptions; provides notice to units external to IT upon activation of the Plan; provides post incident reports to institutional leadership.
• PCI Advisory Group:  Determines whether breach notification to the card brands and/or card holders is required or warranted and will approve and direct any notification and/or reporting required by the responsible business unit.

Definitions

02 – Information Technology and Security Definitions

Definition of a Cybersecurity Event

A cybersecurity event is a change that may have an impact on organizational operations (including mission, capabilities, or reputation).  Cybersecurity events include, but are not limited to:

• Any alert indicating a security incident is possible (e.g., phishing, malware, etc.) where an unauthorized access attempt was detected but blocked
• Any event in which an account belonging to a person that has access to the data might have been compromised or the password shared with an unauthorized person (responding to phishing emails, someone shoulder surfing and writing down your password, etc.)
• Any event in which University or Information System policies, standards, or practices are violated

Definition of a Cybersecurity Incident

A cybersecurity incident is an event that has been determined to have an impact on the organization prompting the need for response and recovery.  Cybersecurity Incidents include, but are not limited to:

• Any scenario in which access to university data has been gained by an unauthorized person that requires response and recovery procedures
• Any scenario in which a device containing university data has been infected with malicious software (viruses, Trojans, etc.) and requires response and recovery procedures
• Successful attempts to physically enter or break into a secure area where University data is or might be stored
• Lost or stolen assets or hardware

Definition of a Breach

A breach is the acquisition, access, use, or disclosure of Protected Health Information (PHI), Payment Card Information (PCI), or Personally Identifiable Information (PII) in a manner not permitted by law or obligations that compromises the security or privacy of the data.

 

Incident Response Phases

The OU Cybersecurity Incident Response process encompasses six phases: preparation, detection, containment, investigation, remediation, and recovery.  These phases are defined in NIST SP 800-61 (Computer Security Incident Handling Guide). 

This plan is the primary guide to the preparation phase from a governance perspective and allows OU to be ready to respond to any incident.  IT Security maintains detailed response procedures that allow OU to be ready to respond to common incidents.  Access to detailed response procedures is limited to authorized IT Security personnel. 

Before an Incident

Preparation includes those activities that enable OU to respond to an incident. 

Maintain Readiness: Train and Test

It is important to coordinate with stakeholders to manage a list of cyber crisis response documents, where to find them and how to use them.

1. IT GRC holds tabletop exercises with executive, management, and technical staff to pressure-test the response plan in a simulated environment.
2. IT TEA will make Cybersecurity Incident Response training materials available to OU faculty, staff, students, residents, and volunteers based on their defined role in the Cybersecurity Incident Response Plan. 

Implement Out-of-Band Communications

OU IT has implemented out-of-band communication and coordination mechanisms in case of failure of one mechanism.

1. Internal OU IT communications may occur using Slack and/or Zoom for low or medium-impact incidents.
2. For high or critical-impact incidents, the CSIRT Microsoft Team and a dedicated private channel will be used for communication and coordination mechanisms.

During an Incident

Incidents can occur in countless ways and OU should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors.  Automated detection capabilities include network-based intrusion detection/prevention systems, antivirus software, and log analyzers.  Incidents may also be reported by users.  Incidents will be categorized into one of three categories: event, incident, breach.  

1. Event:  An event is an exception to the normal operation of IT infrastructure, systems, or services.  Not all events become incidents (e.g., Users are tricked into clicking a link and entering user credentials that have been reset preventing unauthorized access to systems or data.)
2. Incident:  A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. 
3. Breach:  A breach is the acquisition, access, use, or disclosure of Protected Health Information (PHI) or Personally Identifiable Information (PII) in a manner not permitted by law or obligations that compromises the security or privacy of the data.

Reporting Cybersecurity Incidents

The Report Security Incident Checklist provides guidance to gather helpful information that will be used to drive incident response activities. 

1. If a person(s) believes a Cybersecurity Incident has occurred at OU, they may contact OU IT Security at:    https://ou.edu/ouit/cybersecurityincident
2. If a person(s) believes a Cybersecurity Incident has occurred at RSU, they may contact RSU IT at:  https://rsuacs.atlassian.net/servicedesk/customer/portal/3

Review the Incident's Severity and Scope

Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. 

1. OU IT Security Operations will assign an Incident Commander who will be the primary point of contact for the duration of the response and recovery effort.  The Incident Commander’s name and contact information will be provided to the IT reporter and other relevant parties, as needed.
2. Incident commanders should consider how the incident will impact the existing functionality of the affect systems. 
3. Incident commanders should consider not only the current functional impact of the incident, but also the likely future functional impact if it is not immediately contained.  See During an Incident Checklist.

Containment

Containment is important before an incident overwhelms resources or increases damage.  Containment provides time for developing a remediation strategy.  The goal of Cybersecurity Incident containment is to reduce and contain the scope of an incident and ensure that Information Systems are returned to service as quickly as possible.  Rapid response and containment are balanced by the requirement to collect and preserve evidence in a manner consistent with the requirements of rules 26-34 of the Federal Rules of Civil Discovery, and to abide by legal and administrative requirements for documentation and chain of custody.

1. Containment strategies may vary based on type of incident or be defined in the Security Operations Playbook.  Containment strategies may include shutting down the system, disconnecting it from a network, disabling certain functions, security containment (a form of containment allowing limited access to gather evidence).

Incident Analysis

The goal of evidence gathering, and forensics is to gain a better understanding of an event by finding and analyzing the facts related to the event.  Collecting evidence can pose legal issues.  Among these issues is the capture of information with privacy or security implications, such as passwords or the contents of e-mails. 

1. All requests to collect and preserve digital evidence outside of available IT Security tools, must be approved by Legal.
2. The CSIRT should identify possible data sources.  The most obvious and common sources of data are desktop computers, servers, network storage devices, laptops, external data storage media, etc.  After identifying potential data sources, the CSIRT should activate/notify GRC. 
3. IT GRC works with CSIRT to define and submit the OLC authorization request for approval.  This workflow leverages the OU DocuSign service.  Detailed procedures, aligning with NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response, to acquire or analyze data are maintained internally by IT GRC.
4. The CSIRT will determine the scope and impact of the incident, including any data that may have been compromised or stolen/exported/downloaded.

Incident Response

When an incident is analyzed and prioritized, the incident response team needs to notify the appropriate individuals so that all who need to be involved will play their roles. 

1. The CSIRT will develop a response plan based on the severity and impact of the incident.
2. The CSIRT will communicate with internal stakeholders, including senior management, IT staff, end users, and external entities including law enforcement, insurance carriers, and any third-party firms or providers engaged around security.  See Communications Playbook.
3. The CSIRT will share details about the incident the steps being taken to resolve it.

Incident Recovery

Remediation is the post-incident repair of affected systems, communication, and instruction to affected parties, and analysis that confirms the threat has been contained.  During this phase it is important to identify all affected hosts so that they can be remediated.  Recovery is the post-incident restoration of affected systems or data and instructions to affected parties if new procedures are created. 

1. For some incidents, remediation is not necessary or is performed during recovery.  Because remediation actions are typically incident or system specific, the CSIRT shall define and prioritize remediation steps.
2. During the recovery phase, administrators restore systems to normal operation, confirm that systems are functioning normally, and (if applicable) remediate vulnerabilities to prevent similar incidents.  Because recovery actions are typically system specific, detailed procedures are not included in this document.

After an Incident

Post Incident Activity

Low and medium impact incidents need limited post-incident analysis.  After high or critical impact incidents have occurred, it is worthwhile to hold post-mortem meetings that provide a mechanism for information sharing across teams.  Each incident response team should evolve to reflect new threats, improved technology, and lessons learned. 

1. The CSIRT must participate in a Post Incident Review and identify any necessary improvements or lessons learned for high or critical impact incidents.  Remediation plans should be reviewed and approved by the impacted business unit to validate appropriate personnel will address the underlying issues in a timely manner.  See Checklist – After an Incident.

Security Incident Response Checklists

• Report Security Incident
• During an Incident
• After an Incident

Incident Response Playbooks

 

Communications Playbook

This section is designed to support the University of Oklahoma’s internal and external communications surrounding a suspected cybersecurity incident. This document outlines a suggested communications approach and messaging for short-term impacts. It will be continually updated based on the findings of the ongoing forensic investigation.

1. Identify who needs to be notified (internal or external) and who is responsible.
2. Use the communication objectives to coordinate the response and message.
3. Develop internal frequently asked questions.
4. Determine how the notification will be delivered (e.g., internal e-mail, US mail, media alert or press release, etc.).
5. Determine which agencies, if any, require notification.  Provide each agency with their required information, in the format and manner they require.

Key Contacts

Data Type	Role
Category A	HIPAA Security Official
Category B	PCI Compliance
Category C	Office of the Registrar – HSC
Category C	Office of the Registrar – Norman
Category C	Office of Legal Counsel
Category D1	Office of Export Controls
Category D2	Office of Research Administration – HSC
Category D2	Research and Partnerships – Norman
Category E	Office of Legal Counsel
All	Office of Enterprise Risk Management
RSU Data	Director of Academic Computing Services

 

Communication Objectives

• Provide internal leadership with appropriate messages to navigate conversations faculty, staff, and students, and to serve as the primary source of information.
• Ensure alignment between communications team and external counsel on strategy and messaging.
• Ensure a consistent, unified message is delivered across OU to faculty, staff, and students.
• Prepare for potential public/media scrutiny; mitigate negative reaction from faculty, staff, students, media, and other third parties by minimizing/containing the story and not amplifying it unnecessarily or creating additional news cycles.
• Maintain trust with employees, students, and other third parties.

Plan Approval, Review, and Revision

• December 2020: Baseline Version
• July 2021: Revised incident classification scheme, revised playbooks, added DIT responsibilities, added user responsibilities, added IT Owner responsibilities
• June 2022: Approved by the Cybersecurity and Infrastructure Advisory Committee
• April 2024: Updated reporting security incidents section, updated investigating security incident section to include new security incident response checklists.
• November 2024: Updated During an Incident Checklist Impact Matrix to include CUI and Export-Controlled data or system