Platform Features
By Need
By Industry
Partner Program
Our Partners
Resource Center
{ "term_id": 162, "name": "Harold Bell", "slug": "harold-bell", "term_group": 0, "term_taxonomy_id": 162, "taxonomy": "wpx-authors", "description": "", "parent": 0, "count": 91, "filter": "raw" }
This article examines the composition and purpose of the computer security incident response team (CSIRT). CSIRTs comprise a collection of professionals with varied backgrounds in IT and cybersecurity. Their purpose is to respond rapidly and efficiently to cybersecurity incidents, but also to work towards preventing the occurrence of such incidents in the first place.
A CSIRT is a group of people, joined in a formal organizational unit, whose defined mission is to provide fast, results-getting responses to cybersecurity incidents, such as data breaches or ransomware attacks. Risk mitigation is also typically a focus for the CSIRT, as preventing an attack is preferable to reacting to one. To this end, CSIRTs provide services for assessing and managing risks, with the goal of preventing cyber emergencies. The foundational assumption is that any organization that relies on computers needs to have a formal incident response capability, executed by a dedicated team.
A CSIRT likely does not perform every incident response process. Rather, the team supplements its own efforts by coordinating actions from other groups, working from plans and protocols they have prepared. In particular, the CSIRT tries to contain the threat or attack, eradicate the threat, and then oversee the recovery. For example, if malware takes over a server, the security team will follow the CSIRT’s existing protocol and isolate the server so the malware cannot spread across the network. The CSIRT will then coordinate the execution of a process that eliminates the malware and restores the server to proper functioning.
Oftentimes, the CSIRT will conduct a post-incident investigation and either perform or direct others to take care of follow-up tasks, e.g., patching operating systems, resetting firewalls, or making sure that defensive technologies like intrusion detection systems (IDS’s) are configured to catch whatever malware got through to the server. As part of this process, the CSIRT may update its response plan. Additionally, a CSIRT may get involved in reviewing and revising security policies. It may manage audits, too.
CSIRTs have been an established part of the information security landscape for many years, a fact reflected in the name itself—harkening back to an era when a few large computers dominated what was then called the management information systems (MIS) department. No one today would say, “We had a computer incident.” Back then, though, if “the computer,” perhaps a massive mainframe in a “glass house,” had a security problem, the CSIRT was there to respond. Cybersecurity has gotten a lot more serious and complex in the intervening decades, but the need for a CSIRT remains. If anything, organizations need a CSIRT more than ever.
CSIRTs are a necessity because the stakes are so high in today’s severe threat landscape. Companies and public sector organizations must defend themselves against persistent and sophisticated adversaries. In some cases, attacks come from nation states. A bad cybersecurity incident can cause significant damage to operations, finances, and reputation. A well-planned, fast-moving response is an absolute imperative. That’s what CSIRTs offer.
Today, the role of the CSIRT is blending into a number of different areas of IT and security. For example, if a company has a security operations center (SOC), the team that runs it will work with the CSIRT, perhaps using its procedures. In some cases, technology itself has taken over some of the CSIRT’s traditional duties. For example, a security orchestration, automation, and response (SOAR) platform may have CSIRT policies embedded in its workflows and threat mitigation “playbooks.”
Every CSIRT has its own distinct composition. However, most CSIRTS combine people and policies in ways that clearly define their missions. In terms of people, a CSIRT usually has a core group of dedicated members that is supplemented by experts who work with the CSIRT on an as-needed basis. The team members invariably come with different backgrounds and skillsets. For instance, some are experts in defending Windows systems, while others know about Linux. The core team may be assigned to the CSIRT full-time, but that occurs mostly at very large organizations. In most cases, CSIRT team members have “day jobs” in IT and cybersecurity departments.
Regarding policies, in addition to the CSIRT’s mission statement and written definitions of relevant constituencies, the CSIRT will create and maintain a set of documents that establish how the CSIRT functions. For example, a CSIRT usually has a central incident response plan that declares, in writing, how the team handles on-site incident response processes versus handling incident response by phone. The plan reveals how the CSIRT coordinates incident response by allocating team resources across multiple constituent groups.
As part of this effort, a CSIRT will publish forms and contact directories to share with each group it services in the organization. This may sound like an unnecessary step, but experience has shown that key stakeholders often don’t know whom they are supposed to contact if there is a security incident. For example, if the CEO’s laptop is stolen, will his or her administrative assistant know to contact the CSIRT, or will he simply call the IT help desk—who themselves may need clear prompts to activate the CSIRT.
A CSIRT also compiles many internal policy and procedure documents. These cover how the CSIRT functions, how they respond to incidents, who is who and who does what, as well as how to prepare incident reports and more.
The specifics of these policies will vary according to the CSIRT structure. The common organizational approaches to establishing a CSIRT include:
The main work of CSIRTs is incident response. As one might imagine, having the desired impact is all about being quick, but also accurate in the response process. Each CSIRT works differently, but the goals are always the same: minimize damage to systems and data; eradicate the threat; and quickly restore systems to operating status.
Preparation is one of the key success factors. It’s not glamorous work, and it may seem that the CSIRT “isn’t doing anything” between emergencies. However, the truth is that the CSIRT is constantly honing its policies and procedures and checking in with its partner groups in the organization. For example, the CSIRT is regularly updating the SOC’s SOAR system and its incident playbooks. On a related front, the CSIRT is always studying the latest threat data, perhaps in sync with an information sharing and analysis center (ISAC).
When an incident occurs, the CSIRT springs into action. It works to contain the threat while notifying all necessary stakeholders, such as the IT department, business managers, the legal department, the public relations team, and so forth. Once it has contained the threat and isolated it, the CSIRT remediates it, perhaps by applying a system patch—and instructing the IT department to patch all similar systems. The CSIRT then prepares an incident report for relevant stakeholders and updates its policies and procedures to avoid a repetition of a comparable incident in the future.
A PSIRT, or product security incident response team, is analogous to a CSIRT, but it is focused on security aspects of a company’s products. For example, if a company makes computer hardware, the PSIRT is responsible for handling any security incidents that arise with the product. That might mean keeping up with patches on the product’s firmware and repairing customers’ infrastructure if the product is a target of a cyberattack.
Structurally, the PSIRT is comparable to the CSIRT. It comprises experts in complementary areas of cybersecurity, IT, and compliance. Organizationally, the PSIRT is usually based in the company’s secure engineering organization. This way, the PSIRT contributes to the company’s secure development lifecycle (SDL). The PSIRT may also get involved in the requirements gathering process, offering risk modeling advice and helping to ensure the creation of a secure end product.
What does it take to build a CSIRT that gets the job done? Best practices run the gamut from maximizing CSIRT availability (24/7) to cross-training team members. The more people know how to do things, and have the ability to do others’ jobs in a pinch, the more effective the CSIRT will be. Ongoing training in general is a best practice. A good CSIRT is always building its skill base and refining its practices. It pays to model risks and scenarios and rehearse how the CSIRT will respond. It’s also a wise practice to establish relationships with executive sponsors across the organization. A CSIRT is not an inexpensive proposition, so its existence may be called into question in lean times. Therefore, it’s good to have advocates in high places.
The CSIRT is an essential element of a successful cybersecurity strategy. This is because every business today faces substantial disruption and expense if a critical system goes down or suffers a data breach. A CSIRT can mitigate the worst business impacts of such an event. CSIRT members collectively have expertise that enables them to respond quickly and effectively to cybersecurity incidents. They also help prevent attacks. Due to their policy making authority, the CSIRT’s role expands, rather than recedes as security processes modernize and become more automated.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.