IT Security Incident Management Guidelines for U-M Units

These guidelines:

  • Describe how Information Assurance (IA) and U-M units work together to respond to and coordinate IT security incidents.
  • Outline specific IT security incident roles and responsibilities for both IA and U-M units.

Units can use the guidelines:

  • As a guide for development of internal processes and procedures for IT security incident response.
  • To inform IT staff and unit leadership about IT security incident response processes and responsibilities at U-M.

U-M staff with IT security responsibilities play a critical role in IT security incident response. IA provides the following guidance for IT security staff within campus units, to help the university respond to IT security incidents as defined in the university's Information Security Incident Reporting (SPG 601.25).

In general, the goals of IT security incident response at the University of Michigan are to:

  • Minimize negative consequences of information security incidents, and improve the university's ability to promptly restore operations.
  • Enable prompt incident response decisions to be made by appropriate stakeholders.
  • Proactively reduce the exposure of the university to information security incidents by employing consistent incident management processes that incorporate lessons learned from past incidents.
  • Satisfy federal, state, and industry regulations that require improved protection of sensitive and private information, and timely disclosure of potential breaches to affected individuals.
  • Establish a framework and appropriate metrics for consistently prioritizing information security investments across the university.
  • Promote awareness and education of the U-M community relevant to incident avoidance, detection, reporting, and handling.

Communication During an Incident

Units should rely on IA to manage and coordinate communication during an incident—both within the group of people working on the incident and on any notifications to leadership, users, or others. IA will ensure the appropriate communication cadence and level of detail so people have the information they need and are not unduly alarmed and that the investigation is not jeopardized. Units are asked not to communicate about an incident without first working with IA.

Incident Lifecycle

The incident lifecycle processes include the following:

Incident Detection and Reporting

The incident detection process involves observation of malicious or anomalous activity, and gathering of information that provides insight into security threats or risks. Reports of threats from sources external to U-M may also trigger an incident report. Risks, threats, and vulnerabilities that meet the SPG 601.25 definition of information security incidents are forwarded to the designated Security Unit liaison. Information security incidents that are detected by any users of U-M information resources (including computer theft or loss) are also reported to the Security Unit liaison per SPG 601.25. As noted in the SPG, incidents should be reported to the Security Unit liaison as soon as possible but no later than 24 hours from the time they are initially detected.

Incident Severity Classification

Incidents that meet the Serious Incident criteria as defined in SPG 601.25 must be centrally reported to [email protected]. All other Non-Serious incidents are to be handled by the unit using unit level procedures for incident response, which include incident tracking and monitoring using any automated or manual tool selected by the unit. In the case of a MiWorkspace unit, IA will take the lead and handle Non-Serious incidents.

Incident Response Process

The Incident Response Process is designed to provide a high level guide for effective planning, communication, and response in the event of a IT Security Incident. The responsibilities assigned to the Security Unit Liaison may be performed by a person or group designated by the Security Unit Liaison in coordination with IA.

Preparation (Preparing incident response tools and IT staff for when an incident occurs)

Unit IA
  • Unit IT staff must have necessary training, tools, and procedures to identify, contain, and remediate non-serious information security incidents. IA will provide guidance and expertise if needed.
  • The Security Unit Liaison must act as the point person for unit level incident response communication and coordination.
  • IA Incident Response staff have necessary tools and procedures to coordinate IT security incidents.
    • IA acts as the primary incident responders for serious and non-serious incidents in MiWorkspace units.
    • IA acts as primary incident responders for serious incidents only in units that are not part of the MiWorkspace service. Non-serious incidents are to be handled by appropriately-trained unit IT staff.

Identification (Determining where the incident occurred and the incident severity)

Unit IA
  • Unit IT Staff will determine the severity of the incident as defined by SPG 601.25, and may consult with IA to ensure appropriate incident classification.
  • The Security Unit Liaison should be available to coordinate and properly facilitate incident identification.
  • If the incident is serious (per SPG 601.25), the unit must contact IA within the first 24 hours of becoming aware of the incident.
    • IA will coordinate the incident response process going forward.
    • SUL must inform appropriate business owners and leadership.
  • For MiWorkspace units, IA will coordinate with ITS Neighborhood IT and the Security Unit Liaison to identify the severity and scope of the incident.
  • For non-MiWorkspace units, IA will coordinate with unit IT staff and the Security Unit Liaison to determine the severity and scope of the incident.

Containment (Limiting the incident damage as quickly as possible)

Unit IA
  • Serious Incidents:
    • Unit IT staff / ITS Neighborhood IT are responsible for containing the security incident under IA's guidance.
  • Non-Serious Incidents:
    • For MiWorkspace units, IA will assist ITS Neighborhood IT in containing the security incident.
    • For non-MiWorkspace units, Unit IT staff will contain the incident, and may consult with IA if assistance is needed.
  • Serious Incidents:
    • IA will guide appropriate containment efforts.
  • Non-Serious Incidents:
    • IA can provide guidance for effective incident containment if needed.

Eradication (Removing the cause of the incident)

Unit IA
  • Serious Incidents:
    • Unit IT staff / ITS Neighborhood IT must coordinate with IA to analyze the incident, collect any necessary forensic evidence, and notify approporate parties for affected device(s) eradication.
  • Non-Serious Incidents:
    • For MiWorkspace units, IA will assist ITS Neighborhood IT in eradicating the security incident.
    • For non-MiWorkspace units, Unit IT staff will eradicate the incident, and may consult with IA if assistance is needed.
  • Serious Incidents:
    • IA will inform appropriate regulatory parties if the incident involves sensitive data, as well as keeping the Computer Security Incident Response Team (CSIRT) informed.
  • Non-Serious Incidents:
    • IA can provide guidance for effective incident eradication if needed.

Recovery (Restoring affected systems to normal operational status)

Unit IA
  • Unit IT Staff / ITS Neighborood IT should work with necessary parties in order to verify that all affected systems are back to a fully operational state.
  • If it is apparent that affected systems were not properly hardened from a security perspective, IA can be involved to provide hardening suggestions.
  • Serious Incidents:
    • Unit must review recovery plans with IA before implementation.
  • IA can coordinate with unit IT Staff / ITS Neighborood IT on appropriate hardening suggestions and implementation procedures for affected systems if needed.
  • IA will provide findings to involved parties as necessary.
  • Serious Incidents:
    • IA will follow up with necessary CSIRT members to verify that all appropriate regulatory, and any additional team notifications, have been successfully completed.
    • IA will review and approve unit recovery plans.

Lessons Learned (Serious Incidents)

Unit IA
  • Security Unit Liaison will coordinate any necessary findings and lessons learned documentation for review with the CSIRT.
  • IA will schedule and involve appropriate parties in a lessons learned discussion to review the incident management process, and discuss potential improvements for future incidents. The participants in the lessons learned process are determined by IA, and may include the unit SUL, IA ISL, IA Incident Response team, business owners, unit leadership, and CSIRT members.

 

Incident Reporting (Serious Incidents)

All serious incidents, including incidents where the Security Unit liaison is not sure whether the incident is serious or what type of information might be involved, must be reported to IA. Any serious incidents that are reported or forwarded to IA should include the following:

  • Time(s) of occurrence
  • Systems/applications/devices potentially involved
  • Actions taken
  • Types of sensitive data that may be involved
  • Potential business impacts of action or inaction
  • Include contact details for business owners and technical staff involved
  • Has unit leadership/ISL/SUL has been informed?

Reporting of serious incidents to IA must occur as soon as possible, but no more than 24 hours from discovery of the incident.

Roles and Responsibilities