This document describes the College of LSA procedure for responding to an information (technology) security incident (hereafter referred to as "incident"). It specifies appropriate incident response actions based on the nature and severity of the incident, the data involved, and other factors. The procedure supplements the University’s Information Security Incident Reporting Policy (SPG 601.25), and the Information Security Incident Management Guideline.
This procedure applies to incidents relating to all data networks, network hosts, workstations, printers, mobile devices and servers administered by the College of LSA. It also applies to computers and IT devices not administered by the College, but which are used by LSA employees or other individuals associated with the College to access information resources managed by the University.
Incidents covered under this procedure meet the definition of information security incidents in SPG 601.25.
The LSA Security Team (LSA.Security) is responsible for handling information security incidents within the College of LSA. The goals of LSA.Security with regard to incidents are to:
Terms used in this document may be found in the Data Management and Protection Common Definitions here. See SPG 601.25 for the definition of an information security incident.
Standard information security roles are explained in Data Management and Protection Roles and Responsibilities.
The College of LSA has the following information security roles.
LSA.Security is the group of IT security professionals who have successfully completed the Information and Infrastructure Assurance (IIA) security administrator training (or equivalent), and are assigned to handle the IT security needs for the College of LSA. This group also includes other pertinent LSA IT staff members who need to know about incidents as they happen.
Responsibilities include:
The LSA Security Administrators are members of the LSA.Security Team who (in addition to the above) are responsible for coordinating incident response for the College of LSA.
Responsibilities include:
Note: Once an incident is classified as SERIOUS, the LSA Security Coordinator assumes the responsibility of being the focal point for incident communications.
The LSA Security Coordinator is the manager or senior member of LSA.Security who is also specifically designated as the Information Security Coordinator for the College of LSA. The LSA Security Coordinator also advises the Senior Manager for LSA IT.
Responsibilities include:
LSA.Security will use the security technologies available to respond to the incident. This may include data traffic interception, collection, redirection, or system disconnection. In an external attack, the College of LSA will work with law enforcement agencies and upstream data service providers/ as appropriate/ to stop an attacker’s access. In an internal attack, the College of LSA will work with Departmental System Administrators and/or the Computer Support Group to stop an attacker’s access.
LSA.Security will follow the Incident Response Procedure and capture all relevant data. This data will then be aggregated in a secure database to be shared with law enforcement and IIA as necessary.
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. Furthermore, 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.
An incident begins when an IT security-related event is reported to LSA.Security. This could come from an email, automated system diagnostic, trouble ticket submitted by a Data User, or some other means.
The person on the LSA.Security team who receives the initial notification opens an Incident Log in the LSA Security Incident Tracking Database with a unique incident identifier and adds available details, including some preliminary assessment of the incident severity, if one can be immediately determined.
According to College of LSA procedure, the incident is assigned to a LSA Security Administrator, a member of the LSA.Security Team, who is responsible for investigating the incident and/or coordinating the response with appropriate unit personnel until the incident is resolved and closed.
Once an incident has been confirmed by appropriate unit personnel, a LSA Security Administrator will contact the person or group who reported the incident, and provide them with detailed information about incident response, actions, and resolution,
Incident documentation should include the Incident Data Fields found in the Information Security Incident Management Guideline. Use the table below to clarify the data fields that are initially provided. This information should be entered and updated, as necessary, in the LSA Security Incident Tracking Database (a ServiceLink queue).
Information to be Documented | Description/Note |
Date of Event | |
Time of Event | Include the time zone. |
Who or What Reported | If a person reported the event, include their fill name, location, telephone number, event number, and email. If an automated system reported the event, include the name of the software package, name of the host where the software is installed, physical location of the host, host/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 possible. |
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, U-M asset ID tag, physical location of the host, host/CPU ID of the host, network address of the host, and MAC address of the host if possible. If the host has a modem connected to it, document the telephone number of the connected line or the wall jack number. |
Names or Descriptions of Others | If the event involves suspicious modifications or behavior of a computer that is accessible to pany 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. |
DPS Case Number | If this has been reported to DPS, include the case number and date reported. |
The Information Security Incident Management Guideline defines three severity levels for information security incidents: Low, Medium, and Serious. LSA.Security will also track Informational-level security incidents for internal reporting purposes.
Informational- and Low-severity incidents should be tracked for statistical aggregation purposes and do not require taking the additional steps described below.
The LSA Security Administrator classifies the incident severity based on the following:
The following assessment questions are intended to help classify serious risks, and are meant as specific examples of applying severity levels to security incidents:
For SERIOUS incidents, the owner(s), operator(s), and/or technical support staff of the affected hosts should be directed NOT to use or modify the system in any way until the LSA Security Administrator contacts them and instructs them to do so. Pulling power cords and network cables or shutting down a system during a serious incident may destroy evidence that would compromise a subsequent investigation and/or potential conviction.
Note: An incident severity classification may change based on subsequent events or greater knowledge of what happened during the incident.
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.
The LSA Security Administrator must notify the LSA Security Coordinator of any SERIOUS or MEDIUM incidents in a timely manner.
The LSA Security Coordinator takes the following steps:
Notification of SERIOUS incidents (to IIA, HIPAA, or UMOR) should occur as soon as possible and no later than 24 hours from the time the incident was initially reported. Notification of SERIOUS incidents should include the data fields specified in the Information Security Incident Management Guideline.
For SERIOUS incidents, the LSA Security Coordinator confers with LSA Senior Leadership and the University Chief Information Technology Security Officer (CITSO) at IIA to determine whether the incident warrants legal action and whether the Department of Public Safety and the Office of General Counsel need to be contacted. If necessary, due to absence or unavailability, the LSA Security Coordinator should jump to the next level in the LSA "chain of command" to insure LSA Leadership is informed. The CITSO informs the Office of the Vice President for Communications of all serious incidents. The LSA Security Coordinator is responsible for periodically communicating the ongoing status of the response and investigation to the CSIRT, IIA, unit management, and law enforcement as needed.
College of LSA Contacts
Condition | Contact(s) | Contact Information |
Any SERIOUS incident | IIA | security@umich.edu |
LSA Senior Leadership | dsweetma@umich.edu | |
Incident involves Protected Health Information | University HIPAA Officer | UMHS-Compliance-IT-Sec@med.umich.edu; |
Incident involves human subject research or other sensitive research information | U-M Office of Research (UMOR) | OVPR-IT-Sec@umich.edu |
U-M Institutional Review Board (IRB) | irbhsbs@umich.edu | |
Incident involves criminal activity | U-M Police Department (UMPD) | http://police.umich.edu 734.763.3434 |
Office of General Counsel (OGC) | ovpgc@umich.edu | |
Other contacts as necessary | Business Owners IT Service Providers Other Unit contacts |
U-M Treasurer's Office treasury@umich.edu LSA Assistant Dean for Budget, James Penner-Hahn jeph@umich.edu LSA Facilities Lead, Robert Johnston rjohnstn@umich.edu |
Incident may be picked up by the media | LSA Development, Marketing and Communications | LSA Public Information Specialist, Brian Short brshort@umich.edu |
Office of Public Affairs | public.affairs@umich.edu |
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 LSA Security Administrator should use their best judgment when devising a containment plan. The LSA Security Administrator may choose to coordinate the containment plan with IIA.
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 action should be applied.
For example, if the SERIOUS incident is network-based, 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 the College of LSA, ensure the Business Owners understand the potential impact of the incident and the implications of disconnecting the systems from the network. 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 LSA Security Administrator should coordinate a plan with the LSA Security Coordinator and, if necessary, the Senior Manager for LSA IT. 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, 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 LSA Security Administrator should coordinate with upstream network service providers to identify the source of the problem and devise a containment plan.
Include a detailed log entry in LSA Incident Tracking Database of the containment plan, the parties involved, the actions taken, who took them, and when.
Analysis will vary greatly from incident to incident, but the overall methodology should be consistent. If a SERIOUS incident involves law enforcement, DPS and IIA will work with the College of LSA to ensure appropriate measures are taken when gathering and handling forensic evidence. For other SERIOUS incidents, LSA Security Administrator may choose to involve IIA in the analysis. For non-SERIOUS incidents, LSA Security Administrator should perform an appropriate level of analysis.
The incident should be analyzed by LSA Security Administrator in order to answer the following:
A variety of tools should be used to collect information about the affected systems. The LSA Security 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 LSA Security Administrator should contact IIA.
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 alerts should be gathered and correlated.
Please see Appendix A for OS specific commands and utilities for use with Incident Handling & Response.
A log in LSA Incident Tracking Database 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.
Using information collected in the preceding steps, the artifacts left by the intrusion must be completely removed from all affected systems. This can be very difficult and may require a complete rebuild of one or more systems. The vulnerability that led to the compromise of the system should be removed or at least addressed. Not until these steps have been completed should the affected system(s) be put back on the network.
Depending on the type of compromise, it may be necessary to implement additional, temporary monitoring tools or scripts as restored systems are brought back online to help prevent re-infection.
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. Include the time and date for each entry in the incident notes, as well as the following information:
The College of LSA is required to notify IIA when a SERIOUS incident has been closed. Include relevant documentation from the LSA Incident Tracking Database as appropriate.
All logs and data associated with the incident should be saved in accordance with the College of LSA policies. Forensic files, such as dumps or traces, should be collected and stored in a secured folder.
For all MEDIUM and SERIOUS level incidents, a Lessons Learned Review must be conducted, which will typically use information captured in the LSA Security Incident Tracking Database. 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.
For SERIOUS incidents, the Lessons Learned Review will take place in a private meeting between IIA and the LSA.Security no later than 72 hours after the conclusion of the SERIOUS incident.
Once a SERIOUS incident is closed, an Executive Summary Report is required. This report will be generated by the LSA Security Coordinator and provided to IIA, executive management, and other groups involved in the incident response.
The Executive Summary Report should contain:
TECHNOLOGY SERVICES
G155 Angell Hall, 435 South State St, Ann Arbor, MI 48109–1003
734.615.0100
LSATechnologyServices@umich.edu