CSIRTs need proper tooling, relationships, and a solid technical background. However, to have any kind of authority, teams need to be recognized within an organization’s InfoSec or computing policies. Having a CSIRT internally means an expectation of network monitoring, as well as possible investigations into activity performed on an organization’s assets. Policies accepted by everyone in the organization must include language indicating the role and obligation of the CSIRT.
Company policies specifically stipulate (dis)allowed behaviors, requirements, processes, and standards. Rules are made to be broken, so policies must be enforced. These policies will serve as the basis for your charter. A solid charter will help you identify roles and responsibilities that your CSIRT will require to be successful in your own environment. For instance, if you provide a paid service to customers, what level of detection capabilities (if any) do your clients expect? Who is responsible for physical security at your organization? Are PC rebuilds mandatory to fix malware infections? Ideally, your charter should be documented, accessible, and approved by your management and senior management, as well as third-party groups such as legal or HR. It is from this charter that you will draw your enforcement powers.
Not every possible activity a CSIRT might perform necessarily has to be enshrined in policy; however, it can be beneficial to explicitly mention a few directives. Remember that all policy development should be closely aligned with an organization’s overall strategy and operations. Not every CSIRT will enforce identical policies; however, fundamentally they should be expected and explicitly permitted to:
Again, policies are totally dependent on a business and the role a CSIRT plays, whether internal or external. Having a defined constituency can also clear up any gray areas about a CSIRT’s span of control. For example, a CSIRT might be charged with protecting corporate or organizational data, but not customer data. On the other hand, a team might be responsible for monitoring corporate networks, customer networks and data, and partner interconnections. Understanding the scope of a CSIRT’s mission helps ensure proper resourcing and expectations.
The incident response team has the authority to implement necessary actions for incident management, including but not limited to, removal of network access, revocation of access rights, or seizure and forensic examination of electronic and computing devices owned by [organization] or devices communicating on internal networks and business systems, whether owned or leased by [organization], a third party, or the employee. Data collected or analyzed during the course of an investigation will be handled according to the procedures described in the Incident Response Handbook.
In adherence to event logging, intrusion detection, incident handling, and monitoring standards, the incident response team must monitor the [organization’s] network and any networks owned by [organization], including all interconnections and points of egress and ingress.
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.
Figure 1: This four-step process helps to organize and manage a computer security incident response team (CSIRT).In this article, you will learn:
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.
Table 1: How to decide on utilizing a CERT, CSIRT, or SOC team.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.
Table 2: Here are the pros and cons of outsourcing the various functions of your CSIRT.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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
What is incident response charter?
In terms of purpose, the organization IRT charter clearly defines the authority, scope, roles, goals, responsibilities, and memberships for the Computer Security Incident Response Team (CSIRT).
A Computer Security Incident Response Team (CSIRT) is a service organization that is responsible for receiving, reviewing, and responding to computer security incident re- ports and activity.
Forensic tools are valuable not only for acquiring disk images but also for automating much of the analysis process, such as: Identifying and recovering file fragments and hidden and deleted files and directories from any location (e.g., used space, free space, slack space)
