In today's interconnected world, every organization suffers cybersecurity incident of one kind or another. Your team's ability to respond efficiently and effectively to incidents may be the difference between success and serious financial loss or reputational damage for your organization. Careful planning and preparation is crucial to ensure business continuity during the most challenging security incidents.
Incident response should be based around the following steps (every step plays a critical role in protecting your organization, and none should be skipped):
To prepare for incidents, ensure that you formally assign responsibility, document response policies and procedures, establish an incident response team, publish accurate contact information, and train your incident handlers.
First, designate and appropriate staff member to oversee and manage cybersecurity incident response. By clearly and formally designating responsibility, you can ensure a consistent response effort that matures over time. If you have an organization with a distributed infrastructure (such as a university, health care network, or a large company with multiple sites), make sure to assign ONE person to be in charge of the overall incident response, and then designate an appropriate staff member for each location or department to oversee response efforts for that specific group.
Consider the types of incidents that may affect your organization. Clearly document a response policy for each type of incident.
Create an easy-to-remember notification mailing list and phone number that general employees, customers or third parties can contact to report a suspected incident.
Establish a "core" incident response team to handle events on a day-to-day basis. This group typically consists of Help Desk staff, IT security staff members, members of the network team, etc. In small- to mid-sized organizations, it may simply be one or two individuals.
Next, identify members of an "extended" incident response team that may be called in to help with specific types of incidents. Members of the extended team typically include Legal, Human Resources, Physical Security or Facilities, Public Relations, Accounting/Finance, and upper management.
Collect accurate and canonical network diagrams, copies of firewall configurations, critical assets list, and any other documentation needed to understand the organization's network. Make sure this is available to incident responders as needed.
Not every member of the Incident Contact List needs to be activated for every incident, but the incident handler should not hesitate to request resources as needed. In addition to the Incident Contact List, Incident Handlers should have access to contact information for the technical administrators and business owners of all systems.
Core members of the Incident Response team should undergo specialized training. There are industry certifications available, such as the GIAC Certified Incident Handler (GCIH) certification, and others.
Preparation is an ongoing process and should regularly incorporate feedback from the Post-Incident reports. For instance, if a recent incident response was hampered by lack of log retention on a particular system, this should be included in the Post-Incident report and dealt with during a scheduled preparation phase.
The identification phase begins when defenders discover signs of an incident. Signs can take a wide range of forms, from intrusion detection system (IDS) alerts to system outages. Immediately after identification of a potential incident, a common reaction is to skip directly to the containment and recovery steps. However, resist the urge to skip steps. Skipping to containment before identifying all affected systems can allow attackers change tactics and entrench themselves more deeply. Also, moving to containment before resources are in place to collect forensic evidence can destroy vital information and place an organization at risk.
Once a suspected incident has been reported or detected, the following steps should be executed in a methodical and controlled manner to validate the incident and identify its scope.
The goal of the containment phase is to limit damage the attacker can cause and preserve evidence for later analysis. Once the Incident Handler has determined which systems are affected and the potential impact, move to the containment phase.
Always develop a containment plan before putting measures into place. This will allow defenders to execute containment quickly and methodically, while giving attackers little time to react once containment begins.
The plan should contain the incident while preserving evidence whenever possible. For instance, if a web server has been compromised, coordinate with the system's administrator to acquire a live memory image before disconnecting the server and imaging the hard drives.
The plan should cover the full scope of the incident. For instance, if a keystroke logger has been discovered on an administrator's workstation, the containment plan should include changing or disabling credentials for all of the administrator's accounts. If there is evidence that an administrator's credentials have been used to access other systems, containment should include these systems as well. The plan should attempt to minimize disruption to the organizations operations.
The later steps of the containment plan should include analysis of collected evidence (disk images, memory dumps, network logs) to create a full timeline of the incident. This vital step ensures the incident has been fully contained and will aid in the recovery phase.
The goal of the recovery phase is to get the organization back to normal operations. During this phase compromised systems should be rebuilt, affected customers should be notified, and attack vectors identified during the Identification and Containment phases should be remediated.
The goal of the post-incident phase is to assess and improve the incident response process. During this phase the notes Incident Handler's notes, timeline of the incident, evidence collected, and any other information about the incident should be archived.
The Incident Handler should also file a brief after-action report that summarizes causes and impacts of the incident, as well as steps taken to identify, contain, and recover from the incident. Special attention should be given to parts of the incident response process that were successful or need improvement. These after-action reports should be regularly incorporated into the preparation phase.