When a potential incident occurs, it can be difficult to know who should be notified. Should the incident be reported to someone in IT, the Information Security Officer (ISO), direct supervisors, or someone else entirely?
To facilitate effective incident response, many organizations are beginning to adopt a more formal approach, routing initial incident notifications through a designated member of the incident response team. As incidents continue to grow in frequency and complexity, this team has become a foundational element of a successful incident management program.
So, what exactly is an incident response team? Who should be part of this team and what should they do? To answer these and other questions, we are going to review seven steps for building a successful incident response team.
Step 1: Consider the Purpose
Before you even begin to develop an incident response team, or if you are looking to improve your existing team, the first step is to define the team's purpose. Start with completing the following statement:
The incident response team exists to ____________.
Maybe at your organization, the incident response team exists to ensure the organization's strategic objectives can be achieved. Maybe it exists to secure systems and data. Maybe it exists to develop your incident response plan. Maybe all three of those and more. Start with the team's purpose and use the purpose to guide your other decisions.
Step 2: Name the Team
When it comes to naming the team, it can be beneficial to start with something plain, like "Incident Response Team." This name clearly indicates members of the team exist to help with incident response. Then, based on the team's purpose, you may want to add some flavor. Some variations on the name we see in guidance include appending words like "Security" or "Computer" to the start. For example:
- The Federal Financial Institutions Examination Council (FFIEC) Information Security Booklet uses the term "Security Incident Response Team (SIRT)."
- The National Institute of Standards and Technology (NIST) SP 800-61 Rev. 2, Computer Security Incident Handling Guide uses the terms "Computer Incident Response Team (CIRT)" and "Computer Security Incident Response Team (CSIRT)."
No name is inherently better than the others. You can add as many descriptors as you like. Just be mindful of the fact that each descriptor can clarify or limit the perceived scope of the team's responsibilities.
Step 3: Define the Team Responsibilities
The incident response team should exist for a reason, and that reason should be spelled out a little more than "assist with incident response." Some responsibilities traditionally assigned to the incident response team include:
- Developing and implementing the organization's incident response plan.
- Ensuring all incidents are effectively managed, including:
- Documenting all suspected or actual incidents in the organization's incident tracking system.
- Performing analysis of detected incidents.
- Overseeing the containment, eradication, and recovery of incidents.
- Ensuring the successful completion of all incident response activities.
- Communicating the status of incidents with appropriate stakeholders (e.g., management, law enforcement, customers / members, third parties, etc.).
- Improving the organization's overall security posture by performing tests of the plan and communicating results with management.
Step 4: Determine the Team Structure
When thinking about current common forms of incidents (e.g., ransomware, phishing, third-party failures, etc.), it can be easy to think about the incident only from an IT perspective. If you have helped with managing an incident though, you know involvement in the response process can grow quickly. To ensure the team is ready for an incident, consider the following team structure recommendations.
- Include representation from various departments. In addition to IT and information security personnel, other individuals who will need to be involved with incident response include senior management, legal, audit and compliance, public relations and marketing, business continuity, vendor management, human resources, etc.
- Involve third parties, as needed. Determine if there are any functions on the team which may need to be partially or fully outsourced. Outsourcing certain incident management functions can be a viable option if the organization does not have enough qualified personnel on staff to manage incidents.
- Ensure members of the team have the right skills, authority, and access. Members of the incident response team should have appropriate training to fulfil their role on the team. For example, the team will need to investigate and report findings, access necessary incident management resources, and have authorization or access to senior management for timely approval of incident-related decisions.
Step 5: Establish a Reporting Structure
Incidents have the potential to cause significant strategic, financial, operational, and reputation impacts. As such, while the incident response team may be responsible for creating the incident response plan and managing incidents as they occur, the organization's senior management and Board of Directors are ultimately accountable for the plan's success.
An individual on the incident response team should be designated as the point-person for reporting the program status to senior management and the Board of Directors. Often, this is someone like the ISO, who can participate as a full member of the team, can include status updates in their regular reporting, and has the authority to escalate issues, when needed.
Step 6: Identify Points-of-Contact
Procedures should be defined for reporting incidents to the incident response team. Some organizations create an "on call" style system. Since incidents can occur at any time and often cause more damage the longer they go unresolved, it is important to ensure at least one member of the team is available 24/7. That said, in this kind of environment, it is important to consider something like job rotation and separation of duties, to avoid burnout for your skilled team members.
Contact information for the on-call team members should be made readily available to people who may receive reports of incidents (e.g., IT staff, supervisors, help desk, etc.) and escalation procedures should be defined for what to do if the team members cannot be reached. When a member of the team does respond, they accept responsibility for contacting other team members, as needed, and documenting known details in the incident tracking system.
Step 7: Formalize Your Team Documentation
Depending on the size, complexity, and nature of your organization, other factors may be at play, such as the need for creating multiple incident response teams or having the team be available only on an as-needed basis. For additional considerations regarding incident response team creation, see Section 2.4 ("Incident Response Team Structure") in the NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide.
If you would like assistance in developing and managing your incident response procedures, check out Tandem Incident Management. As part of your organization's overall incident response plan, you can set up teams, define team roles, document team member contact information, and provide a description to outline team charters, strategic goals, and responsibilities.
A designated incident response team plays a key role in the success of an organization's incident management program. With Tandem, we can help you ensure the right components are in the right place.