Why a commercial SOC is not Netflix: what to know before connecting monitoring

Buyer of Cyber Peace

Imagine a top manager of a large Russian company. In his hands is a freshly signed contract for commercial SOC services. The air is filled with the smell of fresh toner and a barely perceptible feeling of relief. A checkbox has been ticked in the annual report, the budget has been allocated, and a huge stone called "Cybersecurity" has been lifted off his shoulders. Now real experts will take care of it — the problem is solved.

Not so fast! Our imaginary hero thinks he has subscribed to a service like Netflix: pay and enjoy the results. But in reality, he has signed up for a relationship that requires attention, open communication, and collaboration.

His phone hasn't started ringing off the hook with emails titled "Urgent: clarification on infrastructure," nor has his calendar been filled with meetings called "Log sources synchronization."

If approached incorrectly, he will face a multitude of new concerns. To ensure this process doesn't end in failure, let's understand why the "buy and forget" attitude is the wrong approach to cybersecurity.

The Psychology of the Silver Bullet

What drives company leadership to seek SOC services? Three main reasons can be identified.

The Great and Terrible Regulator

More often than not, the story begins not with a desire for protection, but with a fear of punishment. Regulatory requirements (Federal Law 187-FZ, GOSTs, and Central Bank directives) loom on the horizon, inspections, and very real fines. The task set by company management sounds not like "ensure security," but like "meet the requirements."

In this paradigm, the SOC is perceived more as a formality that needs to be observed. It results not in protection but rather in a theater of security. When monitoring services are purchased to comply with regulatory requirements, their implementation is often treated with insufficient attention.

The Magic of Marketing

The internet is full of advertisements promising that the SOC will solve all your cybersecurity problems at once. As you understand, there is not a word about asset inventory and the need for interaction with an external team.

Often, a client who is not immersed in best practices for information security perceives the service not as a process but as a ready-made solution. They expect that by delegating the task to external specialists, they can completely relieve themselves of protection issues. They hear not "we will work together," but "we will do everything for you." And, of course, they happily sign the contract without really knowing what SOC is and why exactly they need it.

The Illusion of Self-Readiness

This is perhaps the most insidious reason. A company may be sincerely confident in the satisfactory level of its security. However, this confidence is often based not on objective data but on a lack of internal expertise.

Purchasing a SOC in this case leads to a painful examination that reveals a whole bouquet of long-standing problems that no one suspected. This is where the most interesting part begins—the clash of expectations with reality.

A Recipe for Successful Implementation

Any SOC implementation project relies on three pillars: people, processes, and technologies. Let’s break down each of them.

Do you have a team or just the last resort?

The most common misconception: "We bought a SOC to relieve our specialists of their workload." In fact, the workload will not disappear; it will simply change, and if the right people are not prepared for this, then the effectiveness of monitoring will be low.

Suppose the company appointed its best system administrator, a person who is already stretched thin, as responsible for interacting with the SOC. Most likely, they simply will not be able to respond quickly enough to requests from the SOC.

A Story from Practice

Imagine, an SOC analyst detects suspicious activity on the client's server coming from a contractor's account that should have been disabled long ago. Someone is trying to access internal systems. The time is 3:15 AM. This is a clear incident, so the analyst begins notifications through all available communication channels specified by the client. However, it is difficult to promptly contact the responsible specialists at night.

In such a situation, the SOC operates strictly within the framework of the powers and procedures previously agreed upon with the client. The team initiates approved playbooks and blocks suspicious sessions. These measures help limit the actions of a potential attacker.

However, some critically important measures — for example, making changes to the network infrastructure or disabling key systems — require direct involvement from the client’s team.

And attackers do not wait; often they specifically attack during off-hours, on weekends, and holidays.

How to Avoid Such a Scenario

To ensure effective interaction with an external SOC, it is important to define and approve the acceptable level of operational authority in advance and ideally organize an internal team of cybersecurity specialists who will communicate with the SOC in the same language. If such a team does not exist, at least one dedicated employee with clearly defined responsibilities is needed.

Successful incident response is built on clear and uninterrupted interaction. For this, it is important to have a duty schedule and at least two, preferably three contacts for escalation. Moreover, these individuals must have the rights and technical capability to promptly execute the SOC’s recommendations (block an account, isolate a host) at any time of the day.

Service Provider Contract

Clients often do not understand that the SOC cannot operate effectively without established and, more importantly, honestly described processes on their side.

Case Study

During the onboarding process, the client provides the SOC with a diagram of their infrastructure. Monitoring begins, and after a couple of months, the company gets hacked. How? Through an old terminal server that was once set up for contractors and then simply forgotten about.

The SOC will not notice this because it simply did not monitor this segment, which the client forgot to tell us about. The segment is compromised, the client is dissatisfied, and the SOC appeals to the questionnaires. This situation is a good illustration of why one of the key tasks at the start is not just obtaining the scheme but also working together to verify it and identify "blind spots".

Unfortunately, SOC specialists physically cannot know about all corners of the client's infrastructure. They only see what falls within the monitoring systems' purview. Gray zones—areas of the network without adequate security coverage—remain invisible until the client mentions their existence.

The completeness and relevance of information about the infrastructure is the foundation for quality monitoring. Internal client specialists play a key role here, as they better understand the actual network topology, the list of active systems, and plans for deploying new equipment. The more complete this picture is, the more qualified recommendations on information security the SOC can provide.

How to avoid such a scenario

Therefore, before connecting to the SOC, it is advisable to conduct a thorough and meticulous inventory of IT assets together with an external team of experts, including test benches and equipment in remote branches.

Additionally, the interaction regulations should not be treated as a formality. They must clearly outline areas of responsibility, SLAs, and procedures for different types of incidents. This document should be agreed upon, signed, and readily available to all participants in the process.

Why SIEM is a scalpel, not a sledgehammer

Many clients think that advanced SIEM, SOAR, and TIP systems are the main components of a SOC. But in reality, technology is just a tool that relies on a foundation of people, processes, and your network architecture.

SIEM itself is merely an engine for collecting, normalizing, and correlating events. If you "dump everything" into it without a well-thought-out threat model and correlation rules, it quickly turns into a very expensive log storage that generates thousands of alerts per day.

One of the main tasks of the SOC is to set up rules in such a way as to highlight truly suspicious chains from the event stream, such as strange log sequences, combinations of events according to the MITRE matrix, and anomalies in access time and geography. It is important that the client provides such data sources and network architecture that there is actually something to assemble these chains from.

Practical Case

The SOC team deploys a standard, time-tested script for collecting events on the client's workstations, but it does not work. It turns out that some machines at the client have the latest version of Windows 11 installed, which was released very recently.

The problem was on our side: we were deploying Sysmon through scripts and using the WMIC command to get the path. In Windows 11, this command is no longer supported, which is why the standard installation script simply stopped working.

A technical detail that neither the client nor, initially, the SOC specialists were aware of. Although the engineers quickly found the reason, adapted the scripts for the new OS version, and completed the deployment, this detail temporarily halted the process of connecting an entire segment of the network. And there are dozens of such pitfalls—not only in the infrastructure of each client but also in the industry as a whole.

Of course, SOC teams do not stand still; they constantly update their knowledge based on accumulated experience and industry trends. Each such case becomes a lesson that helps avoid similar problems in the future.

How to Avoid Such a Scenario

The effectiveness of the SOC's work directly depends on the quality of the analysis products provided by the client. The analogy is simple: the SOC provider is the chef, and you are the supplier of ingredients (logs). If their quality is low or if there are not enough logs, nothing will work.

In practice, "quality logs" are not about "maximizing audit." For domain controllers, this means at least correctly configured Security Logs with logging audit policies, permission changes, account management, and group policies. For workstations: events related to script execution, PowerShell, attempts at privilege escalation. For Linux servers: system logs, authentication, sudo, attempts to access critical services. For network equipment: authentication logs, administrative actions, VPN sessions, configuration changes. If there are gaps in this set, the SOC will only see part of the picture.

To close these gaps, it is important to consider three things. First — resources: it is crucial to ensure that your network can handle the additional load from event collection, and that servers (in a hybrid model) meet the requirements. Second — competencies: engineers are needed to configure log sources (domain controllers, Linux servers, network equipment) according to SOC instructions. SOC specialists will certainly do their best, but they may not know all the nuances of your infrastructure. Third — readiness for surprises: you need to be prepared for unexpected technical issues that may arise during the connection process. This is not a sign of the provider's incompetence, but a normal working process.

Maturity Test: Are You Really Ready for SOC?

We have outlined the main issues that arise when connecting to SOC. Let's assess your company's readiness for monitoring without marketing exaggerations and vague promises.

Take this short test. It is based on dozens of real connection cases and can save you millions of nerve cells. For each honest "Yes" answer, give yourself 1 point.

People Block

• Do you have at least one dedicated employee who will be the point of contact for the SOC and the coordinator of all actions within the company?

• What will happen if a critical incident occurs on Saturday at 3 AM? Does this employee have officially designated substitutes with the same access and authority as outlined in the regulations?

Processes Block

• Can you right now, within one business day, export a complete and, more importantly, up-to-date list of all your IT assets (servers, workstations, networking equipment), including those located in remote branches and testing environments?

• Are you willing to spend time and resources on collaboratively developing and agreeing on a detailed interaction protocol with the provider?

• Do you understand which specific types of events (from Windows, Linux, networking equipment, remote access systems, proxies, email gateways) are critical for monitoring your key business processes?

• Does your management (at the C-level) understand that in the event of a serious incident they may be called at night to make business decisions (for example, "We are shutting down the main server, stopping production, we won't be able to take orders/start production/process payments. Do you approve?"), and are they prepared for this?

Technology Block

• Do you have engineers who not only know how to work on their hardware but can also configure event collection from the domain controller, Linux machine, or border router based on instructions from the SOC?

• Have you at least roughly assessed how the constant sending of logs from all key systems will affect your network load, and are you sure it won't go down at the most inconvenient moment?

• If you are considering a hybrid model, do you have available server capacity (virtual or physical) and disk space that meets the provider's requirements for deploying SIEM system components?

Your Readiness Level

Now count your points.

0–3 points: Early Access

You are not yet ready to think about a full-fledged commercial SOC. You are the type of customer who is highly likely to waste money and gain a dangerous illusion of security.

Your priority for the next 6–12 months is getting organized. Start with two things. First, conduct a total inventory of assets. Second, hire or grow at least one specialist who will be responsible for information security or turn to a SOC partner to help prioritize.

4–6 points: Beta Version

You are on the right track; you have a foundation. You can start dialogues with providers, but be prepared for the fact that the preparation and connection stage may turn out to be more expensive and complicated than it seems.

Focus on formalizing processes. Start writing internal regulations, define the response team and its authority. Use questionnaires from potential providers as a checklist to identify your weak points.

7–9 points: Release Candidate

Congratulations, you are a mature customer that SOC providers dream of. The implementation process will likely go relatively smoothly and predictably for you.

Choose a partner and remember that your readiness is the starting position for building a truly effective protection system.

Not a Product, but a Partner

Let's return to the top manager from the beginning of the article in six months, after he has followed our recommendations.

He is no longer worried about beautiful dashboards in monthly reports. Instead, he knows the names of three SOC analysts with whom his team has spent many sleepless nights analyzing incidents. He realized that the phrase "very close interaction" in the contract is not just a marketing term, but an accurate description of what is happening. He was looking for a product to solve his problems, when he should have been looking for a partner with whom these problems could be solved collaboratively.

This leads to the main, perhaps the most important thought of this entire article. A commercial SOC is not a magic wand or an outsource for your headache. It is an injection of missing expertise.

You do not relieve yourself of responsibility; you are buying missing players for your team: experienced analysts, response experts, engineers who have seen hundreds of infrastructures and know all the typical mistakes. They do not replace your team; they enhance it. At the same time, with each new incident, your team learns to see real attack chains and mistakes in the current architecture, as well as mastering incident response methods.

As soon as you stop seeing SOC as a product and start seeing it as a partner, everything falls into place. The questions that the customer asks during the presale change. The attitude towards the connection stage changes. The results also change.

As a result, companies stop seeking an illusion of security and begin to build a real, mature security system. And this, you must agree, is a completely different story.