Information security incident response

This document assists Ohio University (OHIO) personnel in establishing information security incident response capabilities and handling incidents efficiently and effectively. It provides a guide for incident handling, particularly for analyzing incident-related data and determining the appropriate response to each incident.

Table of contents

*Please use the links to navigate to the topics below.*
SECTION 1: INTRODUCTION
Authority
Purpose and scope
Audience
SECTION 2: CYBER INCIDENT RESPONSE CAPABILITIES
Mission
Strategy and goals for cyber incident response
University authority for cyber incident response
OHIO's approach to InfoSEC incident response
SECTION 3: THE INCIDENT RESPONSE PROCESSES
Preparation
Identification, detection, and analysis
Containment, eradication, and recovery
Incident closure
APPENDIX A: SENSITIVE DATA RESPONSE PROCEDURE
APPENDIX B: CHECKLIST OF MAJOR STEPS FOR INCIDENT RESPONSE AND HANDLING
APPENDIX C: COMPROMISE QUESTIONNAIRE AND INFORMATION GATHERING
APPENDIX D: UNIVERSITY POLICIES AND STANDARDS
APPENDIX E: GUIDANCE ON REPORTING AND INFOSEC INCIDENT
APPENDIX F: CONTACT INFORMATION FOR LOCAL POLICE
APPENDIX G: GENERALIZED CYBER INCIDENT ESCALATION AND WORKFLOW DIAGRAM
APPENDIX H: ACRONYMS

Record of changes

Version #	Implemented by	Revision date	Approved by	Approval date	Reason
1	Information Security Office	05.06.2021	Information Security Governance Committee	05.06.2021	Initial Draft and corresponding implementation.

Review cycle

This incident response plan should be reviewed on an annual basis. The review should include an examination of procedures and resource information to make sure information reflects OHIO’s needs. The Information Security Governance Committee and the Information Security Office should review all changes.

Section 1: Introduction

Authority

Oversight of the security of University Information Technology (IT) resources and information is entrusted to the Chief Information Officer by the OHIO Board of Trustees.

In 2009, the Ohio University Board of Trustees passed a resolution requiring the Chief Information Officer to:

Assume leadership, responsibility and control for the University's information technology resources and data, including potentially sensitive information. This responsibility shall extend to each University campus, college and planning unit. The Chief Information Officer shall utilize the experience, expertise and resources of other University offices as appropriate.
Direct the University Chief Information Officer to be responsible for conducting all investigations and responses related to the unauthorized access and/or disclosure of sensitive information as well as all computer security incidents to minimize risk to the University and its constituents.
Direct the University Chief Information Officer to develop and implement all appropriate policies and procedures necessary to protect the University's information technology resources and data.

University policy 91.005 Information Security, provides a framework to continuously protect and secure Ohio University’s data and information resources and comply with and maintain legal and contractual requirements. This policy also designates the Information Security Office (ISO) to consult with stakeholders to define the information security standards which help support and maintain an adequate information security posture.

ISO manages and coordinates detection, identification, containment, eradication, and recovery efforts of reported cyber security incidents with OHIO departments’ IT personnel. The Senior Manager, Information Security (SMIS) also has the discretionary authority to classify threats as a risk to the enterprise and can activate the Incident Response team. The Ohio University Critical Incident Response Team (CIRT) will only be activated if a cyber security incident has been identified as affecting University IT systems/services at an enterprise or a multi-departmental level.

Purpose and scope

This document seeks to assist university personnel in mitigating the risks from cyber security incidents by providing a practical guide for responding to incidents effectively and efficiently. It includes guidelines on establishing an effective cyber security incident response program, but the primary focus of the document is to provide assistance with detecting, analyzing, prioritizing, and handling incidents.

This document is not intended to replace Business Continuity or Disaster Recovery Planning. This document addresses only incidents that are computer security-related, not those caused by natural disasters, power failures, etc. This document applies to computers and technology devices which store, process, or transmit university data. All University locations are covered by this document. It is not intended to be used as a detailed list to accomplish every task associated with cyber security incident handling and response. Rather, the document is intended to provide a framework and processes by which consistent approaches can be developed and resource allocations can be made for a given scenario to facilitate the detection, identification, containment, eradication, and recovery from specific cyber security incidents. This document is intended to provide guidance to address Information Security (InfoSec) incidents that have impacts that affect the University’s operational, financial, or reputational standing and/or the ability to comply with regulatory or legal requirements.

Audience

This document has been created for the OHIO Critical incident response team (CIRT), system and network administrators, security staff, technical support staff, Senior Manager, Information Security (SMIS), chief information officer (CIO), computer security program managers, and others responsible for preparing for or responding to cyber security incidents at Ohio University.

Section 2: Cyber incident response capabilities

An Information Security (InfoSec) incident is defined by the Department of Homeland Security as an occurrence that (A) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of an information system or the information that system controls, processes, stores, or transmits; or (B) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. An incident could be either intentional or accidental in nature.

Examples of InfoSec incidents may include, but are not limited to:

An incident in which an attacker commands a group of computers or botnet to send high volumes of connection requests to a web server, causing it to crash.
An incident in which users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host.
An incident where an attacker obtains sensitive data and threatens that the details will be released publicly if the organization does not pay a designated sum of money.
An incident where a user provides or exposes sensitive information to others through peer-to peer file sharing services.

Successful incidents similar to those noted above have occurred at OHIO. These incidents have caused financial and reputational harm, disrupted daily operations, and created compliance issues with state and federal laws. Establishing cyber incident response capabilities at OHIO ensures systematic (i.e., following a consistent incident handling methodology) and coordinated actions are taken. Incident response helps personnel to minimize loss or theft of information and disruption of services caused by InfoSec incidents.

Incident response capabilities also build institutional resilience. Information gained and lessons learned during incident handling can help better prepare for dealing with future incidents.

Mission

One of the elements of OHIO’s Information Technology mission is to provide, secure, and maintain information systems, allowing the University to accomplish its mission.

To support the University’s mission, Information Technology has developed a guide for implementing information security incident response plans. To aid in the coordination of response activities, Information Technology will consult with the Ohio University Critical Incident Response Team (CIRT).

Strategy and goals for cyber incident response

Timely and thorough action to manage the impact of cyber incidents is a critical component of the response process. The response should limit the potential for damage by ensuring that actions are well known and coordinated. Cyber incident response goals are:

To protect the well-being of the University community.
To protect the confidentiality, integrity, and availability of University systems, networks, and data.
To help University personnel recover their business processes after computer or network security incidents.
To provide a consistent response strategy to system and network threats that put OHIO data and systems at risk.
To develop and activate a communications plan including initial reporting of the incident as well as ongoing communications as necessary.
To address InfoSec related legal issues.
To coordinate efforts with external Computer Incident Response Teams.
To minimize the University’s reputational risk by notifying appropriate University officials of incidents that may become high profile events and implementing timely and appropriate corrective actions.

To achieve these goals, Information Technology has adopted security best practice guidance and information security standards derived from standardized incident response processes such as those published by the National Institute of Standards and Technology (NIST) Special Publication 800-61 and other authorities.

The specific incident response process elements that comprise the OHIO incident response plan include:

Preparation: Maintaining and improving incident response capabilities and preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.
Identification: Confirming, characterizing, classifying, categorizing, scoping, and prioritizing suspected incidents.
Containment: Minimizing loss, theft of information, or service disruption.
Eradication: Eliminating the threat.
Recovery: Restoring computing services quickly and securely.
“Lessons learned” post-incident activities: Assessing response to better handle future incidents through utilization of reports, and after-action activities, or mitigation of exploited weaknesses to prevent similar incidents from occurring in the future.

These six elements of Incident Response will be defined in detail in section 3.

Cross-cutting elements present throughout incident response handling include:

Communication: Notifying appropriate internal and external parties and maintaining situational awareness;
Analysis: Examining available data to support decision-making throughout the incident management lifecycle; and
Documentation: Recording and time-stamping all evidence discovered, information collected, and actions taken from Identification through Post-incident activities.

University authority for cyber incident response

The following University organizations act as University Authorities; those who are authorized to make requests and decisions regarding cyber security incident response at OHIO:

Chief Information Officer (CIO): empowered to respond to IT security incidents by BOT Resolution “Regarding the Leadership, Responsibility, and Security of OHIO's Information Technology Infrastructure”
Senior Manager Information Security (SMIS): delegated authority by CIO to decide whether to activate CIRTOHIO Critical Incident Response Team (CIRT): a broad range of University stakeholders (see university Policy 44.100).
University Legal Counsel: any law enforcement/legal actions, questions about information disclosure, legal aspects of the investigation
University President: personnel actions for staff
Executive Vice President and Provost: personnel actions for faculty
University Internal Audit: data integrity of critical University data, compliance with University procedures and fraud investigations
Division of Student Affairs/Student Conduct: offenses by OHIO students
Ohio University Police Department: criminal matters
Departmental leadership as stewards of university data will be engaged as applicable in coordination with designated University Data Stewards for regulatory compliance acts such as FERPA, HIPAA, PCI-DSS, etc.

NOTE: Requests from local, state, or federal law enforcement officials do not necessarily constitute proper authority. All requests from these agencies must first be made to University Counsel before contacting any university departmental personnel.

Any of the following requests from local, state or federal law enforcement agencies must be authorized by University Legal Counsel prior to issuance:

Warrant: If you are presented with a warrant that has been authorized by University Legal Counsel, you should comply immediately with the request. Notify your supervisor and the Campus Police unless advised otherwise by law enforcement or University Legal Counsel.
Subpoena: If you are presented with a subpoena that has been authorized by University Legal Counsel, comply with the request. Notify your supervisor unless you are advised otherwise by Legal Counsel.
Freedom of Information Act: University Legal Counsel will advise how requests should be honored.

OHIO’s approach to InfoSec incident response

This section provides guidelines for establishing incident response capabilities, and advice on maintaining and enhancing existing capabilities in the event of an InfoSec incident.

Reporting an information security incident

An InfoSec incident is an event that poses a threat to the integrity, availability, or confidentiality of an IT system. Incidents must be reported immediately to the Information Security Office (ISO) after discovery. The ISO or designee will act as the Incident Response Manager (IRM) for all reported cyber incidents. The ISO, with the assistance of the reporting entity will work together to coordinate all aspects of the incident response process. The reporting entities must coordinate with the ISO (or designee) prior to initiating any actions during the investigation or in response to information security (InfoSec) incidents. All communications regarding InfoSec incidents must be conducted through channels that are known to be unaffected by the InfoSec incident under investigation. See the Notification of a Data Security Breach standard for additional information.

InfoSec incidents can be reported in several ways including by email, phone, in-person, or by initiating a OIT ServiceDesk ticket.

Information Security Office contact information: security@ohio.edu or 740-566-SAFE(7233).

Examples of incidents that should be reported immediately include, but are not limited to:

A virus/worm affecting multiple systems;
Intrusion or damage to:
- Web site or page
- Computer system or network
- Wireless access
- Cell phones, smartphones
- Laptops, tablet computers
- Fax machines
- Voice mail
- Voice over IP (VOIP) systems.

See Appendix E for further guidance on reporting InfoSec incidents.

Early notification allows the ISO and affected departments time to gather as much information as possible when evaluating potential cyber incidents. Information that should be gathered and shared when reporting cyber incidents includes:

Contact information of affected individuals
IP address, hostname, or location of system(s)
In the case of a website intrusion, the specific URL(s)
Disclosure of data that may be included on the system. This is particularly important if this data may include social security numbers, credit card numbers, bank account numbers, debit card numbers, driver’s license numbers, passport numbers, medical information, or FERPA data.
Disclosure of the system’s criticality, as noted on its most recent IT risk assessment.
A description of the incident that includes a timeline and identification/detection details.

Prompt reporting may also help reduce common risks associated with cyber incidents, including:

Physical safety risk: As the “Internet of Things” becomes more prevalent in monitoring physical facilities, an InfoSec attack against networked devices could cause physical harm to individuals.
Regulatory risk: Compliance with federal and state legislation regarding the protection of information. This includes data and systems that fall under GLB (Gramm-Leach-Bliley Act), HIPAA (Health Insurance Portability and Accountability Act), FERPA (Family Educational Rights and Privacy Act, ITAR (International Traffic in Arms Regulations), PCI-DSS (Payment Card Industry Data Security Standard), federal/state data breach notification laws, and the Patriot Act.
Operational risk: Failure to protect systems and data can cause disruptions to critical daily operations.
Financial risk: There may be costs associated with lost data, restoring systems, and data breach notifications.
Reputational risk: There may be a negative impact on confidence in a system or a negative impact on the university’s reputation.

InfoSec incident response procedures

Once an incident report has been received, the ISO will confirm details surrounding the incident through the identification, detection, and analysis phases of incident handling. Different types of incidents merit different types of response strategies, but generally:

If an incident is confirmed, the ISO will coordinate actions through the Chief Information Officer.
If an incident cannot be confirmed, the ISO will make mitigation recommendations to the reporting entity.

The ISO, and/or the IRM shall categorize the incident according to type and potential impact(s). The incident shall then be classified and responded to in order of priority.

If immediate action is required, the ISO will begin coordinated incident response activities. NOTE: The CIRT will only be activated if a cyber incident is affecting University IT systems/services at an enterprise or a multi-departmental level.
If immediate action is not required, the ISO will work with the reporting entity to determine appropriate response actions.

In the case of multiple cyber incidents occurring simultaneously, the ISO, and/or the IRM will classify the incidents according to their immediate and potential adverse effects and prioritize recovery and investigation activities according to the severity of these effects.

Communications and information sharing about a cyber incident

Communication is an essential part of cyber incident response. Because communications regarding an incident often need to occur quickly, it is vital to build relationships and establish suitable means of communication between the ISO and other groups, both internal (e.g., human resources, legal) and external (e.g., other incident response teams, law enforcement).

Once an incident is confirmed, the ISO will coordinate information sharing so that only the appropriate information is shared with the appropriate parties.

A communication plan is mandatory whenever a breach of Personally Identifiable Information (PII) has been confirmed. Appendix A provides a workflow diagram for communications required when there is an exposure of sensitive data.

The approach to communications should be tailored depending on the stakeholders and in accordance with the Information Security Standard Data Breach Response and corresponding Administrative Procedure Notification of a Data Breach.

Section 3 provides more detail about developing an InfoSec incident communications plan.

Section 3: The incident response processes

This section describes the major phases of the incident response process—preparation, detection and analysis, containment, eradication and recovery, and post-incident activity.

Appendix B provides a checklist of major steps to be performed during response and handling of an incident. The checklist does not dictate the exact sequence of steps that should always be followed and should be used as a guide for those involved. Appendix B also provides Unix/Linux and Windows Operating Systems Checklists for responding to system compromises.

Preparation

Preparation is fundamental to the success of incident response programs.

Incident response methodologies typically emphasize the proactive and ongoing use of tools, training, and processes necessary for preventing incidents by ensuring that systems, networks, and applications are sufficiently secure.

Many of the necessary tools and training are available on the Information Security Office website http://www.ohio.edu/oit/security.

One of the recommended preparation practices is for University colleges and departments to conduct an IT Risk assessment as outlined in University Policy 91.006 Information Security Risk Management, Information Security Risk Assessment Standard, and the corresponding administrative procedure Information Security Risk Assessment Strategy. The benefits of conducting an IT Risk Assessment include identifying applicable threats, including organization-specific threats. Each risk is categorized and prioritized to determine if risk can be mitigated, transferred, or accepted until a reasonable overall level of risk is reached. Another benefit of conducting risk assessments regularly is that critical resources are identified, allowing staff to emphasize monitoring and response activities for those resources.

Identification, detection, and analysis

Early steps taken to detect, verify, investigate, and analyze an incident are important to developing an effective containment and eradication strategy. Once an incident has been confirmed, resources can be assigned to investigate the scope, impact, and response needed. The detection and analysis phases determine the source of the incident and preserve evidence.

The general steps required for incident identification, detection, and analysis are to:

Review guidelines for departmental actions regarding unacceptable computer use and other InfoSec incidents - See University policy 91.003.
Determine whether an incident has occurred.

Coordination between the Information Security Office and the affected department is important to make sure that steps taken to verify the incident do not alter data that will be needed for further investigation.

Conducting an IT Risk Assessment enables departments to correlate IT resources with mission critical business processes and services. Using that information, it then becomes possible to characterize interdependencies and the consequences of potential disruptions, as well as to generate plans to eliminate or ameliorate risks.

Detection and analysis

The Information Security Office will work with the affected department to quickly analyze and validate each incident and perform an initial assessment to determine the incident’s scope, such as which networks, systems, or applications are affected; who or what originated the incident; and how the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being exploited). The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident.

A coordinated investigation may be required once an incident has been confirmed. The Information Security Office will identify and assign an individual to be the Incident Response Manager (IRM). The IRM will lead the incident response, is the point of contact for all matters relating to the incident and is responsible for coordinating the data required for documenting the investigation and gathering evidence. In some cases, Federal, State, or local law enforcement may be involved in an incident investigation. See Appendix I for contact information for the Federal Bureau of Investigations (FBI), Department of Homeland Security (DHS), state, campus, and local police.

Inter-departmental cooperation guidelines

University personnel may be alerted to a threat from an internal or external source. It is important to notify the Information Security Office once a threat has been detected.

The local systems administrator is responsible for fixing the problem on the machine(s). The Information Security Office may also detect a threat and alert the system custodian of record for the hardware or Ethernet port connection.
All incidents should be handled by departmental IT staff with the support of the Information Security Office and, if necessary, the CIRT.

See Appendix C: Compromise Questionnaire and Information Gathering - Information Needed from the User, and Appendix E: Guidelines for Reporting an InfoSec Incident.

Incident categorization, classification, and CIRT activation

The incident type and impact will determine the level of response needed by the University. The Information Security Office will work with departments to determine the appropriate response for each confirmed incident. The general steps required for incident categorization and classification are:

Categorize the incident based on type of incident, security objective, and impact.
Classify the incident as a local or enterprise incident.
Prioritize handling of the incident based on the Incident Response Classification Matrix
Activate CIRT if necessary. Report the incident to the appropriate internal personnel and external organizations.

COMMON CATEGORIES OF CYBER INCIDENTS

Incident type	Description
Unauthorized Access	When an individual or entity gains logical or physical access without permission to a university network, system, application, data, or other resource.
Denial of Service (DoS)	An attack that successfully prevents or impairs the normal authorized functionality of networks, systems, or applications by exhausting resources. This activity includes being the victim or participating in the DoS.
Malicious Code	Successful installation of malicious software (e.g., a virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating system or application. Agencies are NOT required to report malicious logic that has been successfully quarantined by antivirus (AV) software.
Improper or Inappropriate Usage	When a person violates acceptable computing policies.
Suspected PII Breach	If an incident involves personally identifiable information (PII) a breach is reportable by being merely Suspected. (Suspected PII incidents can be resolved by confirmation of a non-PII determination.)
Suspected loss of Sensitive Information	An incident that involves a suspected loss of sensitive information (not PII) that occurred as a result of Unauthorized Access, Malicious Code, or Improper (or Inappropriate) Use, where the cause or extent is not known.

Source: Incident Response and Management: NASA Information Security Incident Management

IMPACT DEFINITIONS

Potential impact
Security objective	Low	Medium	High
Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.	The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.	The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.	The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals
Integrity: Guarding against improper information modification or destruction and includes ensuring information non-repudiation and authenticity.	The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.	The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.	The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
Availability: Ensuring timely and reliable access to and use of information	The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.	The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.	The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

Source: FIPS Publication 199

Once an incident is classified, it is important to categorize the incident as a local or enterprise event.

Local events represent a risk to OHIO systems, networks, and data but are confined to a single or small number of departmental systems. An example of a local issue would be malware discovered on a departmental desktop or server. Local issues may even lead to data breaches if unencrypted sensitive data is stored on the compromised systems. Most cyber threats are identified, contained, and eradicated through coordinated efforts between the ISO and affected departments. Local events are the most common type of attack observed at OHIO.

Enterprise events are rare but have a large impact. A Distributed Denial of Service attack (DDoS) that degrades network performance in a manner that disrupts University operations is an example. This would be an enterprise-wide issue that would affect the entire University. Enterprise issues may require the activation of the Critical Incident Response Team (CIRT). CIRT team members may be drawn from many departments across the university and have knowledge of critical systems that can be leveraged to protect OHIO IT assets during an enterprise incident.

When multiple incidents occur simultaneously, the most serious or highest potential impact incidents should be handled first.

The incident classification is performed by the Incident Response Manager (IRM) using the Incident Response Classification Matrix.

Incident response classification matrix
Classification level (3=Most Severe)	Typical characteristics	Impact	Response	Activate CIRT?
3	DDoS attack against University Servers. Attacks against network infrastructure. Network disruption for a large segment of the OHIO population	An enterprise-wide attack involving multiple departments requiring local and enterprise administrator support from the affected departments.	CIRT directs, response coordinated by ISO. OHIO senior management, local sysadmin involved. Possible Legal Counsel, Law Enforcement involvement	Yes
2	Affects data or services for a group of individuals and threatens sensitive data, or involves accounts with elevated privileges with potential threat to sensitive data	Compromised PeopleSoft, Exchange, Active Directory, domain controller system administrator account, or Learning Management System (LMS) administrator account compromise	Response coordinated by ISO. Local Sysadmin. CIRT advised, Legal Counsel notified if PII breach.	Advised
2	Affects data or services of a single individual, but involves significant amounts of sensitive data	Faculty desktop with University defined sensitive data compromised, physical theft of computer/computer equipment	Response coordinated by ISO. Local Sysadmin. CIRT advised, Legal Counsel notified if PII breach.	No
1	Affects data or services of a group of individuals with no sensitive data involved	Compromise of an account with shared folder access	Local sysadmin, ISO notified, event logged, progress monitoring, Standard forensics performed if local admin is unable.	No
1	Affects data or services of a single individual with no sensitive data beyond their own involved; focus is on correction and/or recovery and education/future prevention	Compromised faculty machine w/no University defined sensitive data etc.	Local sysadmin, ISO notified, event logged, progress monitoring, Standard forensics performed if local admin is unable.	No
0	Occurrences of very minor or undetermined focus, origin and/or effect for which there is no practical follow-up	Network scans, personal firewall log reports, Snort reports, File Integrity Monitor, IDS/IPS reports	ISO monitors periodically, periodic summaries, vulnerability database maintenance, sends reports to central logging facility for trending weekly/monthly reports.	No

CIRT activation

The CIRT will only be activated if an incident has been confirmed to be affecting University IT systems/services at an enterprise or a multi-departmental level. Attacks against departmental servers do not necessarily require CIRT activation. Local events may be escalated to enterprise events if evidence warrants. The ISO has the authority to classify incidents as an enterprise threat.

Communications plan

Communications processes occur throughout the incident response phases and involve the initial reporting of the incident to relevant authorities, as well as ongoing communications with those impacted.

A communications plan is essential when dealing with a confirmed InfoSec incident. A good communication plan can help limit confusion and increase responsiveness by sharing action plans, updating University stakeholders, and providing transparency throughout the process. The plan should identify the stakeholders, those authorized to speak about the incident, the communication channels, the schedule of communication as well as procedures for notifying external organizations that are directly involved in the incident. A communications plan can reduce conflicting messages and focus efforts.

The University must develop a communications plan whenever a breach of Personally Identifiable Information (PII) has been confirmed. Such communications shall adhere to the processes outlined within the Administrative Procedure: Notification of a Data Security Breach.

Containment, eradication and recovery

Containment

Containment procedures attempt to actively limit the scope and magnitude of the attack. A vulnerability in a particular computer architecture can be exploited quickly. Containment involves acquiring, preserving, securing, and documenting all evidence.

Containment has two goals:

Prevent data from leaving the network via the affected machines.
Prevent attacker from causing further damage to OHIO information technology assets.

The ISO assigns a high priority to determining who the attackers are and what vector (port, software vulnerability, etc.) they are using to attack OHIO hosts. Once this information is obtained, the ISO will request a firewall/router block or physical disconnection to temporarily prevent an IP address, port or both from connecting to the OHIO network. This may disrupt other normal traffic, but this disruption will be kept to a minimum. Containing a cyber incident has a higher priority than maintaining normal business traffic. The following actions are taken during the containment phase:

Coordinate all activities with local system administrator. Possible actions include:

Upon direction by the IRM, the local system administrator can proceed to repair the system as
needed to return to normal business operations.
Consulting provided by the ISO to the local system administrator. The ISO will remain available to provide consulting support during the repair process.
The deployment of a small team from the ISO with the appropriate expertise to the site.
Securing the physical area on site if necessary.
Using Appendix C: Compromise Questionnaire and Information Gathering to guide documentation.
A review of the information provided by the system administrators.
Not allowing the system to be altered in any way. Maintaining a low profile in order to avoid tipping off the attacker.
Using a trusted system binary kit (Unix/Linux, Windows) to verify the system binaries have not been compromised.
Making a forensic copy of the system for further analysis. Ensuring that any backups are in a secure location.

Determine risk of continued operation. Possible actions include:

Disabling network access but leaving the system up. Disabling the port if the attack is ongoing or if the compromised system is attacking another site. The Network Infrastructure Team should utilize available tools to identify and disable the port.
Making a recommendation to the local management (faculty member, department head, dean, supervisor, etc.) regarding whether the affected system(s) should remain online. Attempting to restore operations as quickly as possible. However, if the compromised system threatens the integrity of the network or systems connected to the network, it should be disconnected from the net as soon as possible.
Changing all user and system credentials on the affected machine(s).

Back up the system.

In some cases, a forensic image disk will be requested by law enforcement or by the office of Legal Affairs. Contact the ISO to initiate the forensics process.
Use network backup systems to determine what files were changed during the event. Contact OIT Systems and Infrastructure for additional information.

Eradication

Eradication is the removal of malicious code, accounts, or inappropriate access. Eradication also includes repairing vulnerabilities that may have been the root cause of the compromise. We strongly recommend a complete re- installation of the OS and applications.

The general steps involved in the eradication phase of incident response are to:

Define eradication benchmarks o Consult various checklists for compromises. See Appendices B, C for general information
Identify and mitigate all vulnerabilities that were exploited
Remove malware, inappropriate materials, and other components
If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps to identify all other affected hosts, then contain and eradicate the incident for them
Reinstall OS, apply patches, reinstall applications, and apply known patches

Recovery

Once the incident has been contained and eradicated, recovery can start. This phase allows business processes affected by the incident to recover and resume operations.

The general recovery steps are:

If there was sensitive data on the affected machine, go to step 2. If there was not, go to step 4.
Follow the flow chart steps in Appendix A.
Reinstall and patch the OS and applications. Change all user and system credentials.
Restore data to the system.
Return affected systems to an operationally ready state.
Confirm that the affected systems are functioning normally.
If necessary, implement additional monitoring to look for future related Post-Incident Activity.

Incident closure

Documentation of a cyber incident and the steps taken to mitigate issues encountered are important. The documentation offers an opportunity to improve Incident Response processes and identify recurring issues.

Certain cyber incidents should be documented more thoroughly when their impact warrants. The ISO will identify those local incidents that should be more thoroughly documented. A follow up report and documentation is required for all enterprise level incidents.

Follow-up reports document the incident and include the lessons learned in order to preserve and expand knowledge. Reports are produced by the Information Security Office and/or the CIRT teams depending on the incident. The report should include:

Information about the incident type
A description of how the incident was discovered
Information about the systems that were affected
Information about who was responsible for the system and its data
A description of what caused the incident
A description of the response to the incident and whether it was effective
Recommendations to prevent future incidents
A discussion of lessons learned that will improve future responses
A timeline of events, from detection to incident closure

The follow-up report should be shared with CIO as well as other stakeholders deemed appropriate. A “Lessons Learned” meeting with all those involved in the handling and response of the incident should be held and is mandatory for enterprise level incidents.

Appendix A: Sensitive data response procedure

A detailed flowchart explaining the process of responding to data exposure

Appendix B: Checklist of major steps for incident response and handling

Detection and analysis phase
	Action	Completed
1.	Determine whether an incident has occurred
1.1	Analyze the precursors and indicators
1.2	Look for correlating information
1.3	Perform research (e.g., search engines, knowledge base)
1.4	As soon as the handler believes an incident has occurred, begin documenting the investigation and gathering evidence
2.	Prioritize handling of the incident based on the relevant factors (functional impact, information impact, recoverability effort, etc.)
3.	Report the incident to the appropriate internal personnel and external organizations.

Continued

Containment, eradication and recovery
	Action	Completed
4.	Acquire, preserve, secure, and document evidence
5.	Contain the incident
6.	Eradicate the incident
6.1	Identify and mitigate all vulnerabilities that were exploited
6.2	Remove malware, inappropriate materials, and other components
6.3	If more affected hosts are discovered (e.g., new malware infections), repeat the Detection and Analysis steps (1.1, 1.2) to identify all other affected hosts, then contain (5) and eradicate (6) the incident for them
7.	Recover from the incident
7.1	Return affected systems to an operationally ready state
7.2	Confirm that the affected systems are functioning normally
7.3	If necessary, implement additional monitoring to look for future related activity

Continued

Post-incident activity
	Action	Completed
8.	Create a follow-up report
9.	Hold a lessons learned meeting (mandatory for major incidents, optional otherwise)

Source: NIST Special Publication 800-61 revision 2

UNIX/LINUX checklist

This section is intended to provide guidance during the examination of a compromised system. Additional steps may be needed to examine a system. Please consult the Information Security Office before performing steps.

☐ Regain control of the system. Some options include disconnecting the system from the network and making an image copy of the system disk(s).

☐ Analyze the intrusion.

☐ Look for modifications made to system software and configuration files.

☐ Look for modifications to data.

☐ Look for tools and data left behind by the intruder.

☐ Review log files.

☐ Look for signs of a network sniffer.

☐ Check other systems on the local network.

☐ Check for systems affected on other local subnets or remote sites.

☐ Recover from the intrusion.

☐ Install a clean version of the OS on the affected system.

☐ Disable unnecessary services.

☐ Install all vendor security patches.

☐ Change all passwords.

☐ Improve the security of your system and network.

☐ Review the Center for Internet Security benchmark documents and the CERT.ORG Unix configuration guidelines checklist.

☐ Install security tools.

☐ Enable maximal logging.

☐ Install software firewall tools.

☐ Reconnect to the network.

Windows checklist

☐ Examine log and event files.

☐ Check for odd user accounts and groups.

☐ Look for incorrect group memberships.

☐ Look for incorrect user rights.

☐ Check for unauthorized applications starting at boot.

☐ Check system binaries with something like Tripwire.

☐ Check network configuration and activity.

☐ Check for unauthorized shares

☐ Examine jobs run by the scheduler service.

☐ Check for unauthorized processes.

☐ Look for unusual or hidden files.

☐ Check for altered permissions on files or registry keys.

☐ Check for changes in user of computer policies.

☐ Make sure the system has not been moved to a different Workgroup or Domain.

☐ Examine all other related systems.

Appendix C: Compromise questionnaire and information gathering

It is important to gather and record information during an incident. This helps with planning and assigning resources. Analysis of gathered information is also important to the incident closure process. The following questions are intended as an example to help with information gathering. Depending on the nature of the incident, it may be appropriate for additional questions to be considered.

Information needed about detection

What is the infection/intrusion type?
What time was the incident detected?
How was the infection detected?
Who detected the infection?
What is the incident machine IP address and DNS name?
Who is the IT Support for the incident machine?
Was a 4Help Ticket created?
What is the ticket number?
What time was the initial notification sent?
Was network access disabled?
Were people contacted? If so, who?

Information needed from the user

Gather user’s contact information. User (name, email, phone #)
What is the user’s job function?
What is the primary function of this department?
1. Who is the user’s manager / direct-report?
Does the user work with sensitive or covered PII data?
1. If yes, what types of sensitive or covered PII data?
How much sensitive data? (# of files, GBs, file types, location)
What files did the user access during the time of the incident?
Did user work with research data?
1. If so, what types of research data?
How much research data (# of files, size, file types, location)
Does the user use university or departmental enterprise systems?
1. If so, what level of access does the user have?
Does the user have access to shared network storage?
Are the shared drives automatically mounted?
Who else shares the data in those folders?
Did the user use encryption on files?
1. If so, what kind(s) of encryption and where are the keys? ISO may require access to encryption keys.

Questions about the infection

What was the user doing during the incident?
Did the user notice any strange things about the computer around that time?
Did the user receive any strange emails, or open any unknown attachments?
Did the user enter credentials (username, password) on any sites?
Did the user install any software?
Did the user receive any software updates?
Did the user’s antivirus software complain or alert?
Did the user notice a change in computer performance?
Did the user receive any strange Instant Messages?
Does the user use their computer for non-work related functions?
1. If so, what function(s)? Facebook/social media? Internet Radio? Email? Online Banking?

Information needed from departmental IT support

IT Support contact information (name, email, phone #)
Do they have shared drives?
Who has access to these drives?
What type of data is accessed or used by the system? FERPA, GLBA, University PII, etc.
Are they automatically mounted?
What types of security precautions have you placed on the system? (Firewall, Anti-Virus, Anti-Malware)
Is administrative access granted to the user?
What types of encryption are used?

Infection details and analysis

IT person (name, email, phone #)
Do they have shared drives?
Who has access to these drives?
Types of data (see above)
Are they automatically mounted?
What types of security precautions have been placed on the system?
What type of anti-virus is used?
Does the user have administrative access?
Is there file-based encryption? (think PGP Desktop, TrueCrypt, Native Encryption: e.g. MS Office or Acrobat)
1. What type of encryption?

Incident analysis

When was the first sign of an infection?
Was this sign indicative of the initial infection?
What is the confidence level of the initial infection notice?
Is a copy of the malware package available?
How long was the machine online after the first sign of an infection?
How long before the IT staff was notified?
How many Command & Control (C&C) servers are involved?
Where are they located?
How much data went to each C&C server?
Are other devices on the network communicating with these C&C servers?
How much data was transferred between the time of the believed initial infection and when the device was pulled off the network?
Who were the top talkers?
Are they legitimate top talkers?
What other network security alerts were triggered by the device?
How much traffic remains for the incident period after the top talkers are removed?

Information Security Office procedure for notification of outside organizations involved in a InfoSec Incident

It may be necessary to contact an outside organization to let them know that a machine under their control may be having a negative impact on OHIO’s IT systems and networks. The steps provided below are intended to guide communication.

Determine technical and administrative contacts of the source machine.
Determine WHOIS contact for upstream provider, if one exists.
Determine if a US-CERT or “abuse” email address exists if the source machine is from a foreign country.
Determine if other campus sites have been attacked/scanned by the source machine.
Send a concise email to the WHOIS contact of the source machines. Include:
- The source site’s US-CERT
- Copy for IT Security Office
- Copy affected department(s) and personnel.
- Log excerpts in text of e-mail. Do NOT send attachments or HTML.

Appendix D: University policies and standards

Available at https://www.ohio.edu/oit/security/policy-and-practices

OHIO Legislation

1349.19 Private disclosure of security breach of computerized personal information data. • OHIO Sunshine Law

Appendix E: Guidance on reporting an InfoSec incident

What to report

A cyber incident should be reported if it resulted in either:

Exposure of legally protected data in University databases, such as financial information protected by GLBA,
Health information protected by HIPAA.

and/or

Major disruption to normal agency activities carried out via the University’s data communications, such as network unavailability for all or significant portions of an agency due to a denial of service (DoS) attack.'

You should report events that have a real impact on your organization. An IT security incident includes, but is not limited to the following events regardless of platform or computer environment, when:

Damage is done
Loss occurs
Malicious code is implanted
There is evidence of tampering with data
Unauthorized access has been gained or repeated attempts at unauthorized access have been made
(from either internal or external sources)
There has been a threat or harassment via an electronic medium (internal or external)
Access is achieved by the intruder
Web pages are defaced
A user detects something noteworthy or unusual (a new traffic pattern, new type of malicious code, a specific IP as the source of persistent attacks)
There is a denial of service attack on the agency
Virus attacks adversely affect servers or multiple workstations
Other information technology security incidents occur that could undermine confidence and trust in the OHIO's Information Technology systems

CIO: Chief Information Officer
CIRT: Critical Incident Response Team
SMIS: Senior Manager, Information Security
DDoS: Distributed Denial of Service
ES: Enterprise Systems
FERPA: Family Educational Rights and Privacy Act
GLBA: Gramm-Leach-Bliley Act
HIPAA: Health Insurance Portability and Accountability Act
IDS: Intrusion Detection System
IMS: Identity Management Services
IPS: Intrusion Prevention System
IRM: Incident Response Manager
ISO: Information Security Office
IT: Information Technology
ISO: Information Security Office
ITAR: International Traffic in Arms Regulations
ITRM: Information Technology Resource Management
NIST: National Institute of Standards and Technology
PCI-DSS: Payment Card Industry Data Security Standard
PII: Personally Identifiable Information
PIRN: Personal information requiring notification
URL: Universal Resource Locator
US-CERT: United States Computer Emergency Readiness Team
OHIO: Ohio University