No organization is exempt from data breaches or cyber-attacks. In order to protect your company and its customers, you must have a plan in place for when (not if) an incident occurs. This plan should include the steps you will take to investigate the issue, contain the damage, and restore service. A well-run Incident Response Team (IRT) is key to minimizing the impact of any data breach or cyber-attack.
The job of an IRT is not easy – it requires coordination and communication among people with different skillsets, as well as cooperation with other departments within the company. But with careful planning and execution, an IRT can be a valuable asset in times of crisis.
This guide will walk you through everything you need to know about responding to an incident, from initial steps to long-term recovery. We hope this information will help you create or improve your organization’s Incident Response Plan.
What is an Incident Response Team (IRT)?
The incident response team is the group that engages and supports the entire incident response lifecycle. Simply put, these team members are the ones you will call when it hits the fan, and they’ll fix it.
There are many names for the incident response team, some of the most common being:
-
ISIRT (Information Security Incident Response Team),
-
Centralized Incident Response Team,
-
Computer Emergency Response Team,
-
Incident Response Team CSIRT (Computer Security Incident Response Team), and
-
When referred to in this specific way normally represents a more specialized division on the incident team (we’ll talk about that just a bit later)
-
-
Response Team.
Regardless of their name, these incident responders do the same thing. They handle your incidents.
What are the Incident Response Team Roles?
While each incident response team has variations, they typically have these general members identified and assigned to appropriately competent and available entities.
Incident Response Manager (Team Leader)
The incident manager is responsible for all incident management functions (*drop mic*). This “team lead” oversees the entire incident response effort and ensures all other team members are performing their duties.
While they should have the technical expertise to understand all of the aspects of the incident response effort, the incident manager does not need to be a specialist in everything. The incident manager also is not necessarily the team member who will communicate with other internal stakeholders or external parties (i.e., customers, vendors, etc.).
Excellent project management, leadership, and communication skills are a must for the incident manager. It’s also important that the incident manager is highly available so that when there is an incident, they can immediately jump on it and assemble the appropriate team members.
Technical Lead
This is another incident manager that focuses on the technical aspects of an incident and its management. As their name suggest, they should have substantial technical expertise.
In many organizations, the technical lead is supported by the CIO (Chief Information Officer), CTO (Chief Technical Officer), or CISO (Chief Information Security Officer), and their supporting technical players are typically sourced from the organization’s IT (Information Technology), and/or SOC (Security Operations Center) departments.
ISMS (Information Security Management System) Director
The organization’s ISMS is its security and compliance management program. It encompasses all of the efforts that the organization puts into managing its security and compliance. The ISMS can go my many names, one of the most common being an ISP (Information Security Program).
This director (of whatever your organization calls your security and compliance program) is typically the custodian (i.e., the one doing the work) of all security and compliance matters within the organization. They are usually your organization’s risk management specialists and typically manage your incident response planning. If this role is separate from any of the above roles, it should be included within your incident response team.
Regulatory & Compliance Advisor(s)
These incident response team members ensure that all regulatory requirements are being met before (done during the incident planning phase – more on that later), during, and after an incident.
Security breaches involving client or patient information introduces a host of regulatory requirements and it is imperative you have appropriate representation on your team to manage these legal requirements.
HIPAA (Health Insurance Portability & Availability Act) Officer
If you work with PHI (Protected Health Information), then HIPAA applies to you. Your HIPAA Officer must be an internal resource (this can’t be outsourced) and there are very specific (time and deadline sensitive) actions they must perform when there is a data breach that impacts (or is suspected to impact) PHI or ePHI (Electronic Protected Health Information).
This role must understand the complexities of the HIPAA Privacy Rules, and the HITECT Subpart D Data Breach Notification requirements. Even if ePHI/PHI has not been affected, HIPAA still has very specific requirements anytime a covered entity or business associate experiences a security breach.
Privacy Officer
Just like HIPAA has very specific requirements around ePHI/PHI management, if you process, store, or transmit PII (Personally Identifiable Information) there are very specific state, federal, and international laws your organization must abide by.
Just like with HIPAA, whether there was a data breach or not, certain actions must be performed with all security breaches to ensure your organization is not breaking the law.
At the very least, your Privacy Officer must understand that there are tremendous complexities in privacy laws and how to get the support you need to ensure your organization is following them.
It’s also important to note, that for practically every privacy regulation, where your customers reside (not your organization) determines what privacy laws your organization must follow. With the internet making it so easy to do business with customers in multiple states and countries, it’s imperative your organization has an effective Privacy Officer.
Forensic Analysis
These highly technical cyber security teams perform an analysis of cyber attacks to determine, what happened, how it happened, and what as affected. Like a detective looking for fingerprints, these cyber security detectives provide the information your organization needs identify the root cause of an attack, and prevent future attacks.
Their analysis after security incidents is critical not just to identify what was accessed, but what wasn’t accessed. HIPAA and multiple privacy laws require “proof” that ePHI/PHI/PII was not impacted in any of your organization’s security incidents, and the forensic team can provide that. This keeps your organization from having to perform costly (and embarrassing) client notifications. Though not all IRT’s include a forensic analysis expert or team, these security analysts can protect your organization from expensive notification campaigns, remediation costs, regulatory fines, and lost business.
Legal Representation
These individuals or teams provide crucial legal guidance for your organization. Many times, your legal representation will also act as your HIPAA Officer (if they are internal to your organization) and/or Privacy Officer.
It’s very important however to source legal guidance from firms that understand your industry and needs. A patent attorney is not the best resource to engage for a possible privacy event.
Local Law Enforcement & FBI Contacts
While not direct incident response team members, it’s important to have the contact information for all law enforcement agencies and FBI field offices local to your location(s).
Insurance Carriers
Again, while not direct incident response team members, your ISIRT member contact list should have the relevant insurance information listed (i.e., claim contact numbers, policy numbers, etc.) so it is easily available during an incident.
Public Relations & Media Support
It’s best to not represent yourself in court, and the same goes for public engagement. If available, be sure to list the contact information for these resources (and any other relevant information) so they can be quickly engaged if needed.
Client Notifications
If client (or patient) information is impacted during a security incident, they must be notified, and there are specifics regarding how that is done. Your Client Notifications team member(s) ensure(s) that the right message goes to the right parties, at the right times. Many times, this is managed by your legal team, HIPAA Officer, or privacy compliance officers. These are more compliance driven communications, rather than the PR/Marketing messages managed by the Public Relations & Media Support team(s).
Other Team Members
Your incident response team should consist of every resource that could support you through an incident. Not every member will be involved in every incident response. What’s important, is that they are ready, and their contact information easily available, when they are needed.
Do the Incident Response Team Members Just Address Security Incidents?
While many people think of an incident response team as only handling security incidents (which in specialized teams is typically the role of the Incident Response Team CSIRT), the incident response team is (should be) responsible for handing the incident response for any type of incident that negatively affects the organization.
Be sure to source your incident response team will all the resources that can support the type of incidents your organization may experience.
What Seven Incident Response Activities Must the Incident Response Team Address?
While they may be named differently all incident plans should ensure they address:
-
Incident Response Management Preparation,
-
Incident Detection and Notification of Weaknesses, Events & Incidents,
-
Incident Containment, Investigation, Assessment, & Decision
-
Incident Response & Recovery,
-
Incident Reporting
-
Learning from Incidents (Post Mortem Analysis), and
-
Collection of Evidence
1 – Incident Response Planning
Just like you don’t want to start developing your evacuation plan when the building is already on fire, you don’t want to start developing your incident response plan when you experience an incident.
Incident response planning must happen before experiencing a security incident. Creating an effective incident plan of action should include:
-
Performing risk assessments to identify all relevant security threats and system vulnerabilities to your organization and identify the gaps in your security posture,
-
A review of relevant trending data and previous incidents (if any exist),
-
Identification of all relevant incident response team roles and responsibilities,
-
Development of your security incident process flow (your general approach to handling a security incident),
-
The identification of all communication requirements during and after an incident,
-
Documentation of your plan (write it all down), and
-
Ensure your plan is both protected, and available (it’s no use to anyone if they can’t access it when they need it).
To create the most effective incident response strategy possible, work with all relevant stakeholders (interested parties) and other security analysts to ensure you address all relevant issues to organization. You should also utilize each of the remaining elements listed below and ensure you have adequate descriptions and instructions for each of them.
2 – Incident Detection & Notification
In order to mount an effective incident response, a security incident must be detected, and the appropriate resources notified.
Detection
A successful incident response can’t occur without it being detected. Unfortunately, according to the 2021 IBM Data Breach Cost Report, this takes 287 days on average. Ouch!
What constitutes good detection capabilities is subjective to each organization and its particular needs, there is no one size fits all solution. Good detection capabilities come from a layered approach (multiple and varying security tools), which typically include:
-
Network traffic monitors,
-
Multiple security devices like firewalls and managed switches,
-
IDS – Intrusion Detection Systems,
-
Robust logging of systems and networks,
-
Review of threat intelligence briefs,
-
Well developed internal audit programs, and
-
Performing routine vulnerability assessments and penetration testing.
These are just a few examples and what would be best for your response development will depend on your specific needs. It’s important that the review and development of your detection capabilities are part of your normal team activities and most importantly reviewed by more than one person.
Notification
Once a security incident has been detected, the ISIRT needs to be told about it. That’s notification.
Notifications can come from many places, some examples include:
-
Security alerts,
-
Auditing activities,
-
Vulnerability assessments,
-
Penetration tests,
-
Internal or external notifications.
It’s important that direct communication channels to your ISIRT are established and that all those interacting with your organization understand how to use them effectively.
3 – Incident Containment, Investigation, Assessment, & Decision
This stage is where your incident team first takes action (not counting all of the work they did in the planning phase).
Incident Containment
Stop the bleeding. Here your first responder (first team member to engage) performs a quick triage of the situation and takes immediate action to prevent further impacts from the detected incident or at least slow them as much as possible.
The actions performed in this stage won’t necessarily be your final solution, and they rarely are as what is done to initially respond to an incident typically has a significant impact to business productivity and operations.
Thorough planning and “pre-authorizations” (i.e., what systems a responder can take offline) supports rapid system containment, and helps minimize the impact(s) to your organization during the initial states of an incident.
Incident Investigation
Once the bleeding has been stopped, you’re in a safe place, your ISIRT can begin the investigation to understand what exactly is happening and what organizational assets (equipment, informations, locations, people, etc.) are being affected.
The goal of this stage is not necessarily to identify the root cause of the incident (though that does happen many times during this stage) but rather, to understand the extent of the damage and affected assets to support the team’s ability to fully assess the situation, and make an appropriate decision regarding how to move forward.
Incident Assessment
To understand how to appropriately respond, your incident response team needs to fully understand what they are dealing with. The assessment phase will use all available information available on the incident to classify the incident which will dictate an appropriate response effort.
The incident response team can classify an incident in one of three ways:
-
Weakness
-
A process or flaw in a system or process that could lead to an impact but there is (as of yet) no evidence or belief that an actual impact has occurred or has attempted to be exploited.
-
Examples include:
-
An organizational asset without anti-malware installed,
-
Unused open ports on a system or firewall, and/or
-
A door to a secure area without a lock
-
-
-
Security Event
-
An action or occurrence that may have (but did not or hasn’t yet) impacted any organizational assets and can be evidenced to that affect.
-
Examples include:
-
A breach of the network, but no data was accessed within the affected network,
-
An asset containing organizational information was sent to the wrong location, but no data was accessed (because the system was encrypted), and/or
-
An unauthorized party entered an organizational location (not a secured location) but did not access any information/assets and caused no damage or disruption.
-
-
-
Security Incidents
-
An action or occurrence that has impacted the organization (i.e., data breach) or cannot be verified with evidence that such an impact did not occur.
-
Examples Include:
-
A breach of the network, and data was stolen or accessed,
-
An asset containing organizational information was sent to the wrong location but was not encrypted and accessed by an outside party, and/or
-
An unauthorized party entered an organizational secured area or a non-secured area and accessed information or assets or caused damage or a disruption.
-
-
It’s important that when a security issues is being classified as an event rather than an incident that there is supporting evidence to verify that no PHI/ePHI/PII was accessed by unauthorized parties. Without this evidence, your organization could be in violation of certain privacy regulations and laws.
It’s also worth noting, that some incident response plans also have a classification for “high severity incidents.” The structure provided here assumes that the assessment performed by your incident response team will include a severity assigned to each level. Either way, how your incident team responds to the identify security issues will depend on the assessment performed in this phase, so be sure to utilize a structure that works best for your organization and team.
Incident Decision
After the security issue (weakness, event, or incident) has been classified (which can be updated later after more information is collected), the incident response team will determine a course of action that:
-
Most securely and quickly addresses the issue,
-
Eliminates or minimizes further impact to the organization,
-
Introduces the least amount of disruption to services, and
-
Prevents further similar issues.
In some cases certain internal occurrences may result in a conflict of interest. In these situations the applicable parties should be removed from the ISIRT and all decision-making roles during the investigation to ensure transparent and un-biased incident decision making and reporting.
4 – Incident Response Process & Recovery
During this phase of incident management, your incident response team will fully manage the impact of the incident and recover (return to normal operational capabilities) from it.
Generally, security issues are responded to and recovered from:
-
As directed by the relevant (to the security issue at hand) ISIRT members and supporting SME’s (Subject Matter Experts),
-
According to the organization’s business continuity plans and disaster recovery plans (which are ultimately incident response plans), and
-
As required by all organizational obligations (statutory, regulatory, and contractual).
If they are not already involved, this is where the more specialized incident response team members will be engaged and offer the most support, such as:
-
The computer security incident response team,
-
Specialized security teams,
-
Threat researchers,
-
Forensic experts,
-
An on call engineer or other consultants, just to name a few.
Response
How your incident response team responds to an incident is based on its assessment of the incident (performed in the previous phase) and should be structured to ensure the issue is:
-
Fully contained as quickly as possible and appropriate,
-
Correctly assessed (the initial assessment should be validated or updated,
-
Remediated / mitigated,
-
Prudently repaired and recovered from,
-
Tracked, and
-
Formally reported as appropriate and in line with all organizational obligations (statutory, regulatory, and contractual).
Your incident response team should have general guidelines for how to respond to each (general) type of incident. This should be developed during the incident planning phase. These plans are typically your organization’s Business Continuity Plans (BCP’s) which should be structured to support business operations, productivity, and incident management.
Recovery
The incident recovery phase is where normal business operations are restored and it’s confirmed that the security issue (weakness, event, or incident) is no longer (or could no longer) impact the organization. Pre-planning for this phase of your incident response plan is typically found within your organization’s Disaster Recovery Plans (DRP’s).
5 – Incident Reporting Procedures
Communication is critical during each phase of the incident response process. There needs to be communication between all the team members, those internal to the organization, and even to affected (and interested) external parties.
This is absolutely critical (and unfortunately either overlooked, or ignored by many incident response teams) to avoid any regulatory, statutory, or contractual obligations. Not handing this correctly can introduce your organization, and its senior management, to very serious (and steep) civil and legal penalties. Not overstating here, it is possible for senior management and others involved, to go to jail for mishandling their incident reporting requirements. Be sure you have competent and professional help here.
Incident Communication – Who, What, When, and How
Different stakeholders want and require different levels of communicated information. To support effective communication, your incident response team should develop a communication matrix that identifies:
-
All possible stakeholders (i.e., senior management, employees, clients, regulatory bodies, etc.),
-
What information each stakeholder must be provided,
-
When communication with each party should take place (i.e., at incident detection, during the management, after resolution, etc.), and
-
Generally how the information will be communicated to each party (i.e., email, phone, mail, etc.).
While at the ultimate discretion the ISIRT and other appropriate stakeholders, notification responses should generally be performed as follows:
-
Notification should be done via email whenever possible,
-
If email is not possible (or appropriate), then direct mail should be provided,
-
In cases where email or direct mail is not a feasible notification method, a notice can be put up on the organization’s website assuming it’s publicly available.
All communications should include:
-
A concise account of what happened (or what is believed to have happened),
-
How the notified party is or may have been impacted,
-
What is being done to address the issue,
-
Next steps (if any), and
-
Contact information for additional questions relating to the matter.
Who is the Primary Communicator
As stated, improperly handing your incident communications can create some serious issues, so no notification should be provided without involving the following:
-
Regulatory, Compliance and/or Privacy Officer(s),
-
Legal Counsel,
-
Public Relations & Media Support,
-
Client Notifications, and
-
Executive management
Your communication matrix should also identify who will communicate with other stakeholders like employees.
6 – Learning From Incidents
Often overlooked (especially in the planning phase and documentation), and one of the most important incident response activities, are the post incident measures. These are critical to further develop your organization’s internal intelligence and identify appropriate security controls to prevent (or lessen the impact) of future security incidents.
Once the issue has been fully resolved and the organization has resumed normal operations, the ISIRT team leader should work with the ISMS Board and all other appropriate stakeholders to review:
-
The issue and its immediate and future impact(s) to the organization,
-
How the issue was identified,
-
How effective the notification process was at supporting the incident process,
-
How the issue was contained,
-
The scope of the impact,
-
Who was notified and how effective the reporting process was,
-
Legal considerations,
-
Regulatory considerations,
-
Lessons learned,
-
Any changes that were implemented because of the issue,
-
Recommended changes, and
-
Any other pertinent information
Changes made from lessons learned will also support the improvement of applicable Business Continuity Plans and Disaster Recovery Plans to better support the organization’s ability to operate during security issues and quickly recover from them. This is a very important phase that makes incident response programs truly effective and is not to be skipped.
7 – Collection of Evidence
Not so much a phase but an extremely important element of the process, is the appropriate collection and preservation of evidence. This can come in many forms such as:
-
Log files,
-
Reports,
-
Communication records,
-
Physical hardware (i.e., hard drives, USB drives, etc.), and
-
Provided notifications.
Evidence should be collected and preserved to support incident’s:
-
Analysis,
-
Decision making capabilities,
-
Response,
-
Recovery (back to operational efficiency),
-
Reporting,
-
Post analysis learning and improvement to prevent data breaches and other exposures in the future, and
-
Compliance with notification regulations (and other applicable requirements).
It’s important to have competent team members support the collection and preservation of evidence especially if this is an issue that may go to court.
Incident Response Teams – Brining it all Together
The proper planning and management of an incident response team is critical to the success of any organization when it comes to data breaches or other security incidents. By following the seven phases we’ve outlined, along with the associated tasks, you can help ensure that your organization is prepared for any potential incident. While no one wants to go through a data breach or other security issue, being prepared will at least give you a fighting chance to minimize the damage and get back to business as usual as quickly as possible. Let us know how we can help you strengthen, support, or even get started with your own Incident Response Plan today.