Incident response is an organized approach to addressing and managing the aftermath of a security breach or cyberattack, also known as an IT incident, computer incident or security incident. The goal is to handle the situation in a way that limits damage and reduces recovery time and costs.
Ideally, incident response activities are conducted by the organization's computer security incident response team (CSIRT), a group that has been previously selected to include information security and general IT staff as well as C-suite level members. The team may also include representatives from the legal, human resources and public relations departments. The incident response team follows the organization's incident response plan (IRP), which is a set of written instructions that outline the organization's response to network events, security incidents and confirmed breaches.
Incident response is all about planning ahead and having a flight plan before it is necessary. Rather than being an IT-centric process, it is an overall business function that helps ensure an organization can make quick decisions with reliable information. Not only are technical staff from IT and security departments involved, so too are representatives from other core aspects of the business.
Importance of incident response
Any incident that is not properly contained and handled can, and usually will, escalate into a bigger problem that can ultimately lead to a damaging data breach, large expense or system collapse. Responding to an incident quickly will help an organization minimize losses, mitigate exploited vulnerabilities, restore services and processes and reduce the risks that future incidents pose.
This article is part of
Incident response enables an organization to be prepared for the unknown as well as the known and is a reliable method for identifying a security incident immediately when it occurs. Incident response also allows an organization to establish a series of best practices to stop an intrusion before it causes damage.
Incident response is a crucial component of running a business as most organizations rely on sensitive information that would be detrimental if comprised. Incidents could range from simple malware infections to unencrypted employee laptops that are put into the wrong hands to compromised login credentials and database leaks. Any of these incidents can have both short term and long term effects that can impact the success of the entire organization.
Additionally, security incidents can be expensive as businesses could face regulatory fines, legal fees and data recovery costs. It could also affect future profits as untreated incidents are correlated with lower brand reputation, customer loyalty and customer satisfaction.
While organizations cannot eradicate incidents completely, incident response processes do help minimize them. Emphasis should be placed on what can be done in advance to brace for the impact of a security incident. While hackers will always continue to exist, a team can be prepared to prevent and respond to their attacks. That is why having a functional, effective incident response approach is important for all types of organizations.
Types of security incidents
There are various types of security incidents and ways to classify them. What may be considered an incident for one organization might not be as critical for another. The following are a few examples of common incidents that can have a negative impact on businesses:
- A distributed denial of service (DDoS) attack against critical cloud services.
- A malware or ransomware infection that has encrypted critical business files across the corporate network.
- A successful phishing attempt that has led to the exposure of personally-identifiable information (PII) of customers.
- An unencrypted laptop known to have sensitive customer records that has gone missing.
Security incidents that would typically warrant the execution of formal incident response procedures are considered both urgent and important. That is, they are urgent in nature and must be dealt with immediately and they impact important systems, information or areas of the business.
Another important aspect of understanding incident response is defining the difference between threats and vulnerabilities. A threat is an indication or stimulus, such as a criminal hacker or dishonest employee that is looking to exploit a vulnerability for a malicious or financial gain. A vulnerability is a weakness in a computer system, business process or user that can be easily exploited. Threats exploit vulnerabilities which, in turn, create business risk. The potential consequences include unauthorized access to sensitive information assets, identity theft, systems taken offline and legal and compliance violations.
Incident response plan
An incident response plan is the set of instructions an incident response team follows when an event actually occurs. If developed correctly, it should include procedures for detecting, responding to and limiting the effects of a security incident.
Incident response plans usually include directions on how to respond to potential attack scenarios, including data breaches, denial of service/distributed denial of service attacks, network intrusions, malware outbreaks or insider threats.
Without an incident response plan in place, an organization may not detect the attack or it may not follow proper protocol to contain the threat and recover from it when a breach is detected. A formally documented IR plan helps businesses respond rather than react. When incident response procedures are not developed in advance, the resulting efforts end up making the situation worse, including looking on professional and ultimately being indefensible if lawyers get involved.
According to the SANS Institute, there are six key phases of an incident response plan:
- Preparation: Preparing users and IT staff to handle potential incidents should they should arise.
- Identification: Determining whether an event qualifies as a security incident.
- Containment: Limiting the damage of the incident and isolating affected systems to prevent further damage.
- Eradication: Finding the root cause of the incident and removing affected systems from the production environment.
- Recovery: Permitting affected systems back into the production environment and ensuring no threat remains.
- Lessons learned: Completing incident documentation, performing analysis to learn from the incident and potentially improving future response efforts.
Additionally, best practices indicate that incident response plans follow a common framework, which includes:
- An overview of the plan.
- A list of roles and responsibilities.
- A list of incidents requiring action.
- The current state of the network infrastructure and security safeguards.
- Detection, investigation and containment procedures.
- Steps toward eradication.
- Steps toward recovery.
- The breach notification process.
- A list of follow-up tasks.
- A call list.
- Incident response plan testing.
- Any revisions.
An incident response plan can benefit an enterprise by outlining how to minimize the duration of and damage from a security incident, identifying participating stakeholders, streamlining forensic analysis, hastening recovery time, reducing negative publicity and ultimately increasing the confidence of corporate executives, owners and shareholders.
The plan should identify and describe the roles and responsibilities of the incident response team members who are responsible for testing the plan and putting it into action. The plan should also specify the tools, technologies and physical resources that must be in place to recover breached information.
Every organization’s incident response plan can be tailored to specific business risks and needs that have been identified. However, all incident response plans should outline factors involving who, what, when, why and how as they relate to security incidents and confirmed breaches.
What does an incident response team do?
A good incident response program requires putting together a cross-functional team from diverse parts of the business. Without the right people in place, any attempted incident response efforts will likely be ineffective. The team not only helps to execute the incident response plan but also aids with ongoing oversight and maintenance including the day-to-day administration of technical controls. Each team member should have clearly defined duties and goals. These are actions that not only take place during an incident but also before an incident occurs and afterwards as well. The incident response team may involve members of the organization’s overall security committee.
Who is responsible for incident response?
To properly prepare for and address incidents across the business, an organization should form an incident response team. This team is responsible for analyzing security events and responding appropriately. An incident response team may include:
- An incident response manager, usually the director of IT, who oversees and prioritizes actions during the detection, analysis and containment of an incident. The incident response manager also conveys the special requirements of high-severity incidents to the rest of the organization.
- Security analysts who support the manager and work directly with the affected network to research the time, location and details of an incident. Triage analysts filter out false positives and keep an eye out for potential intrusions. Forensic analysts recover key artifacts (residue left behind that can provide clues about an intruder) as well as maintain the integrity of evidence and the investigation.
- Threat researchers that provide threat intelligence and context for an incident. They scour the internet and identify information that may have been reported externally. Threat researchers combine this data with an organization's records of previous incidents to build and maintain a database of internal intelligence. If this level of expertise does not exist in house, it can be outsourced.
Management support is key to securing the necessary resources, funding, staff and time commitment for incident response planning and execution. Many incident response teams include the Chief Information Security Officer (CISO), the Chief Information Officer (CIO) or another C-suite executive, who acts as a leader and evangelist for the group. An outside consultant who specializes in incident response can be a good addition to the team when needed.
The incident response team may also include a human resources representative, especially if the investigation reveals that an employee is involved with an incident. Audit and risk management specialists can develop vulnerability assessments and threat metrics and also encourage best practices across the organization.
Including the organization's general counsel can ensure that the collected evidence maintains its forensic value in case the organization decides to take legal action. Attorneys also provide advice about liability issues when an incident affects vendors, customers and/or the general public. Finally, a public relations specialist is essential for keeping in touch with team leaders and to ensure accurate and consistent information is disseminated to the media, customers, stockholders and other interested parties.
Incident response plan management
Incident response is not unlike any other aspect of information security. It requires thoughtful planning, ongoing oversight and clear metrics so that efforts can be properly measured. Ongoing management initiatives include setting and overseeing incident response goals, periodically testing the incident response plan ensure its effectiveness and training all the necessary parties on applicable incident response procedures. Specific metrics used to measure the effectiveness of incident response initiatives might include:
- Number of incidents detected.
- Number of incidents missed.
- Number of incidents requiring action.
- Number of repeat incidents.
- The remediation timeframe.
- Number of incidents that led to breaches.
Additionally, incident response goals might include areas involving:
- Routine incident response plan reviews and updates.
- The planning and execution of incident response test scenarios.
- Integration with related security initiatives, such as security awareness, employee training and vulnerability and penetration testing.
- The reporting of security events to executive leadership or outside parties.
- The procurement of additional technologies that can provide enhanced network visibility and control.
Incident response plans vs. business continuity plans
With the goals of keeping the business running and minimizing the impact of unforeseen events, incident response could be considered part of the business continuity process. Given what is at stake and the different variables involved, such as people, technologies and business processes, incident response should have the highest levels of visibility within the organization. An incident response plan is dedicated to incidents and breaches impacting networks and computers, applications and databases and related information assets. Therefore, most organizations are best served by keeping the incident response plan in a standalone document – separate from yet referenced in the business continuity plan. The most important thing is to ensure the incident response plan is easily accessible by all team members when it is needed.
Tools for incident response
There are numerous tools and methodologies that can be used to assist with incident response and are typically categorized by prevention, detection or response functionalities. Certain organizations follow the military-derived OODA loop for incident response. The OODA loop is a methodology that encourages a business to observe, orient, decide and act when an incident occurs, all of which IR tools can assist with.
For example, an organization can gain the necessary visibility into an incident with packet analysis, system resource monitoring and file integrity examination technologies. Insight can be gained into the threats by using real-time threat indicators and threat intelligence services. Even further, there are tools that can provide forensics details such as source location, incident technical information and event replays. There are also tools that allow an organization to act against a threat by stopping it from spreading or minimizing the impact it has on the computing environment.
While incident response is a process, technology can be used to automate and streamline specific incident response functions to help minimize detection times and system errors. Service providers focused on developing incident response technology typically offer products in the following categories:
- Employee awareness and training.
- Endpoint security management.
- Firewall, intrusion prevention and DoS mitigation.
- Forensics analysis.
- Net flow and traffic analysis.
- Security incident and event management (SIEM).
- Vulnerability management.
In essence, incident response tools provide organizations with both visibility and control. They also provide professionals with the necessary information so that they know what to do, or not do, once anomalous behavior is discovered. Finally, incident response tools help with direct response efforts – allowing organizations to take action in order minimize the risks involved.
Most technology products in the incident response sector are commercial and require proper budgeting for capital and operating expenditures. Alternatively, there are a number of open source software offerings that could be tailored to meet a specific organization’s requirements. When choosing the open source approach, it is important to weight how much effort will be involved, how efficiently it will be able to scale and how effective it will be long term.
Once incident response tools are put into place, it is important to ensure that there is enough staff and expertise to keep it maintained and updated. Having the necessary resources is critical for the initial design and implementation of the technology as well as the ongoing administration and troubleshooting.
Finally, executives must remember that incident response tools cannot comprise the entire incident response program. While tools and automation may play a large role, they should still only be one component of the overall incident response requirements.