Policies and Guidelines Supported

University of Michigan

• Information Security Incident Management Guidelines (PDF)
• SPG 601.25, Information Security Incident Reporting Policy
   

College of LSA

• Technology Services's Security Policy (PDF)
• RIAA/MPAA Infringement Notice Response

Purpose

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.

Scope

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.

Goals

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:

• 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.
• Restore service as soon as possible.
• Preserve evidence of the incident, as appropriate.
• Ensure that incidents are promptly reported and escalated per SPG 601.25.
• Take proactive steps to mitigate future incidents.

Definitions

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.

Information Security Roles and Responsibilities

Standard information security roles are explained in Data Management and Protection Roles and Responsibilities.

The College of LSA has the following information security roles.

The LSA Security Team (LSA.Security)

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:

• Receiving notification of detected or reported information security events and incidents from IT Resource Users, automated detection systems, or other sources.
• Accepting, logging, and tracking incidents.
• Providing guidance and/or technical assistance to Technology Services professionals who are tasked with responding to incidents in their respective units.
• Providing guidance and/or technical assistance to Technology Services professionals who are tasked with executing incident mitigation and containment actions within their units.
• Performing other core security services and risk assessments for LSA.
• Alerting LSA Senior Leadership when sensitive data is at potential risk of exposure.
• Maintaining the LSA Security Incident Tracking Database.
• Forwarding discovered incidents that didn’t originate in the College of LSA to the appropriate unit or to security@umich.edu.

College of LSA Security Administrators

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:

• Serving as the focal point for tracking, investigating, and coordinating incident response for assigned incidents with in the College of LSA.
• Serving as the focal point for incident status reporting and communications for the College of LSA.
• Reporting SERIOUS and MEDIUM incidents to the LSA Security Coordinator and other parties as appropriate.

Note: Once an incident is classified as SERIOUS, the LSA Security Coordinator assumes the responsibility of being the focal point for incident communications.

College of LSA Security Coordinator

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:

• Serving as the LSA focal point for SERIOUS incident communications.
• Ensuring LSA has established appropriate unit-level security procedures that are consistent with University policies and guidelines.
• Ensuring LSA is following information security policies and procedures.
• Ensuring incident are promptly reported to LSA management, appropriate Business Owners, IIA, the Health Information portability and Accountability Act (HIPAA) Officer, U-M Office of Research (UMOR), Office of General Council (OGC), Institutional Review Board (IRB), and the U-M Police Department (UMPD) as necessary.
• Collaborating with IIA on the response and mitigation of SERIOUS incidents.
• Championing information security education and awareness for the College of LSA
• Providing feedback of special security, priorities, and concerns to IIA.
• Identifying security training needs for the unit.
• Contacting and informing LSA/U-M Media contacts (Public Relations).

Information Security Incident Response Procedure

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.

1. Initial Event Notification

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.

2. Assign Incident to LSA Security Administrator

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,

3. Detail Incident Log Entry in LSA Security Incident Tracking Database

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).
 

4. Severity Assessment

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:

• Sensitivity of potentially compromised date, such as identity theft concerns
• Legal issues, both criminal and regulatory
• Magnitude of service disruption
• Threat potential
• Expanse or scope of the incident
• Is High Profile and the incident' level of potential public interest and newsworthiness
• Estimate of cost of the incident as best as can be determined

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

• 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. Such information could include but is not limited to SSNs, student grades, drivers license numbers, and so on.
• 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.
• 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 Officer must be contacted.
• 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 UMOR must be contacted.

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.
 

5. 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.

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:

1. Review and verify incident documentation, event reports, and information entered in the LSA Security Incident Tracking Database.
2. Verify the assigned severity level based on available information.
3. Acquire the resources necessary to respond to the incident.
4. Notify IIA and LSA Senior Leadership of and SERIOUS incidents.
5. Notify the HIPAA Officer for all incidents involving PHI (personal health information).
6. Notify the UMOR for all incidents involving human subjects' personal information.
7. Notify others as necessary, including Business Owners, UMPD, Office of General Counsel (OGC), unit communications, and unit IT Service Providers.
8. Participate in a Computer Security Incident Response Team (CSIRT) that may be convened relating to a SERIOUS incident at the unit.
9. Contacting and informing LSA/U-M Media contacts (Public Relations folks).

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

6. 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 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.

7. Analysis

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:

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

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.

8. Eradication & Recovery

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.

9. Incident Closure

Complete Incident Documentation in LSA Security Incident Tracking Database

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:

1. How the incident was detected
2. Dates:
   • Inferred date of compromise
   • Date the compromise was detected
   • Date the incident was finally resolved
3. Names:
   • People added to the Incident Roles for this incident
   • Person responsible for the IT Resource
4. Person compromising the resource, if known
5. Scope:
   • Cause of the incident
   • Impact of the incident
   • Nature of the resolution
6. Proposed improvements to security systems

Inform IIA

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.

Store Other Incident Information

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.

10. Lessons Learned Review

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.

11. Executive Summary Report

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:

• A high-level description of the incident and its scope
• The impact on the University
• Actions taken to prevent further occurences
• Recommendations for further action

References

• Data Resource Management and Protection Common Definitions — This reference lists commonly-used information security terms and acronyms.
• Data Resource Management and Protection Roles and Responsibilities — This reference defines information security responsibilities at all levels of the University.
• Information Security Incident Management Guidelines 
• Private Personal Information (PPI) Data Classification — This page provides examples of private personal information (PPI) that should be considered sensitive and a scheme for classifying this information. It also identifies federal, state, and industry regulations that are applicable to various categories of PPI.
• SPG 601.7, Proper Use of Information Resources, Information Technology, and Networks at the University of Michigan — Describes University community responsibilities for exercising high ethical standards when accessing and handling University IT resources. Violations may constitute security incidents.
• SPG 601.12, Institutional Data Resource Management Policy — Sets policies and responsibilities for managing and protecting institutional data resources.
• SPG 601.25, Information Security Incident Reporting Policy — Requires prompt reporting of all security incidents and central reporting of serious incidents.

Appendix A: Operating System Specific Guides

• Linux — The Linux documents are under revision.
• Mac OS X — https://knowledgebase.umich.edu/Compromised_Mac
• Windows — The Windows documents are under revision.