The Complete Guide to CSIRT Organization: How to Build an Incident Response Team

What is an incident response team?

An incident response team (IRT) is a team of professionals within an organization who are responsible for responding to and managing any security incidents or breaches that may occur. The IRT typically consists of professionals from various departments within an organization, including IT, Security, Legal, and Management.

The primary goal of an IRT is to minimize the impact of a security incident by swiftly identifying and containing the incident, preserving evidence, and restoring normal operations as quickly as possible. This may involve conducting a thorough investigation to determine the cause and scope of the incident, implementing remediation measures to prevent similar incidents from occurring in the future, and communicating with stakeholders such as customers, partners, and regulatory agencies.

An effective incident response team is critical to an organization’s ability to respond to and recover from security incidents. To ensure their success, the team should have a well-defined and documented incident response plan that outlines their roles and responsibilities, procedures for addressing different types of incidents, and the tools and technologies that will be used to support response efforts. By fulfilling their responsibilities, the IRT plays a critical role in protecting a company’s valuable assets, reputation, and customer trust.

A computer security incident response team (CSIRT) can help mitigate the impact of security threats to any organization. As cyber threats grow in number and sophistication, building a security team dedicated to incident response (IR) is a necessary reality.

In this blog, we discuss how to organize and manage a CSIRT and offer tips for making your IR team more effective. First, let’s define the role and scope of your CSIRT. Consider beginning by following the four-step process shown below to help organize and manage your team.

In this article, you will learn:

• What is a CSIRT?
• How CSIRTs differ from CERTs and SOCs
• Selecting an organization type: Choosing a CSIRT, CERT, or SOC
• How to organize a CSIRT
• Staffing your CSIRT
• An outsourced vs. internal CSIRT
• Where should CSIRT staff be located?
• Developing an IR plan

What is a CSIRT?

A CSIRT is a group that responds to security incidents when they occur. Key responsibilities of a CSIRT include:

• Creating and maintaining an incident response plan (IRP)
• Investigating and analyzing incidents
• Managing internal communications and updates during or immediately after incidents occur
• Communicating with employees, shareholders, customers, and the press about incidents as needed
• Remediating incidents
• Recommending technology, policy, governance, and training changes after security incidents

Overall, a CSIRT analyzes security incident data, discusses observations, and shares information across the company. Some of these responsibilities may be shared with other organizations, which we will discuss below.

How CSIRTs differ from CERTs and SOCs

There are overlapping responsibilities between a community emergency response team (CERT), computer security incident response team (CSIRT), and security operations center (SOC). To addto this confusion, frequently, the terms CERT and CSIRT are used interchangeably, despite the important differences. To add clarity to these terms, let’s start by defining the role of each team with background on where each one originates.

A SOC is a facility where an organization’s network, applications, and endpoints are monitored and defended. The term was adapted from network operations centers (NOCs), where large telecommunication or corporate networks are monitored. When network security became more of a concern, security teams were formed within the NOCs, and eventually spun off into larger organizations of their own as the responsibilities of security teams grew increasingly complex and specialized. The security staff working in a security operations center are often called the SOC team.

The term “computer emergency response team” was coined in 1988. In response to the Morris worm attack that impacted thousands of servers on the Internet, DARPA funded the formation of the Computer Emergency Response Team Coordination Center (CERT-CC) at Carnegie Mellon University. The goal of CERT-CC was to help protect the internet by collecting and disseminating information on critical security vulnerabilities. Several other countries formed similar centers using the same acronym (despite threats of legal action by Carnegie Mellon for trademark infringement). Now the term CERT refers to any emergency response team that deals with cyber threats. Many people use CERT-CC interchangeably with CSIRT, though the charter of a CERT is information sharing in order to help other response teams respond to threats against their own infrastructure.

A CSIRT, on the other hand, is responsible for responding to security incidents. A comprehensive response includes both technical actions taken to remediate the incident, and recommended changes to systems to protect against future incidents. There are several nontechnical aspects to an incident response, including employee communications, responding to press inquiries, dealing with legal issues, and handling any personnel issues in the event of insider action. Other names for CSIRT include computer incident response team (CIRT) and incident response team (IRT).

So, using strict definitions, a CERT collects and disseminates security information, typically for the benefit of a country or an industry. A CSIRT is a cross-functional team that responds to incidents on behalf of a country or an organization. A SOC is where a country or organization monitors and defends its network, servers, applications, and endpoints.

Selecting an organization type: Choosing a CSIRT, CERT, or SOC

Using the strict definitions above, the choice between a CSIRT and CERT is straightforward. Unless your goal is to collect and disseminate information on security vulnerabilities on behalf of a country (which probably is already covered) or industry (which likely already exists), then your choice is between a CSIRT and aSOC.

If your IRT roles include monitoring and defending your organization against cyberattacks, you are looking at building and staffing a SOC. If your organization is too small to afford a SOC, or you have outsourced your SOC, as many smaller organizations do, then you will want a CSIRT to deal with security incidents as they occur. Again, the response may not be technical, but it will require legal or public relations (PR) expertise.

How to Organize a CSIRT

Organizing your CSIRT involves determining who will be on the team, their roles and responsibilities, which functions to outsource, and where your team members will be located.

Staffing your CSIRT

As mentioned, the CSIRT is a cross-functional team that will coordinate during security incidents. The CSIRT should also meet quarterly to review past incidents and recommend changes to policy, training, and technology. Lastly, the team should participate in drills at least twice a year. These drills are considered “table-top incidents” where CSIRT members act out what they would do in the case of an incident, to keep the team’s skills sharp and work out any issues.

To build your CSIRT team, here is a list of the talent you will need, along with the different CSIRT roles and responsibilities:

Team Leader or Executive Sponsor: Typically, this is the CISO or a member of the executive staff. The team leader’s key role is to communicate incidents to the executive staff and board, and to assure that the CSIRT gets appropriate attention and budget.

Incident Manager: This manager or executive can work across the organization and is responsible for calling meetings and holding team members accountable for their action items. The incident manager also summarizes findings and any impacts to communication throughout the company before escalating issues to higher levels of management.

Lead Investigator: This technical resource, such as a security analyst or dedicated incident responder in the SOC, is responsible for investigating the occurrences during a security incident. The lead investigator may work with an extended team of security analysts and forensic investigators.

Communications and PR: Ideally, this is an individual on the marketing team responsible for PR, fielding any press inquiries or statements as needed, and drafting communications to be sent to employees, partners, and customers. This individual should also be responsible for monitoring social media.

Legal: The general counsel or a deputy member of the legal team, this individual advises on the need to disclose security incidents, such as a breach, and deals with any of the fallout resulting from the incident, such as shareholder or employee lawsuits.

Human Resources (HR) Representative: This position is typically filled by the head of HR, who can manage any personnel-related issues that occur, especially if they involve insider theft.

The HR representative also advises on internal communication to employees about security incidents.

An outsourced vs. internal CSIRT

Since the CSIRT roles and responsibilities are cross-functional and involve more than technical staff, it is unlikely to be entirely outsourced, and it probably shouldn’t be, considering how critical cybersecurity is for protecting business interests. That said, you may be able to outsource parts of the CSIRT based on your budget and expertise. Here is a quick summary of the pros and cons of outsourcing the IR team roles.

Where should CSIRT staff be located?

One thing is true of security incidents: they always happen at the most inopportune times — on weekends, after business hours, on holidays, or personal vacations. Hackers have carried out major breaches during holiday shopping season when clerks are rushed and customers can be less diligent about examining their online purchases. Some have theorized that malicious actors attack on weekends or national holidays, knowing that security staff will not be able to catch them in the act.

For that reason, it’s important that CSIRT staff be dispersed geographically. Ideally, someone would be awake and available 24/7. Also, there should be redundancy for every team member, such as having more than one legal expert and PR representative on hand. An easy way to do this is for team members to assign delegates when they are unavailable.

If you have a small organization, or one located in a single country but with customers worldwide, you can consider outsourcing CSIRT functions after hours, on weekends, and during holidays in your geographic region.

Developing an IR plan

Although we are covering this topic at the end of the blog, creating an IR plan is the first thing a CSIRT should do. Organizations that lack experience can hire a consultant to help draft the plan. It is important that the team be fully staffed and participate in the plan creation – even if it’s done with the help of an external consultant — so that the CISRT has familiarity and a sense of ownership.

Here are the critical steps in developing an incident response plan (IRP). It really doesn’t matter if these are slides, documents, or spreadsheets. The most important thing is that the plan be easy to find during the panic of a potential crisis, and simple to understand by someone who is overwhelmed in the moment.

1. Gain executive buy-in: Your team leader will be the one to spearhead this. If this individual is a member of the executive team, such as the CIO or CISO, then this step will be much easier. Make sure the CEO, CFO (who may deal with investors), chief counsel, and other key members of the executive team are informed and in agreement on the charter. The CSIRT will be looking at sensitive information and communicating delicate details, so it is essential that the team be trusted and supported at the executive level.
2. Confirm roles and responsibilities: Based on the staffing guidelines above, confirm the definitions of the roles and ensure that everyone is in agreement. Establish a backup for each role in case someone is on vacation or otherwise unreachable. Importantly, get agreement from your CEO or other leadership when executive approval is needed, and decide in which situations the CSIRT can act on its charter.
3. Document critical assets: Map out your critical systems and intellectual property (IP). Understand the value of source code or web properties. Know the financial impact of a network going down. You want to know the impact to the business when something goes down or goes missing, such as critical data. One critical asset is your customer database. There may be breach notification requirements, and even penalties. Examining reports from past audits may also be useful in this step.
4. Establish a communications plan and protocol: Determinehow the team will communicate. For example, if there were a crisis where half the IR team was waiting on a conference bridge, and the other half was waiting on Slack, who would be designated to initiate the call? Who would do it if that person was not around? How often should you provide updates to the executive team? When would you need to get permission from an executive who is not on the team? Ideally, consider all scenarios and work out approvals in advance.
5. Draft core communications in advance: List all your potential incidents in advance, such as theft of customer data, critical system compromise, network or site down, cyberbullying by an employee, and so on. Then draft social media posts, short statements for the press, and even a press release for a serious incident that requires legal disclosure. Previously, these were called “drawer statements” as they were kept in the desk drawer for emergencies. Once drafted, have them vetted and approved by your legal team — that way you don’t need approvals in the middle of a fire drill.
6. Prepare by conducting drills: Like the communications issues we mentioned above, there are many things that can go wrong or fall through the cracks during a crisis. Have your team leader organize periodic drills and walk through your process. It will not only highlight potential issues, but drills also give the team more confidence.
7. Socialize the CSIRT charter to the company: First, have your CEO and executive team review and approve the CSIRT’s charter and draft plan. Once you have approval, let your company know about the CSIRT and its charter. Also, let the company know how you will be communicating during a public security incident. The last thing you want is every salesperson in the company emailing your PR contact or worse, your CEO — asking about what is happening. Lastly, make it clear that only members of the CSIRT will be writing and disseminating communications to customers and partners.

Ultimately, you will learn from experience. so it’s important that you continually collect feedback and refine your process. This may involve making a number of adjustments, such as adding or changing team members, and changing how you communicate.

Security incidents will happen that are outside of your control. How you build a CSIRT dedicated to dealing with these incidents will depend on you.

Editor’s Note: Tim Matthews was previously a CSIRT member at a public company, responsible for communications and public relations during incidents.

Want to learn more about Incident Response?

Have a look at these articles:

• The Three Elements of Incident Response: Plan, Team, and Tools
• 10 Best Practices for Creating an Effective Computer Security Incident Response Team (CSIRT)
• How to Quickly Deploy an Effective Incident Response Policy
• Incident Response Plan 101: How to Build One, Templates and Examples
• IT Security: What You Should Know
• Incident Response Steps: 6 Tips for Responding to Security Incidents
• Beat Cyber Threats with Security Automation
• IPS Security: How Active Security Saves Time and Stops Attacks in their Tracks