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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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:
Cookie | Duration | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |