How to structure your CSIRT or SOC team
Organizations must consider their wider security requirements before deciding if they require a CSIRT, a SOC or both.
Pronounced see-sirt, a computer security incident response team (CSIRT) performs three main tasks: (1) receives information on a security breach, (2) analyses it and (3) responds to the sender. A sock, on the other hand, is a security operations center (SOC). Its job is to detect and prevent cyberattacks on an organization.
CSIRTs are usually horizontal across an organization and often involve personnel other than the security team, including public relations, marketing, customer support and management. On the other hand, a SOC is a centralized, standalone function/department. If we consider SOCs as active security practitioners, then we might say CSIRTs are reactive.
In this article, we present details on both to help organizations better understand the relevance of each to their business and decide if they need one or the other in place, or both.
What is a CSIRT?
CSIRTs exist in several forms. They can be ad hoc groups who come together when a security incident occurs, drawing membership from an organization’s various functions as required to respond to the incident. They can also be more established groups, with a recognized membership that immediately knows its responsibilities when an incident occurs. The frequency of security incidents and their seriousness, along with other individual factors, will determine whether an ad hoc or established group best fits an organization.
While these are internal CSIRTs, two flavors of external CSIRT also exist: (1) national- or government-level, responsible for overseeing incidents within their jurisdiction; (2) private companies, who provide paid-for services on a regular or as-needed basis to organizations.
What are the responsibilities of the CSIRT?
In addition to its chief tasks of receiving, analyzing and responding to security incidents, CSIRTs may also support SOCs via the following:
- Review standard security arrangements — that is, provide external/semi-external reviews
- Manage audits and training for new threats
- Investigate new vulnerabilities and share the latest industry-level responses
- Liaise with different internal and external stakeholders when an incident occurs
- Manage remotely‑stored critical information (passwords, network configs, etc.) in an emergency
When should you create a CSIRT?
Creating a CSIRT when an incident occurs is akin to shutting the stable door when the horse has bolted. Instead, responsible organizations will already have an incident response plan (IRP), and when an incident occurs, this manual will list the different actors who have specific responsibilities.
CSIRTs are especially important around the times when the organization considers itself vulnerable or if it is undergoing technology or process changes. If not already in place, this is when a CSIRT should come into being. From there on, the CSIRT should remain in place. The type of CSIRT (ad hoc vs established) and responsibilities it assumes (response-only vs support of SOC) must be decided within the organization and should factor in the likelihood of events/attacks, impact of such breaches, and ultimately, a cost-benefit analysis for resourcing a semi-permanent response team.
CSIRT membership roles
The personnel involved should be matched to the particular organization and the incidents it must respond to. The following roles are commonly found on CSIRT teams, though the same personnel may fill more than one role:
- Team leader: Directs CSIRT and is responsible for response procedures, including analysis and updates for future incidents
- Incident leader: Coordinates individual responses and is an expert on the area/equipment where the incident occurred
- Support members:
- IT: Expert on overall IT infrastructure
- Management: Communicates with management regarding concerns from both sides
- PR: Communicates with public and/or customers to maintain business relationships
- Legal: Advises on likely ramifications for organization or individual(s) involved
While CSIRTs respond to security incidents, SOCs try to prevent them from occurring in the first place. SOC personnel are responsible for continuously monitoring and analyzing an organization’s security arrangements; ultimately, protecting its infrastructure and its data. Analysts and engineers, supported by managers/admins, staff the SOC and oversee day-to-day security operations. They convene CSIRTs (internal or external) for additional support when required.
For the most part, SOCs will be an internal, permanent function of the organization. While some smaller organizations may out-source security, their personnel will form part of the ongoing, informal SOC with the subcontracted vendor.
What are the responsibilities of the SOC?
SOCs have three main tasks:
- Establish and maintain a security information and event management (SIEM) system that receives security-relevant data, such as user access events, persistent outbound data transfers, firewall allows/denies, etc.;
- Analyze the SIEM logs to identify suspect or malicious activity, including indicators of compromise, event correlation rules and evaluating details from potential adversaries;
- Suggest solutions to defend the organization from current threats and likely future vulnerabilities.
When should you create a SOC?
In certain circumstances, a SOC may be necessary to comply with industry rules such as Payment Card Industry Data Security Standard (PCI DSS). Alternatively, an organization may arrive at a situation where its data is now valuable enough to warrant a SOC — beyond having a standard set of security instruments and procedures in place. Additional factors to consider include: risk management, standards and best practice in the sector, previous cyber threats and insurance requirements.
SOC membership roles
As with CSIRTs, membership of a SOC will vary from organization to organization, but the following roles will be common in most SOCs:
- Chief Information Security Officer (CISO): Responsible for defining the overall security operation of the organization; may also manage compliance tasks and communicate with management regarding security issues
- Manager: Oversees all SOC activities, including managing other members and creating new policies and procedures
- Security Engineer: Maintains and recommends new monitoring/analysis tools; builds security architecture and liaises with developers to ensure systems are up-to-date
- Security Analyst: Detects, investigates and responds to threats; may also implement additional security measures where required
CSIRT vs SOC
CSIRTs and SOCs may be interchangeable in some specific situations. We can make various statements showing their relationship, such as “CSIRTs are a sub-section of SOCs” or “established CSIRTs can be considered SOCs if they meet on a monthly/weekly/daily basis.” In addition, the same personnel will often be involved in both entities.
However, if every organization considers itself unique, then their security requirements are also unique. Thus, only by answering the questions posed in the preceding sections on “When should you create a CSIRT/SOC?” can an organization decide whether it needs one or the other, or both. Then, appropriate responsibilities and related tasks can be defined to match the wider security needs of the organization.
- SOC vs CSIRT… What is the Difference?, CyberSponse
- Creating and Managing an Incident Response Team for a Large Company, SANS
- CSIRT Frequently Asked Questions (FAQ), CERT
- Security Operations Centers and Their Role in Cybersecurity, Gartner
- What is a Security Operations Center, Digital Guardian
- Building a World-Class Security Operations Center: A Roadmap, SANS
- Understanding the SOC Team Roles & Responsibilities, Siemplify
- The Best Strategies for a Successful Security Operations Center Explained by 4 Security Experts, Rapid 7
We've encountered a new and totally unexpected error.
Get instant boot camp pricing
A new tab for your requested boot camp pricing will open in 5 seconds. If it doesn't open, click here.