Free DownloadWhat is incident response? Plans, teams and tools
Incident response is an organized, strategic approach to detecting and managing cyber attacks in ways that limit damage, recovery time and costs. This guide shows how to establish an incident response strategy. It then outlines steps needed to craft a plan and put in place the team and tools required to minimize the fallout when a cyber attack hits your organization.
CERT, CSIRT, CIRT and SOC are terms you'll hear in the realm of incident response. In a nutshell, the first three are often used synonymously to describe teams focused on incident response, while the last typically has a broader cybersecurity and security scope.
Still, terminology can be important. Inconsistent terminology can cause misunderstandings of what is meant and can confuse your team's incident response effort planning by complicating the understanding of accepted practices.
To that end, here's a deeper look at the terms.
CERT vs. CSIRT vs. CIRT: What do they stand for?
Let's first look at the terms that describe common organizational models of incident response teams. But take these definitions with a grain of salt -- just because two organizations both call their response team a CSIRT, for example, doesn't mean those two teams have the same goals or methods, or conform to an idealized definition.
CSIRT stands for computer security incident response team. CERT stands for computer emergency response (or readiness) team. And CIRT can stand for either computer incident response team or, less frequently, cybersecurity incident response team. CSIRT, CERT and CIRT are often used interchangeably in the field. In fact, CSIRT and CIRT are almost always near-equivalent; essentially they are synonymous. An organization might prefer one or the other based on the organization's language or style, or subtle differences in organizational scope.
As for the term CERT, although many companies use the term generically, it has been a registered mark of Carnegie Mellon University since 1997. Companies can apply for authorization to use the CERT mark. Companies that have not done so should not use that term for a consulting service name or managed security service provider, or they might be infringing on that. Therefore, if your organization does use the term CERT as part of a response team name, it's useful to have a candid conversation with legal or internal counsel about that usage.
Just because two organizations both call their response team the CSIRT, for example, doesn't mean those two teams have the same goals or methods, or conform to an idealized definition.
Part of the challenge with organizations using the name CERT internally is that it can be confusing. Is CERT intended as a synonym for CSIRT or is the organization trying to convey something else? Both can be true depending on context.
Carnegie Mellon's CERT designation has a particular focus and niche it occupies; it operates as a "…partner with government, industry, law enforcement, and academia to improve the security and resilience of computer systems and networks…" A CERT studies "…problems that have widespread cybersecurity implications and develop[s] advanced methods and tools."
Some organizations reflect this in the way they use the term. In other words, they use CERT to reflect that their internal team's focus is subtly different from that of a typical CSIRT. For example, maybe the team places additional emphasis on partnership with other internal or external teams and organizations, has more focus on methodology and tool development (e.g., those designed to forecast issues before they arise), or focuses more on emerging threat research (e.g., adversary methodology or tradecraft). The term CERT used in this way focuses more broadly on improving incident response as a discipline than on just its own organization.
Still other organizations that use CERT -- generally those unaware of CERT's status as a registered service mark -- use the term as a synonym for CIRT or CSIRT.
What are the differences between CERT, CSIRT and CIRT?
Practitioners should understand the fluidity with which teams use these terms. CERT, CSIRT and CIRT groups can exist as a permanently staffed group or can be pulled together on an ad hoc basis in response to an event. Either way, their focus is almost always the four phases of incident response outlined in the NIST "Computer Security Incident Handling Guide":
preparation
detection and analysis
containment, eradication and recovery
post-incident activity
These phases concentrate on the detection and remediation of security incidents. They also include the governance structures an organization uses to prepare for security incidents and the post-incident activities designed to streamline future efforts.
There is nuance here, though. Not every group at every company does the same thing. Some teams might use a term like CSIRT in a way that aligns with NIST's guidance, but put their own spin on what they do. For example, one organization might see the role of their CSIRT as focused more on policy while another might be more focused on operational issues like looking through log files and tracking activity on the network.
What is a SOC and how is it different from CSIRTs, CERTs and CIRTs?
A security operations center (SOC) is another term you'll hear in the context of incident response teams. However, a SOC generally encompasses multiple aspects of security operations, while CSIRTs, CERTs and CIRTs focus specifically on incident response.
A SOC's purview can include the incident response function (either in whole or in part) as well as other tasks. For example, a SOC can:
encompass monitoring operations and controls (such as an intrusion detection, system/intrusion prevention system, security information event management/security information management);
oversee evaluation of operational and security telemetry and information gathering; and,
manage tasks such as identity management and authorization, firewall and filtering ruleset maintenance (both review and change management), forensics and investigation support, or any other aspect of operational security.
CSIRTs and CERTs focus specifically on incident response. The two terms are often used synonymously but are technically distinct. Among the differences: CERT is a trademarked term and associated more with partnership on threat intelligence, while a CSIRT has more of an association with a cross-functional business team. In contrast to the other two, a SOC's purview is broader than incident response and extends to other areas of security.
A SOC's monitoring efforts is likely to extend beyond incident response. A SOC might harvest and collect metrics to support customer service or service delivery (at a managed security service provider, for example) or it might support management reporting like preparation of metrics and data to support risk assessment or for audit support. While a SOC often comes up in the context of incident response, it almost always has other elements of security within its scope of responsibility. A SOC is likely to have a broader operational purpose and scope than a CSIRT or CIRT. If there is a SOC in a given organization, incident response likely falls within the purview of the SOC as an operational security function. Again, the specifics depend on the organization.
Should you implement a CERT/CSIRT/CIRT or SOC?
With a clear understanding of these terms, organizations can identify which type of incident response team is right for them and how to build the security team of choice. The choice should be based on your organization's goals, structure and use of resources. For example, if the need for monitoring is paramount and your organizational structural is conducive to allowing centralization of that in one physical or logical location, there may be advantages to creating a SOC (for example, economies of scale or a simplified reporting hierarchy). By contrast, if your organizational structure is more decentralized, or otherwise not conducive to centralization of monitoring and other security operations, a CSIRT may make more sense.
It's important to evaluate the relative advantages of both, understand your organization's needs, and select the approach that's optimal for your enterprise.
