The Complete Guide to SOC Organization: How to Build an Incident Response Team
A security operations center (SOC) 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.
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 add to 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.
SOC
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.
CERT
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.
CSIRT
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 a SOC.
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.
How to Organize a SOC
Organizing your SOC 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 SOC
As mentioned, the SOC is a cross-functional team that will coordinate during security incidents. The SOC 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 SOC 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 SOC team, here is a list of the talent you will need, along with the different SOC 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 SOC
Since the SOC 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 SOC based on your budget and expertise. Here is a quick summary of the pros and cons of outsourcing the IR team roles.
Where should SOC 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 SOC 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 SOC 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 SOC 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 SOC 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 SOC 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: Determine how 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 SOC 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 SOC 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 SOC 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 SOC dedicated to dealing with these incidents will depend on you.
source:
