Call now for cybersecurity help: 888-646-1616
Setting up a Security Operations Center (SOC) is a huge task. It often involves hiring and training staff, licensing and configuring a Security Information and Event Management (SIEM) system and creating numerous processes and procedures. You have options: create your own, outsource the whole thing, or do a combination of the two.
The end result is worth it - protecting client and company data is essential. Setting up a SOC allows you to monitor, expose and react to security threats. Plus, one of the key processes which you’ll learn in this article is to Assess/Improve. The SOC team should learn from past security events and improve the process. One data breach incident is terrible, but can be viewed as an honest mistake. Two data breaches in a few years like Marriot looks negligent and sloppy.
In this article you will learn:
Before we get started, one important note. Building an in-house SOC is a must-have for large organizations, but is usually too expensive for smaller companies. For small firms and their IT managed service providers, we have a section at the end of the article that talks about what we recommend.
A Security Operations Center (SOC) consists of expert information security individuals focused on organizational and technical security issues. The team monitors, detects and responds to cybersecurity threats and incidents using technological solutions and best practice processes. The purpose of having a SOC is to protect the company from security breaches.
SOCs usually consist of a Chief Information Security Officer (CISO), managers, engineers and security/SOC analysts. Do not confuse the SOC with an IT help desk. The help desk is usually focused on individual employee-related IT issues while the SOC is focused on the total organization.
Organizations of all sizes may have a robust SOC in place, but small and mid-sized companies tend to focus on hybrid SOC models, with technological solutions doing most of the heavy lifting.
A Network Operations Center (NOC) focuses on remote monitoring and management (RMM). Although some of their responsibilities are related to that of a SOC, there are major differences between the two.
A NOC is focused on making sure end-users aren’t dealing with technical malfunctions, monitor infrastructure health and provide back end maintenance. A SOC focuses on vulnerability management, breach detection solutions, and overall security threats.
So how does a SOC actually protect a company from security breaches? By following these key processes:
Clearly spelling out roles and responsibilities as well as documenting every step of the process is imperative to the success of the SOC team.
Each of these four critical considerations are detailed below. But if you’re in a rush, the tl;dr version is this: find a SIEM that fits your needs and have the right people in place to configure, monitor and analyze the data.
Security Information and Event Management (SIEM) is a software solution that collects security data and then identifies and classifies incidents and events. In many ways, choosing the SIEM is the easiest part of setting up an SOC, and it’s far from easy.
The SIEM provides reports on security-related incidents (failed logins, malware) and sends alerts based on the alerting logic you’ll need to configure. Ultimately we can’t recommend one service over the other, since there are so many variables to consider. You’ll need to look at your own objectives and choose the SIEM that best fits your needs.
If you're looking for a hosted solution, these tools tend to get expensive pretty quickly. They're processing and storing huge amounts of data, and there's a LOT that goes into administering them. If you don't know what you're doing, you will lose data, your users will get frustrated because the system is so slow, etc. This definitely isn't an "install it and figure it out" situation -- go through whatever training the vendor is offering.
There are also some pretty big operational considerations. You need a LOT of storage space, preferably solid state drive (SSD). Plus powerful servers. And you need to figure out a cold/warm/hot retention cycle that makes sense -- by gathering these logs, they become company records, and need to follow your records retention schedule.
It's not hard to find a system that can receive and store logs. It can be VERY hard to find a system that makes vast amounts of logs queryable, reportable, and alertable, and that doesn't take 30 minutes to run a simple query (looking at you, SolarWinds).
The other challenge you're going to run into with a cloud hosted service (which isn't that hard to solve, but will slow you down) is getting the data from the target machines to the SIEM. Firewalls can easily break connectivity. If you're thinking of logging endpoints, you could even be putting a problematic amount of data over a slower internet connection.
You will have to spend a lot of time configuring and scripting in the system to get the alerts your SOC actually wants to see. Most of them don't come with standard out of the box alerting rules, and even if they do, they still require a lot of tweaking. SIEMs handle so many different data types for so many different sizes and types of organizations that it would be really hard for the vendors to make out of the box rules. You don't need to be a full-bore app developer to write this logic, but you definitely need to be comfortable with whatever logic-defining and scripting language your SIEM supports.
And here's something that's important not to skip -- you need to build logic not only to alert you to suspicious problems, but also to alert you to operational problems. We've seen SOCs who don't get alerts for a few days because nobody realized that they weren't getting data for a few days, that something had lost connectivity. So you need to really be on top of it.
A lot of people think of SOCs as "pump in data, magic happens, get out answers." There is SO much variability in data, and it's often really hard to get anything meaningful out of them.
For example, turn on file-level monitoring on a Windows machine, and then go into Windows Event log and try to figure out what a user actually did. It's nearly impossible. A SIEM doesn't make that problem go away, it just stores it in a place that's easier to search. Another example -- most firewall logs are pretty much useless in actually finding suspicious activity. Fortinets are better than SonicWalls in the logging department, but we get a lot of alerts from our SIEM that we're never able to find any root cause on because we don't have the right data.
For every source you want to ingest, you're going to need to be very specific about what you're trying to find, and what constitutes suspicious behavior. If you get under the covers of most of the SOC services, you'll find that many of them only have very narrow things that they monitor for.
This is, by far, the biggest challenge of rolling out a SOC. Let's say you now have a SIEM, and data's showing up. Who do you have who's trained enough to make sense of them? This requires a LOT of training, and the training is mostly around point #3 above -- you need to really understand what the logs are telling you before you can do any kind of forensic analysis. Also, these people are very much in demand. Looking on Indeed.com, there are almost 1,000 job postings for SOC analysts. And someone needs to manage and train these people too.
Large organizations typically have a dedicated Security Operations Center. But what about smaller or mid-sized companies? As mentioned earlier, they sometimes take a hybrid approach which is more cost effective and may make better sense.
A hybrid SOC set up is a mixture of part-time in-house staff and outsourced consultants. Let the experts choose or configure the SIEM and then work with their staff to triage, analyze, respond and improve.
Here’s a list of SOC vendors:
Hey smaller firms! This part is specifically for you. Building a typical SOC takes time. And money. While a SIEM is easy to install, they’re hard to administer and even harder to find the expertise to get value out of them.
For smaller firms, we think you’ll get a much bigger bang for your buck by using Endpoint Detection and Response (EDR) tools.
The EDR tools that are out there like Sentinel One (which is MSP-friendly) and Carbon Black / Crowdstrike (which tend to be more focused on larger enterprises) provide a TON of really interesting log data about workstations and servers. Rather than building another lookalike SOC that collects network/endpoint/server logs and then tries to make sense of them, we'd suggest picking an EDR tool and creating a SOC-lite service around that. Use the API's built into these tools to suck the data into a data lake (perhaps Google's Big Query) so that you can still have flexibility for querying and reporting, and your "SOC-lite-analysts" will have some of the heavy lifting done for them with the logic built into the EDR tools to detect some suspicious activity.
If you don’t want to build the capability to monitor these tools in-house, there are a number of companies who will do it for you. It’s not cheap, but it can be high value to know that experts are keeping an eye on your footprint.
A SOC-lite service caters well to small and mid-sized businesses. The important point here is to collect the right data and be able to make sense of it. Again, it comes down to having the right technology and the right people to understand the technology.
There are so many points to consider when setting up a SOC, whether you’re a business entity or managed service provider (MSP). Depending on the size of your organization, your budget and your information security knowledge, it might make better sense to choose a hybrid SOC model. The most important components of a SOC are the right tools and the right people to use the tools.
We aren’t the first to write about Security Operations Centers, and we found the following articles to be very helpful:
We can show you how to do MSP cybersecurity right. Book a strategy session to get started.
Have questions or feedback? Please share them in the comments below.
Like this article? Share it!
