91探花

This document assists 91探花 (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.

 

Record of changes

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鈥檚 needs. The Information Security Governance Committee and the Information Security Office should review all changes.

Section 1: Introduction

Back to top

Authority

Back to top

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 91探花 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 91探花鈥檚 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 91探花 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

Back to top

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鈥檚 operational, financial, or reputational standing and/or the ability to comply with regulatory or legal requirements.

Audience

Back to top

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 91探花.

Section 2: Cyber incident response capabilities

Back to top

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 鈥渜uarterly 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

Back to top

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

To support the University鈥檚 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 91探花 Critical Incident Response Team (CIRT).

Strategy and goals for cyber incident response

Back to top

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鈥檚 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.
• 鈥淟essons 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

Back to top

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 鈥淩egarding 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
• 91探花 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鈥檚 approach to InfoSec incident response

Back to top

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 .

Information Security Office contact information: 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鈥檚 license numbers, passport numbers, medical information, or FERPA data.
• Disclosure of the system鈥檚 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 鈥淚nternet 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鈥檚 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

Back to top

This section describes the major phases of the incident response process鈥攑reparation, 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

Back to top

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 .

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

Back to top

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鈥檚 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

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

IMPACT DEFINITIONS

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.

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

Back to top

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:

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

Incident closure

Back to top

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:

1. Information about the incident type
2. A description of how the incident was discovered
3. Information about the systems that were affected
4. Information about who was responsible for the system and its data
5. A description of what caused the incident
6. A description of the response to the incident and whether it was effective
7. Recommendations to prevent future incidents
8. A discussion of lessons learned that will improve future responses
9. 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 鈥淟essons 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

Back to top

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

Back to top

Continued

Continued

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

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.

鈽� 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

Back to top

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

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

Information needed from the user

1. Gather user鈥檚 contact information. User (name, email, phone #)
2. What is the user鈥檚 job function?
3. What is the primary function of this department?
   1. Who is the user鈥檚 manager / direct-report?
4. Does the user work with sensitive or covered PII data?
   1. If yes, what types of sensitive or covered PII data?
5. How much sensitive data? (# of files, GBs, file types, location)
6. What files did the user access during the time of the incident?
7. Did user work with research data?
   1. If so, what types of research data?
8. How much research data (# of files, size, file types, location)
9. Does the user use university or departmental enterprise systems?
   1. If so, what level of access does the user have?
10. Does the user have access to shared network storage?
11. Are the shared drives automatically mounted?
12. Who else shares the data in those folders?
13. 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

1. What was the user doing during the incident?
2. Did the user notice any strange things about the computer around that time?
3. Did the user receive any strange emails, or open any unknown attachments?
4. Did the user enter credentials (username, password) on any sites?
5. Did the user install any software?
6. Did the user receive any software updates?
7. Did the user鈥檚 antivirus software complain or alert?
8. Did the user notice a change in computer performance?
9. Did the user receive any strange Instant Messages?
10. 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

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

Infection details and analysis

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

Incident analysis

1. When was the first sign of an infection?
2. Was this sign indicative of the initial infection?
3. What is the confidence level of the initial infection notice?
4. Is a copy of the malware package available?
5. How long was the machine online after the first sign of an infection?
6. How long before the IT staff was notified?
7. How many Command & Control (C&C) servers are involved?
8. Where are they located?
9. How much data went to each C&C server?
10. Are other devices on the network communicating with these C&C servers?
11. How much data was transferred between the time of the believed initial infection and when the device was pulled off the network?
12. Who were the top talkers?
13. Are they legitimate top talkers?
14. What other network security alerts were triggered by the device?
15. 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鈥檚 IT systems and networks. The steps provided below are intended to guide communication.

1. Determine technical and administrative contacts of the source machine.
2. Determine WHOIS contact for upstream provider, if one exists.
3. Determine if a US-CERT or 鈥渁buse鈥� email address exists if the source machine is from a foreign country.
4. Determine if other campus sites have been attacked/scanned by the source machine.
5. Send a concise email to the WHOIS contact of the source machines. Include:
   • The source site鈥檚 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

Back to top

Available at /oit/security/policy-and-practices

OHIO Legislation

Appendix E: Guidance on reporting an InfoSec incident

Back to top

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鈥檚 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:

1. Damage is done
2. Loss occurs
3. Malicious code is implanted
4. There is evidence of tampering with data
5. Unauthorized access has been gained or repeated attempts at unauthorized access have been made
6. (from either internal or external sources)
7. There has been a threat or harassment via an electronic medium (internal or external)
8. Access is achieved by the intruder
9. Web pages are defaced
10. 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)
11. There is a denial of service attack on the agency
12. Virus attacks adversely affect servers or multiple workstations
13. Other information technology security incidents occur that could undermine confidence and trust in the OHIO's Information Technology systems

Appendix F - Contact information for local police

Back to top

OHIO University Police (740-593-1911)

Appendix G: Generalized cyber incident escalation and workflow diagram

Back to top

Appendix H: Acronyms

Back to top

• 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: 91探花