Document Version	2.1
Effective Date	TBD
Review Date	TBD
Security Unit Liaison	Mark Giuffrida
Approval Authority	Dan Maletta, CoE Executive Director of Information Technology
Contact	Mark Giuffrida
Telephone	(734) 936-1825
E-mail	[email protected]

Overview

This document describes the College of Engineering (CoE) process for reporting and responding to an information security incident. It specifies appropriate incident response actions based on the nature and severity of the incident, the data involved, and other factors. This process is a unit-level implementation of the university Information Security Incident Reporting Policy (SPG 601.25) and the IT Security Incident Management Guidelines for U-M Units.

This process applies to information security incidents relating to all data networks, network hosts, applications, workstations and servers managed by CoE. It also applies to computers and devices not administered by CoE, but which are used by CoE employees or other associated individuals to access information resources managed by the university.

Information security incidents covered under this procedure meet the definition of information security incidents in SPG 601.25.

Purpose

The goals in managing an incident are to:

Collect as much information as possible about the nature of the incident;
Block or prevent escalation of the damage caused by the incident, if possible;
Repair, or coordinate the repair of, damage caused by the incident;
Preserve evidence of the incident, as appropriate;
Restore service as soon as possible;
Ensure that incidents are promptly reported and escalated per SPG 601.25;
Take proactive steps to mitigate future incidents.

Definitions

Information Security Incident

As defined in SPG 601.25, an information security incident is an attempted or successful unauthorized access, use, disclosure, modification or destruction of information; interference with information technology operation; or violation of explicit or implied responsible use policy (as defined in SPG 601.07). Examples of information security incidents include (but are not limited to):

Computer security intrusion
Unauthorized use of systems or data
Unauthorized change to computer or software
Loss or theft of equipment used to store private or potentially sensitive information
Denial of service attack
Interference with the intended use of information technology resource
Compromised user accounts

Information Security Roles and Responsibilities

CoE has the following information security roles:

College of Engineering (CoE) Unit Staff

This includes but is not limited to those with roles formerly referred to as IT Security Administrator or IT Security Coordinator in the unit.

As service owners and users of IT resources, CoE staff are expected to recognize potential security incidents. Responsibilities include:

Promptly reporting all security incidents to both [email protected] and unit IT before taking any remediation steps;
Working with the CAEN Security Group to follow this CoE Security Incident Response Process. This includes checking with CAEN prior to communicating with any external unit or department about issues or problems that may have security related components;
Incident information is considered sensitive data and should be appropriately protected;
Ensuring incidents are promptly reported to management and appropriate business owners as appropriate;
Incidents involving suspected child pornography should be reported directly to the Department of Public Safety and Security (DPSS).

CAEN Security Group

Comprised of IT security professionals within CAEN assigned to handle the information security needs for CoE. Responsibilities include:

Receiving notification of detected or reported information security events and incidents from users and service owners of IT resources, automated detection systems, or other sources;
Maintaining [email protected] as the mailbox to report all security incidents within CoE;
Accepting, logging, and tracking all security incidents. Information about security incidents will be retained for five years;
Executing incident mitigation and containment actions including but not limited to black-holing of systems when owner(s) cannot be reached in 24 hours;
Providing expert technical advice and guidance for unit IT in their remediation efforts;
Coordinating discovered incidents that did not originate in CoE with the appropriate CoE unit IT provider or group;
Identifying post-incident security training and mitigation needs;
Coordinating all incident-related communications, including to senior management, business process and service owners, CoE staff, and external units such as the Office of Public Affairs.

Procedure

The CAEN Security Group will follow the Incident Response Procedure and capture all relevant data. This data will then be aggregated and stored in a secure tracking system.

The following steps need to be taken in response to an incident. Although they are listed in a typical order, some steps may be taken concurrently or in a different order, depending on the circumstances. Further, the incident information logged throughout the incident may need to be updated periodically, and specific information, such as severity level, may change as further analysis is performed.

Initial Report and Assignment

A. Initial Event Notification

An information security incident begins when a security-related event is reported. This could come from an automated system diagnostic, a trouble ticket submitted by a user, or other source. Security incidents should be sent to [email protected]. The CoE staff reporting the incident should not take any containment steps before reporting the incident. The person in the CAEN Security Group who receives the initial notification opens an incident log in the tracking system (with a unique incident identifier) and adds available details, including some preliminary assessment of the incident severity, if it can be immediately determined.

B. Assign Incident Administrator

The incident is assigned to an incident administrator, a member of the CAEN security group who is responsible for investigating the incident and coordinating the response until the incident is resolved and closed. When an incident administrator has been confirmed, that individual will promptly contact the person who reported the incident.

C. Detail Incident Log Entry by CAEN

Tracking system incident documentation should include the data fields found in the IT Security Incident Management Guidelines for U-M Units. Use the table below to clarify the data fields that are to be initially provided. This information should be entered and updated as necessary in the tracking system.

Information to be Documented	Description/Note
Date of event
Time of event	Including time zone
Who or what reported the event	Include full name, location, telephone number, and email of person reporting the incident. If an automated system reported the event, include the name of software package, name of the host where the software is installed, physical location of the host, host or CPU ID of the host, network address of the host, and MAC address of the host if possible.
Detailed description of the event	Include as much information as available.
Identification of the host(s)	Specify the host or system that the event is related to/occurred on. Include the hardware manufacturer, operating system type and version, name of the host, UM asset ID tag, physical location of the host, host or CPU ID of the host, network address of the host, and MAC address of the host if possible.
Names or Descriptions of Others	If the event involves suspicious modifications or behavior of a computer that is accessible to many people and a person is reporting the incident, then ask the person for the names or descriptions of others in the area prior to and just after the event.
Physical Security Controls	If there is limited physical access to the computer, document the physical security controls that limit access (ask the person reporting the event to describe what they have to do to access the computer).

Notification and Escalation

There are many factors to weigh in determining appropriate notification and escalation of an incident, including the severity of the incident, the scope of the compromise, cost to the university of supporting a criminal investigation, and the proprietary and confidential university information that might become public if a criminal investigation occurs. When evidence shows that CoE has been victimized by a computer or communications crime, a thorough investigation usually involving law enforcement must be performed. In coordination with appropriate CoE staff, CAEN will coordinate a forensic investigation which may include use of the CoE IR Toolkit when necessary. The incident administrator takes the following steps:

Review and verify incident documentation, event reports and information entered in the Incident Tracking System;
Verify the assigned severity level based on available information;
Acquire the resources necessary to respond to the incident;
Notify the University Incident Response Coordinator in IIA of any serious incidents (see link below for detailed list of Contacts)
Notify the HIPAA Compliance Officer of all incidents involving PHI;
Notify UMOR of all incidents involving human subjects’ personal information;
Participate in a Computer Security Incident Response Team (CSIRT) that may be convened relating to a serious incident in CoE.

Sensitive Data Incident Response Contact Info

Severity Assessment

The IT Security Incident Management Guidelines for U-M Units defines two severity levels for information security incidents: serious and non-serious. For serious incidents, the owner(s) or operator(s) of the affected hosts should be directed not to use or modify the system in any way until the incident administrator contacts them and instructs them to do so. Examples of non-serious incidents include a malware infection on a workstation that does not contain sensitive information, a compromised web server that is not mission critical, or a stolen laptop that does not contain sensitive information. CAEN will prioritize responding to serious incidents over non-serious incidents.

Non-serious Incidents

Once the incident has been classified as a non-serious incident, the following procedure will be pursued. The incident administrator classifies the incident severity based on the following:

a. Sensitivity of potentially compromised data

b. Legal issues

c. Magnitude of service disruption

d. Threat potential

e. Expanse – how widespread the incident is

f. Public engagement – level of potential public interest or concern

Containment: The incident should be contained as quickly as possible, pending further investigation by CAEN. The Incident Response Coordinator and the incident reporter will devise a plan to contain the incident. In most cases this can be accomplished by removing the network cable of a suspected compromised system. In the case of a serious incident, do not remove the network cable as this removes the option of performing more invasive forensic monitoring of an intruder.

Analysis: The Incident Response Coordinator will work with the appropriate CoE IT end users to identify the root cause of the incident. This includes answering the following questions about the incident:

How long was the incident active before it was noticed?
From where did the incident originate?
What level of unauthorized access, if any, was gained?
Were any other University resources affected?

Closure: Based on the characteristics of the incident, a plan will be devised to restore affected systems to normal operation and prevent reoccurrence. The appropriate business owners will be notified and the incident will be closed. CAEN will aggregate statistics about non-serious incidents and provide periodic reports to leadership.

Serious Incidents

The following questions are intended to help classify serious risks, and are meant as specific examples of applying severity levels to security incidents:

a. Is sensitive, confidential or privileged data at risk?

If there is imminent danger (the act is in progress) that sensitive, confidential or privileged information can be read, modified, or destroyed by an unauthorized entity or the disclosure or access already occurred, then assign the incident severity level serious. Reference: Sensitive Data Guide to IT Services.

b. Is business continuity at risk?

If there is imminent danger of disruption of business due to security issues or malicious acts or the disruption is in progress, then assign the incident severity level serious.

c. Does the incident involve Protected Health Information (PHI)?

The Health Information Portability and Accountability Act (HIPAA) sets strict guidelines on the release of the health information of patients. Any violation of HIPAA standards is assigned a serious severity level and the HIPAA Compliance Officer is contacted.

d. Does the incident involve personal information about a human subject?

If personally identifiable human subject information is potentially compromised, the incident is assigned severity serious and the University of Michigan Office of Research (UMOR) is contacted.

e. Does the incident require additional notification internally to U-M or externally?

Some data types have additional, immediate notification requirements. For example, incidents regarding export controlled information require notification to the CoE Compliance Office. Incidents regarding PCI DSS (credit card) data must be reported to the university Treasurer’s Office. Refer to Sensitive Data Incident Notification Contacts for a complete list.

Notification of serious incidents to IIA ([email protected]) and the CAEN Security Group ([email protected]) should occur as soon as possible and no later than 24 hours from the time the incident was initially detected. Notification of serious incidents should include the data fields specified above.

Containment: After assessing that an incident has occurred and notifying the appropriate parties, the next step is to contain the damage. This procedure may be unique for each incident and incident administrators should use their best judgment when devising a containment plan.

In the case of a serious incident, containment includes restricting access to the affected systems or otherwise ensuring that university resources are protected while the incident is under analysis. The longer the perpetrator of an incident has access to or control of a system, the higher the risk of long-term negative impact to the university. In the case of non-serious incidents, an appropriate level of containment, if any, should be applied. In certain cases, gathering information about an active attack may be prioritized over containing an incident.

For example, if the serious incident is network-based, the incident administrator should work with the appropriate Business Owners and administrators of the system to plan a network disconnection of the affected systems. Since this will affect business continuity within CoE, the incident administrator should ensure that the Business Owners understand the potential impact of the incident, the implications of disconnecting the systems from the network, and, if possible, include a timeline for re-enabling access to the system. If the appropriate parties are unavailable, or an agreement cannot be reached, the incident administrator may unilaterally enact a containment plan. If possible, the system should remain powered on but with its network access restricted. Turning a system off could erase potentially valuable volatile data. Actually disconnecting the system from the network could involve physically removing the network cable or reconfiguring network hardware to disallow access to the system. Every possible means of remote access should be disabled, including every network port and modem.

Once disconnection is complete, it is important to verify that the system is indeed unreachable by testing remote connectivity. If the incident involves a network-based denial of service attack, containment may be more difficult. The incident administrator should coordinate with upstream network service providers to identify the source of the problem and devise a containment plan. The containment plan, the parties involved, the actions taken, who took them, and when should be included in a detailed log entry in the Incident Tracking System.

Analysis: Analysis will vary greatly from incident to incident, but the overall methodology should be consistent. If a serious incident involves law enforcement, CAEN will work with IIA and DPSS to ensure appropriate measures are taken when gathering and handling forensic evidence. The incident administrator should analyze the incident in order to answer the following:

What was the incident and how did it occur?
From where did the incident originate?
What level of unauthorized access, if any, was gained?
Did an unauthorized party access sensitive data?
Were any other university resources affected?

A variety of tools should be used to collect information about the affected systems. The incident administrator should carefully weigh the side effects of collecting information. For instance, running a virus scanner on a potentially compromised host will overwrite the last access time for every file scanned, forever losing valuable information. If at any point it is determined a detailed forensic analysis is appropriate, the incident coordinator may employ various forensic toolkits in the investigation which may include use of the CoE IR Toolkit. In the case of a compromised host, information such as system logs, application logs, and active network connections will aid in reconstructing the incident. Other information that is stored outside the host being investigated, such as firewall logs, network logs, or IDS (intrusion detection system) alerts should be gathered and correlated. A log in the Incident Tracking System should be kept detailing the methodology and results of the analysis. If any information is collected, include what it is, who acquired it, how it was acquired, and when it was acquired.

Closure:

Complete Incident Documentation in Incident Tracking System
1. The incident administrator should document any hypothesis, how evidence supports or contradicts it, actions taken to discover evidence or test the hypothesis, important or influential interactions with other people, relevant thoughts at the time, and anything else that will prompt accurate recall of the investigation. The final incident report should include the time and date for each entry in the incident notes, as well as the following information:
  1. How the incident was detected
  2. Dates
    1. Inferred date of compromise
    2. Date the compromise was detected
    3. Date the incident was finally resolved
  3. Names

1. People added to the Incident Roles for this incident
2. Person responsible for the IT Resource

Person compromising the resource, if known
Scope

1. Cause of the incident
2. Impact of the incident
3. Nature of the resolution

Proposed improvements to security systems

All logs and data associated with the incident should be saved in accordance with CoE policies unless otherwise required by IIA. Forensic files, such as dumps or traces, should be collected and stored in a secure manner.
Sensitive Data Status of Incident Information

Due to the sensitivity of incident-related information, strict authorization and access controls will be maintained to ensure information is available only to authorized staff. The Chief Information Security Officer is the data steward and manager for IT security-related information and the ultimate authority for determination of access to the information and data.
Lessons Learned Review

For all serious level incidents, a Lessons Learned Review must be conducted that will typically use information captured in the Incident Tracking System. The review documentation should contain detailed information about the event, investigation, and conclusions. All data used in the review should reference information collected and be verifiable.
Executive Summary Report

Once a serious incident is closed, an Executive Summary Report is required. This report will be generated and provided to executive management, and other groups involved in the incident response. The Executive Summary Report should contain:
1. A high-level description of the incident and its scope
2. The impact on the University
3. Actions taken or planned for to prevent further occurrences
4. Recommendations for further action

References

Responsible Use of Information Resources (SPG 601.07)

Describes University community responsibilities for exercising high ethical standards when accessing and handling University IT resources. Violations may constitute security incidents.

Institutional Data Resource Management Policy (SPG 601.12)

Sets policies and responsibilities for managing and protecting institutional data resources.

Information Security Incident Reporting (SPG 601.25)

Requires prompt reporting of all security incidents and central reporting of serious incidents.

Information Security Incident Management Guidelines for University Units

Sensitive Data Guide to IT Services