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. SOC: A look at the similarities, differences
Let's first look at the terms that describe common organizational models of incident response teams. But take these definition 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. Generally though, the meaning is consistent with the formal definition and description of CSIRTs outlined in the 2007 Carnegie Mellon document "Defining Computer Security Incident Response Teams." Its first line reads: "A computer security incident response team (CSIRT) is a concrete organizational entity (i.e., one or more staff) that is assigned the responsibility for coordinating and supporting the response to a computer security event or incident."
This article is part of
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 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.
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.
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":
- 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.
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 is broader in scope
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.
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.
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.