Incident Management and Response

Table of Contents

• Getting Started | Overview | Resources |Standards
• Management of Information Security Incidents and Improvements (ISO 16)

Top of page

Overview

The reality of security incidents, breaches, and data loss have become all too familiar to a growing number of colleges and universities. Information security incident management programs (sometimes also called information security incident response programs) are required to help institutions respond to information security incidents that compromise the confidentiality, availability, and integrity of an institution’s information technology resources and data. An institution’s failure to plan in advance for handling information security incidents is a mistake and can jeopardize the institution.

An effective information security incident management program includes 4 basic stages: Preparation; detection and analysis; containment, eradication, and recovery; and post-incident review. The National Institute of Standards and Technology SP 800-61, Computer Security Incident Handling Guide, describes the "Incident Lifecycle" using this flowchart:

There are a number of good industry references for effective information security incident management programs, including the NIST document referenced above and ISO/IEC 27002 domain 16 (Information Security Incident Management). This chapter supplements those resources by providing a high-level overview of incident management approaches from an institutional perspective, a list of recommended tools for incident handlers, links to example practices at selected institutions, and other helpful guidance.

Top of page

Management of Information Security Incidents and Improvements (ISO 16)

Preparation

An institution's information security incident response management program is evidenced by policies and incident handling procedures. These documents should be clear and concise, describing the steps all campus members (from end user to incident response staff to leadership) must take in response to an actual or suspected incident. Ideally, these documents are prepared well in advance of being needed. During this preparation stage, the institution identifies the resources needed for incident response capabilities, ensures that it has individuals who are properly trained and ready to respond to information security incidents, and develops and communicates the formal detection and reporting processes to campus.

Many institutions evidence their commitment to their information security incident management programs via an incident response policy. Common incident response policy sections include:

• Purpose and objectives of the policy (including a statement of leadership support).
• Scope of the policy (to whom and what it applies, and under what circumstances).
• The definition of what constitutes an information security incident to which the institution will respond.
• A prioritization or severity ratings for information security incidents (designed to help institutions quickly recognize the types of incidents, or data involved in an incident, that requires escalation beyond the incident response team).
• Delineation of roles and responsibilities within the information security incident response process including roles and responsibilities for:
  • The operational incident response team (this is usually the team within the IT or campus information security office responsible for incident triage and handling).
  • A cross-campus executive leadership team that may become involved if an information security incident has a high severity level.
  • Campus end users (and their roles in reporting an information security incident and/or following incident response instructions from the operational team).
  • Campus professional IT staff who many be pulled into incident response activities depending upon the nature of an underlying incident.
  • CISO/CIO or other primary campus executive in charge of information technology and/or information security (including, for example, their authority within the incident response process to direct that an IT resource be disconnected, to confiscate equipment, and to monitor suspicious activity).
• Reporting contact information and additional resources.

Sample incident response policies can be found on the Information Security Policy Examples page in this Guide.

During the preparation stage it is also important to consider creating resources to supplement the institution's information security incident response policy. Supporting documents might include:

• A flow chart of how information security incidents are handled on campus, from initial report to closing the incident and conducting a post-incident review.
• Procedures for the operational incident response team (both general procedures and procedures directed at response activities for very specific incidents like phishing or a report of confidential information posted on a public facing website).
• Procedures for the cross-campus leadership team to follow in the event of a high severity incident requiring potential breach notification.
• A website for reporting suspected information security incidents with general guidance about what end users should do once they report a suspected incident.

Thinking about incident response training and education is very important during this preparation stage. Not only do campus end users need to be trained on their reporting roles and responsibilities, but the operational incident response team and campus leadership needs to be trained on their roles too. In some instances, members of the incident response team may require specialized training on using forensics analysis or other data examination and recovery tools.

Top of page

Detection and Analysis

Designing an effective mean to detect information security incidents is also essential. Information security incidents can be reported by end users, and they can also be detected (and reported) via trained IT personnel. This is why it is so important that all campus personnel be trained on the proper way to report a suspected information security incident.

In addition to reporting, technical controls must be implemented for the automated detection of security events, coupled with as near real-time reporting as possible, to investigate and initiate response activities. Common controls include monitoring server logs for signs of unauthorized access, monitoring firewall or router logs for abnormal events, and monitoring network performance for spikes in traffic. Institutions may also implement host and network intrusion detection/prevention systems. Data aggregation tools, such as a security information and event management (SIEM) tool, can help manage data from multiple sources to generate alerts and even take action to stop malicious activity.

• Learn more about intrusion detection and prevention in the EDUCAUSE Library.

In addition to detecting an incident (through a number of mechanisms), it is imperative that the information security incident be timely assessed to determine the types of information technology resources and institutional data potentially involved in the incident, and to understand the severity level of the incident (ranging from low to high severity). During this analysis, the operational incident response team will also try to understand the scope of the suspected incident. For example, is the incident confined to one unit, one department, a campus building, an entire campus, multiple campuses, or an entire system (if applicable)? The team will also try to understand how many resources (services, systems, or applications) or how much data (usually counted in records or accounts per person) may be involved. They will try to determine the type of data involved in the suspected incident (e.g., is it personally identifiable to an individual, protected by law, is intellectual property or research data involved, etc.).

They will also attempt to assess the urgency of the suspected incident. Is it an active problem, threat, or an event-in-progress? Was the problem discovered after the fact? Does the suspected incident involve use of an account rather than a system? Does it involve the safety or privacy of individuals?

All data gathered during this detection and analysis stage will help inform prioritization of the incident and help inform the activities performed in the next stage. Most institutions will have forms and checklists to walk them through the data gathering process. It is also during this activity that the institution might start creating a record or log regarding the suspected incident, including whether or not the suspected incident is confirmed as an actual information security incident to which the institution must respond.

• A sample Incident Checklist for data gathering can be found in this Guide.

Containment, Eradication, and Recovery

It should be noted that most incident response steps don’t happen sequentially, or with clear delineations between tasks. Once a suspected incident is confirmed, sometimes detection and analysis, and containment, eradication, and recovery activities may all happen at the same time or with a speed that suggests that they are happening at the same time. This is normal depending on the scope and severity of the underlying information security incident, as well as the maturity of the institution's information security program and incident handling capability.

During this phase, operational incident response teams may do these types of containment activities:

• Confine and mitigate the incident to prevent further disruption and/or spread to other systems or campuses.
• Conduct any additional investigation and/or analysis, especially for incidents that may be of perceived higher severity.
• Acquire, preserve, secure, and document evidence. (Note that collecting evidence that may be used for law enforcement or legal purposes later is very nearly a discipline in and of itself. Personnel must be trained on proper evidence collection techniques. Outlining forensic evidence collection activities is beyond the scope of this Guide. Contact your campus or local law enforcement agency to understand what your institutional needs might be and to learn the appropriate procedures for your jurisdiction).
• In coordination with IT and campus leadership, provide information regarding service disruption and the potential need to activate business continuity plans to the campus community.

Operational incident response teams may do these types of eradication and response activities during this phase:

• Identify and mitigate all vulnerabilities that were exploited in the incident.
• Remove malware, inappropriate materials, or other components and securely configure affected systems appropriately.
• If more affected hosts are discovered, repeat the incident response steps as needed.
• Redeploy securely configured systems to an operational state, and confirm that the systems are functioning normally.
• In coordination with IT and campus leadership, provide information regarding service restoration activities to the campus community.
• If necessary, implement additional monitoring to look for future incident-related activity.
• In the event of high severity incidents, IT and campus leadership may also need to take additional response steps such as coordinating with legal counsel and campus media departments to make a public data breach notification.

The following Information Security Guide resources may be helpful during this phase:

• Incident Checklist
• Data Incident Notification Toolkit
• E-Discovery Toolkit
• Protocol for Law Enforcement Requests

Post Incident Review

The post incident review phase is critically important and oft overlooked. During this phase the operational incident response team, and campus and IT leadership come together after an information security incident is closed (or active incident response activities have concluded) to identify lessons learned and how to better handle future information security incidents. Activities in this stage may include:

• Hold a "lessons learned" meeting to discuss how the incident response process worked and what went well (and what can be improved).
• Review corrective actions put in place during the incident response process for continued applicability.
• Document the incident response process for metrics and historical purposes.
• Determine if there are any high-level issues that need to be elevated to IT or campus leadership for resolution (e.g., whether cyber liability insurance would be useful, or whether there are significant costs to reduce a particular vulnerability).

During this phase, campuses may also update their information security incident response metrics. The purpose of incident response metrics is to help the institution understand the major causes and sources of information security incidents, to measure damage caused by incidents, and to observe trends in both. Metrics may include the total incidents handled, time spent on incidents, the number of different types of incidents, and the number of systems impacted. Some useful incident response metrics to measure over time include:

• The number of detected, but unsuccessful intrusion attempts to compare against the number of detected and successful ones.
• The damage/losses caused by incidents, to help develop plans for reducing outages and the staff hours spent responding to incidents.
• Reductions in downtime of the network or critical systems.

Top of page

Resources

Top of page

Standards

Top of page

Questions or comments? Contact us.

Except where otherwise noted, this work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).

ParentTopics:

Security Management Incident Management and Response Intrusion Detection and Prevention