Как построить SOC с нуля в 2026 году: бюджет, штат, инструменты — руководство

Содержание 📋

1. Введение: зачем строить SOC в 2026 году и кому это нужно

2. Что такое SOC: функции, уровни зрелости, место в ИБ-структуре

3. Три модели SOC: on-prem, гибридный, аутсорсинг — как выбрать

4. С чего начать: бизнес-цели, инвентаризация, объект защиты

5. Ролевая модель SOC: кто нужен и сколько стоит

6. Линии SOC: L1, L2, L3 — функции, численность, расписание 24/7

7. Технологический стек: обязательные инструменты SOC 2026

8. SIEM в России 2026: MaxPatrol SIEM, KUMA, R-Vision SIEM — сравнение

9. SOAR, TI, EDR, NTA: расширенный стек и критерии выбора

10. Бюджет SOC: три сценария — от 5 до 150+ млн рублей в год

11. Дорожная карта: запуск SOC за 12 месяцев

12. Типичные ошибки при построении SOC: что ломает всё с самого начала

13. AI в SOC: что уже работает в 2026 году, а что пока маркетинг

14. FAQ: 12 вопросов о построении SOC

15. Чек-лист: готов ли ваш SOC к запуску

16. Заключение и теги

1. Введение: зачем строить SOC в 2026 году и кому это нужно

По данным исследования «Лаборатории Касперского», половина компаний, планирующих создать SOC в 2026–2027 годах, делает это для повышения уровня ИБ и защиты от сложных кибератак, 40% — для соответствия нормативным требованиям, ещё 33% — ради конкурентного преимущества. Согласно данным AM Live за февраль 2026 года, у 70% компаний крупного и среднего бизнеса уже есть собственный SOC или доступ к нему. Но парадокс в том, что почти у половины из них SOC неэффективен — причём проблема не в инструментах, а в фундаменте.

Этот разрыв между наличием SOC и его реальной эффективностью объясняет, зачем нужна эта статья. Многие организации создали SOC «для галочки» — поставили SIEM, посадили одного аналитика, выпустили приказ. Реального мониторинга, процессов и реагирования при этом нет. В 2026 году, когда атаки стали сложнее, а требования регуляторов жёстче, такой подход несостоятелен.

Кому нужен SOC в 2026 году:

Обязательно — объекты критической информационной инфраструктуры (КИИ): компании, подпадающие под 187-ФЗ «О безопасности КИИ», обязаны обеспечить мониторинг и реагирование на инциденты. Банки и финансовые организации под регулированием ЦБ. Госструктуры и организации, взаимодействующие с ГосСОПКА.

Практически необходимо — организации с распределённой инфраструктурой, штатом от 500+ пользователей и критически важными бизнес-процессами. Компании, пережившие инцидент или атаку и понимающие реальную цену простоя.

Опционально, но разумно — компании с оборотом от 1 млрд рублей в год, где потенциальный ущерб от кибератаки сопоставим или превышает стоимость SOC.

> *Статья носит образовательный и практический характер. Данные о зарплатах и бюджетах приведены для российского рынка по состоянию на 2025–2026 год. Конкретные цифры зависят от региона, отрасли и специфики организации.*

2. Что такое SOC: функции, уровни зрелости, место в ИБ-структуре

Определение и ключевые функции

Security Operations Center (SOC, Центр мониторинга и реагирования на инциденты информационной безопасности) — это подразделение или сервис, обеспечивающий непрерывный мониторинг ИТ-инфраструктуры с целью обнаружения, анализа и реагирования на инциденты ИБ.

Базовые функции SOC:

Мониторинг и обнаружение (Detection) — сбор событий из всех источников, корреляция, выявление аномалий и потенциальных инцидентов в режиме реального времени.

Расследование и анализ (Investigation) — детальный разбор алертов, определение масштаба инцидента, выявление цепочки атаки, сбор доказательной базы.

Реагирование (Response) — сдерживание угрозы, изоляция заражённых узлов, устранение последствий, восстановление нормальной работы.

Threat Intelligence (TI) — сбор и применение данных об актуальных угрозах, индикаторах компрометации (IoC), тактиках и техниках атакующих (TTPs по MITRE ATT&CK).

Управление уязвимостями — в современном SOC это ключевая функция: понимание уязвимостей инфраструктуры позволяет приоритизировать мониторинг наиболее критичных объектов.

По мнению Андрея Шаляпина (BI.ZONE TDR), высказанному на AM Live в феврале 2026 года, современный SOC — это уже не только мониторинг и реагирование, а центр операционной безопасности компании в целом. В SOC-зрелых организациях туда включаются управление безопасными конфигурациями, задачи Red Team и Threat Hunting.

Уровни зрелости SOC

Модель зрелости SOC помогает определить текущее состояние и горизонт развития.

Уровень 1 — начальный: реактивное реагирование на явные инциденты, ручная работа с логами, отсутствие формализованных процессов. Характерен для организаций, где «SOC» — это один администратор безопасности с SIEM.

Уровень 2 — развивающийся: внедрены SIEM и базовые правила корреляции, есть команда первой линии, формализованы плейбуки реагирования, но охват неполный и много ложноположительных срабатываний.

Уровень 3 — определённый: чётко выстроены процессы по всем фазам (обнаружение, расследование, реагирование), интегрирован Threat Intelligence, работает Asset Management, измеряются KPI. Реальное покрытие 70–80% инфраструктуры.

Уровень 4 — управляемый: Threat Hunting как регулярный процесс, SOAR-автоматизация рутинных задач, Red Team как внутренняя функция, интеграция с бизнес-процессами, SLA по времени реагирования.

Уровень 5 — оптимизирующий: непрерывное совершенствование на основе метрик, предиктивные возможности, интеграция ML для обнаружения аномалий, формирование экспертизы внутри компании.

3. Три модели SOC: on-prem, гибридный, аутсорсинг — как выбрать

Выбор модели — стратегическое решение, которое определяет всё остальное: бюджет, штат, инструменты и временны́е рамки.

Модель 1: On-Premise SOC (внутренний)

Полностью собственный SOC: ваша команда, ваши инструменты, ваши помещения. Все данные остаются внутри организации.

Преимущества: максимальный контроль над данными и процессами; глубокое понимание специфики инфраструктуры; возможность кастомизации под конкретные угрозы; соответствие требованиям, запрещающим передачу данных третьим сторонам (КИИ, гостайна).

Недостатки: высокие капитальные и операционные затраты; долгий срок выхода на режим 24/7 (12–18 месяцев); кадровая проблема — найти и удержать квалифицированную команду крайне сложно; зависимость от ключевых сотрудников.

Кому подходит: крупные организации (500+ сотрудников ИТ/ИБ), объекты 1-й и 2-й категории КИИ, организации с требованиями по суверенитету данных.

Ориентировочный бюджет: от 30–50 млн рублей на первоначальное развёртывание, 20–40 млн рублей в год на операционные затраты (без учёта ФОТ команды).

Модель 2: Гибридный SOC

Разделение функций: часть — внутри (Tier 2/3, специфические задачи, контроль данных), часть — на аутсорсинг (Tier 1, 24/7 мониторинг, стандартные инциденты).

Преимущества: баланс между контролем и стоимостью; гибкость масштабирования; экономия на найме дорогостоящих специалистов первой линии; быстрее выйти на 24/7.

Недостатки: сложнее управлять двумя командами; возможны конфликты зон ответственности; зависимость от провайдера по части функций.

Кому подходит: компании среднего и крупного бизнеса (200–1000 сотрудников), у которых есть желание строить собственную экспертизу, но нет ресурсов для мгновенного полного SOC.

Ориентировочный бюджет: 10–25 млн рублей в год (включая аутсорсинг 24/7 и внутренняя команда L2/L3).

Модель 3: Аутсорсинг (MSSP/MDR)

Передача функций SOC внешнему провайдеру безопасности (Managed Security Service Provider или Managed Detection and Response). В России этот рынок представлен BI.ZONE TDR, Solar JSOC (ГК «Солар»), Kaspersky MDR, Softline SOC, Innostage SOC и другими.

Преимущества: быстрый старт (1–3 месяца вместо 12–18); предсказуемые операционные затраты; нет проблемы кадрового голода; доступ к экспертизе уровня L3 без найма.

Недостатки: данные покидают периметр организации; меньший контроль над процессами; ниже кастомизация под специфику конкретного бизнеса; зависимость от провайдера; не подходит для объектов КИИ с ограничениями по передаче данных.

Кому подходит: компании малого и среднего бизнеса (до 500 сотрудников); организации без требований по суверенитету данных; компании, которым нужно быстро закрыть регуляторные требования.

Ориентировочный бюджет: 3–15 млн рублей в год в зависимости от объёма инфраструктуры и уровня сервиса.

Матрица выбора модели

4. С чего начать: бизнес-цели, инвентаризация, объект защиты

По оценке Владимира Дмитриева (Positive Technologies), озвученной на AM Live 2026, большинство SOC-проектов начинаются не с того конца — сначала выбирают SIEM, потом думают, что с ним делать. Правильный порядок обратный.

Шаг 1: Определить бизнес-цели и «недопустимые события»

Начинать нужно с вопроса: что именно должен предотвращать SOC? Для большинства организаций ответ звучит так: остановить атаку до того, как пострадает бизнес. Конкретизация этого ответа приводит к понятию «недопустимые события» — Positive Technologies активно продвигает этот подход.

Примеры недопустимых событий: шифрование критически важных данных ransomware, несанкционированный перевод денежных средств, утечка персональных данных клиентов, нарушение доступности производственных систем.

Именно от этих событий нужно идти назад: какие векторы атаки могут к ним привести? Какие системы на этом пути? Какие источники событий нужно мониторить в первую очередь?

Шаг 2: Инвентаризация инфраструктуры (Asset Management)

Владимир Дмитриев в AM Live назвал Asset Management самым недооценённым продуктом в SOC: «Все говорят о его важности, но мало кто действительно использует». Без понимания того, что именно защищаешь, невозможно выстроить осмысленный мониторинг.

Инвентаризация должна охватить: все конечные устройства (рабочие станции, серверы, мобильные устройства), сетевое оборудование, периметровые средства защиты, облачные ресурсы, критически важные приложения и их зависимости.

Результат — актуальная CMDB (Configuration Management Database), которая обновляется автоматически. Без неё правила корреляции SIEM будут срабатывать вхолостую или пропускать критические события.

Шаг 3: Определить модель угроз и приоритетные источники

Не пытаться подключить всё сразу. Евгений Гуляев (R-Vision) на AM Live рекомендует начать с 5–7 наиболее критичных источников событий и 10–15 ключевых сценариев обнаружения. Это даст реальный результат быстрее, чем попытка охватить всю инфраструктуру сразу.

Типовые приоритетные источники первой очереди: Active Directory / LDAP (события входа, изменения привилегий), почтовый шлюз (фишинг, BEC), периметровый межсетевой экран и IDS/IPS, конечные устройства с EDR, критические бизнес-приложения (ERP, CRM, банковские системы).

Шаг 4: Договориться о процессах до выбора технологий

Евгений Гуляев особо подчёркивает: подготовительную работу, которую можно провести бесплатно, часто игнорируют. До покупки первой лицензии нужно: описать и согласовать процессы реагирования, определить зоны ответственности ИТ и ИБ (кто что делает при инциденте), написать хотя бы базовые плейбуки для топ-5 сценариев.

5. Ролевая модель SOC: кто нужен и сколько стоит

Ключевые роли в SOC

Руководитель SOC (SOC Manager / Head of SOC)
Отвечает за стратегию, KPI, взаимодействие с руководством, управление командой и бюджетом. Должен совмещать экспертизу в ИБ с управленческими компетенциями.
Зарплата в Москве: 300 000 — 500 000 руб./мес.
Критически важная компетенция: понимание бизнес-контекста, умение «переводить» технические риски в язык бизнеса.

Архитектор безопасности (Security Architect)
Проектирует архитектуру SOC, выбирает и интегрирует инструменты, разрабатывает логику корреляции SIEM. Нередко совмещает роль ведущего инженера на этапе построения.
Зарплата в Москве: 250 000 — 400 000 руб./мес.

Инженер SOC (SOC Engineer)
Настраивает и обслуживает технологический стек: SIEM, SOAR, EDR, NTA и другие решения. Пишет правила корреляции, парсеры источников, плейбуки автоматизации. Обновляет и масштабирует инфраструктуру.
Зарплата в Москве: 180 000 — 320 000 руб./мес.
Дополнительные надбавки: знание MaxPatrol SIEM или KUMA даёт +15–25 тыс. руб. к базовой ставке.

Аналитик L1 (SOC Analyst Tier 1)
Первая линия обороны: разбор алертов из SIEM, первичная триаж (ложноположительное / реальное), эскалация на L2, документирование. Работает по плейбукам, минимальная самостоятельность. Работает в режиме 24/7.
Зарплата в Москве: 90 000 — 150 000 руб./мес. (ночные смены — доп. коэффициент).

Аналитик L2 (SOC Analyst Tier 2)
Углублённый анализ инцидентов, эскалированных с L1. Самостоятельно проводит расследование, определяет масштаб, координирует реагирование. Пишет отчёты по инцидентам.
Зарплата в Москве: 150 000 — 250 000 руб./мес.

Аналитик L3 / Threat Hunter / Incident Response
Работает со сложными инцидентами и APT. Проводит Threat Hunting (поиск угроз, не обнаруженных автоматикой), разрабатывает новые сценарии обнаружения, анализирует вредоносное ПО. Участвует в Red Team / Purple Team активностях.
Зарплата в Москве: 250 000 — 450 000 руб./мес. Наиболее дефицитная роль на рынке.

Threat Intelligence Analyst
Собирает и анализирует данные об угрозах, актуальных для организации. Переводит индикаторы компрометации и TTP-фреймворки (MITRE ATT&CK) в конкретные правила обнаружения. Взаимодействует с внешними источниками TI.
Зарплата в Москве: 180 000 — 320 000 руб./мес.

Compliance/GRC специалист (опционально)
Обеспечивает соответствие требованиям регуляторов (ФСТЭК, ЦБ, 187-ФЗ, 152-ФЗ), ведёт документацию, готовит отчётность для ГосСОПКА/НКЦКИ.

Численность: минимальная команда для 24/7

Для обеспечения режима 24/7 без единой точки отказа необходимо как минимум 4–5 аналитиков L1 (с учётом отпусков, больничных, смен). Типовая схема для on-premise SOC малого/среднего масштаба:


Годовой ФОТ: около 26,4 млн рублей. Плюс страховые взносы (30%) — итого около 34 млн рублей в год только на персонал. Именно поэтому гибридная модель или аутсорсинг часто экономически обоснованнее для компаний, где нет жёстких требований по суверенитету данных.

6. Линии SOC: L1, L2, L3 — функции, численность, расписание 24/7

Концепция многолинейной обороны

Трёхуровневая модель SOC — общепринятый стандарт, хотя конкретные названия и распределение задач варьируются между организациями.

Tier 1 / L1 — Мониторинг и первичный триаж
Задача: обработать максимальный поток алертов, отсеять ложноположительные срабатывания, эскалировать реальные инциденты. Работает строго по плейбукам. Время реагирования — минуты.
Ключевые инструменты: SIEM-интерфейс, базовые TI-фиды, система тикетинга.
Принципиальное требование: скорость и дисциплина, а не глубокая экспертиза.

Tier 2 / L2 — Расследование и реагирование
Задача: детальный анализ инцидентов от L1, построение цепочки атаки (kill chain), оценка масштаба, координация реагирования. Имеет право принимать самостоятельные решения.
Ключевые инструменты: EDR-консоль, SOAR для автоматизации реагирования, форензик-инструменты, Threat Intelligence платформа.
Принципиальное требование: аналитическое мышление, понимание тактик атакующих.

Tier 3 / L3 — Экспертный анализ и Threat Hunting
Задача: работа с APT и сложными инцидентами, проактивный поиск угроз, разработка новых сценариев обнаружения, анализ вредоносного ПО. L3 нередко совмещает функции Malware Analyst и Threat Hunter.
Ключевые инструменты: песочница (sandbox), инструменты реверс-инжиниринга, расширенный TI-доступ, собственные скрипты и автоматизация.
Принципиальное требование: глубокая техническая экспертиза, понимание MITRE ATT&CK на уровне разработки детектирующей логики.

Расписание 24/7 и модель Эрланга

Для обеспечения круглосуточного покрытия применяется модель Эрланга (Erlang C) — математический аппарат для расчёта необходимого количества операторов при заданном потоке нагрузки. В Positive Technologies в учебном практикуме по построению SOC 2026 эту модель упоминают как базовый инструмент для расчёта численности L1-аналитиков.

Практическая формула для оценки: при работе в 3 смены по 8 часов, с учётом отпусков (28 рабочих дней), больничных (~5–7 дней в год) и обучения — для покрытия одной рабочей позиции 24/7 нужно 4,5–5 человек. Это означает: для L1 с одним дежурным аналитиком одновременно нужно 5 человек в штате.

7. Технологический стек: обязательные инструменты SOC 2026

По данным AM Live за февраль 2026 года, крупные предприятия внедряют в SOC в среднем 5–6 решений, небольшие — 4. По мнению экспертов, обсуждавших этот вопрос на сессии, набор обязательных инструментов и «продвинутых» нужно разграничивать.

Обязательный минимум (must have)

1. SIEM (Security Information and Event Management)
Ядро SOC — система сбора, нормализации, корреляции и хранения событий безопасности. Без SIEM SOC невозможен в принципе. Подробный разбор российских решений в следующем разделе.

2. Asset Management / CMDB
Реестр активов с актуальными данными о составе, конфигурации и критичности элементов инфраструктуры. По словам Владимира Дмитриева (PT), именно Asset Management остаётся самым недооценённым, но обязательным элементом SOC. Без него корреляционные правила SIEM теряют половину ценности.

3. EDR (Endpoint Detection and Response)
Агент на конечных устройствах, обеспечивающий глубокую телеметрию (процессы, сетевые соединения, файловые операции, реестр) и возможность удалённого реагирования (изоляция хоста, сбор артефактов). В России: Kaspersky EDR, PT MaxPatrol EDR, Security Vision EDR, CrowdStrike (ограниченно доступен).

4. Система управления уязвимостями (VM)
Регулярное сканирование и приоритизация уязвимостей по степени риска. Позволяет SOC-аналитикам понимать, насколько уязвима атакуемая система, и корректно приоритизировать инциденты. В России: MaxPatrol VM (PT), Kaspersky Security Assessment, ScanFactory.

5. Firewall / NGFW + IDS/IPS
Периметровые средства защиты как обязательный источник событий для SIEM. В российских реалиях 2026 года: UserGate NGFW, Код Безопасности «Континент», «ИнфоТеКС» ViPNet, «Гарда» Enterprise Firewall.

6. Система тикетинга / IRP (Incident Response Platform)
Управление жизненным циклом инцидентов: создание тикета, назначение ответственных, трекинг статусов, история действий. Может быть частью SOAR или отдельной системой.

Advanced-стек (следующий этап зрелости)

SOAR (Security Orchestration, Automation and Response) — автоматизация типовых сценариев реагирования. Подробнее в разделе 9.

NTA / NDR (Network Traffic Analysis / Network Detection and Response) — анализ сетевого трафика для выявления аномалий. PT NAD — один из лидирующих российских продуктов.

Threat Intelligence Platform — централизованная работа с данными об угрозах, IoC, TTP. R-Vision TIP, PT Threat Intelligence.

UEBA (User and Entity Behavior Analytics) — поведенческий анализ пользователей и сущностей, выявление аномалий методами ML.

Deception / TDP (Threat Deception Platform) — ложная инфраструктура для раннего выявления атакующих. R-Vision TDP, PT Sandbox.

8. SIEM в России 2026: MaxPatrol SIEM, KUMA, R-Vision SIEM — сравнение

После ухода западных вендоров (Splunk, IBM QRadar, Microsoft Sentinel) с российского рынка в 2022 году отечественные SIEM-системы значительно выросли как по функциональности, так и по зрелости.

MaxPatrol SIEM (Positive Technologies)

Де-факто лидер российского рынка SIEM по числу внедрений: более 600 компаний из промышленности, транспорта, финансов и государственных структур.

Ключевые характеристики: производительность свыше 540 тыс. событий в секунду на одном ядре, поддержка более 310 источников событий, более 8 000 правил нормализации «из коробки». Встроенная CMDB с контролем изменения свойств активов — то, что Дмитриев называет «недооценённым инструментом». Функционал построения карты сети для оценки вероятности успешной атаки. Фирменный SDK для создания и тестирования правил корреляции. Регулярно обновляемые пакеты экспертизы от PT Expert Security Center. Интеграция с ГосСОПКА.

Модель лицензирования: по количеству активов и потоку EPS (Events Per Second). Входит в реестр отечественного ПО.

Когда выбирать MaxPatrol SIEM: организации с требованиями ФСТЭК, уже использующие экосистему Positive Technologies (MaxPatrol VM, PT NAD, MaxPatrol EDR), компании КИИ.

KUMA (Kaspersky Unified Monitoring and Analysis Platform, «Лаборатория Касперского»)

Хорошо известный рынку продукт с богатой историей интеграций с продуктами Kaspersky.

Ключевые характеристики: производительность более 500 тыс. событий в секунду, бесшовная интеграция с линейкой Kaspersky (Kaspersky EDR, Kaspersky TI, Kaspersky Anti APT), встроенные сценарии автоматического реагирования, интеграция с ГосСОПКА через встроенный модуль. Сертификат ФСТЭК России. Продаётся по подписочной модели.

Когда выбирать KUMA: организации, уже развернувшие экосистему Kaspersky, банки и финансовые организации, компании под регуляторными требованиями с необходимостью уведомления НКЦКИ.

R-Vision SIEM

Самый молодой из тройки лидеров — вышел в 2023 году, но уже показывает зрелость за счёт опыта R-Vision в смежных продуктах (SOAR, TIP, SGRC). Является частью экосистемы R-Vision EVO.

Ключевые характеристики: плотная интеграция с R-Vision TIP, SOAR, VM, UEBA, TDP — единая консоль для SOC-операций. При его создании разработчики учитывали трудности пользователей с другими SIEM-системами.

Когда выбирать R-Vision SIEM: организации, строящие SOC на базе экосистемы R-Vision или планирующие последовательное расширение стека через продукты одного вендора.

Другие российские SIEM

RuSIEM — зрелый продукт, активно растущий в корпоративном сегменте с 2021 года. Ankey SIEM NG (Газинформсервис + Positive Technologies) — разрабатывается на базе ядра MaxPatrol SIEM, популярен в государственном и промышленном сегментах.

Сравнительная таблица

9. SOAR, TI, EDR, NTA: расширенный стек и критерии выбора

SOAR: когда нужен и когда не нужен

SOAR (Security Orchestration, Automation and Response) — система автоматизации рутинных операций SOC: создание тикетов, обогащение алертов из TI, изоляция хостов, отправка уведомлений, запуск скриптов реагирования.

Ключевое предостережение: SOAR имеет смысл только при достаточном уровне зрелости SOC. Как отмечают обозреватели Anti-Malware.ru, SOAR требует предварительной подготовки по систематизации и формализации процессов. Если процессы не описаны, автоматизировать хаос — значит получить быстрый хаос.

Российские решения: R-Vision SOAR, Security Vision IRP/SOAR, Innostage SOC. Ранее лидировали западные Palo Alto Cortex XSOAR и Splunk SOAR — сейчас практически недоступны в России.

Когда SOAR оправдан: более 100 алертов в день требует ручной обработки L1, есть формализованные плейбуки хотя бы для 5–10 типовых инцидентов, есть инженер, способный поддерживать плейбуки.

NTA/NDR: анализ сетевого трафика

PT NAD (Network Attack Discovery, Positive Technologies) — один из ведущих российских NDR-решений. Анализирует сетевой трафик, выявляет аномалии, горизонтальное перемещение, эксфильтрацию данных. Особенно ценен для выявления угроз, не обнаруженных EDR (бесфайловые атаки, атаки через легитимные инструменты).

Другие российские решения: «Гарда» NDR, UserGate Network Security, Kaspersky Anti APT (включает сетевой сенсор).

Threat Intelligence (TI)

TI-платформа позволяет централизованно управлять индикаторами компрометации (IoC), автоматически обогащать алерты SIEM и SOAR контекстом об угрозах, отслеживать активность APT-групп, актуальных для вашей отрасли.

Российские решения: PT Threat Intelligence (Positive Technologies), R-Vision TIP, Kaspersky TI (в составе KL экосистемы). Важно: многие организации начинают с бесплатных или низкобюджетных TI-фидов (MISP, OpenTI, ФинЦЕРТ ЦБ для банков) и только потом переходят к коммерческим платформам.

10. Бюджет SOC: три сценария — от 5 до 150+ млн рублей в год

По данным AM Live 2026 года, 47% организаций называют недостаток бюджета главным барьером для эффективного SOC. Ниже — реалистичные сценарии для российского рынка.

Сценарий А: Минимальный SOC / «SOC Lite» (5–12 млн руб./год)

Подходит для: небольших компаний (до 300 сотрудников), организаций с ограниченным бюджетом, первого этапа построения.

Модель: гибридная или полный аутсорсинг. Инструменты: подписка на MSSP/MDR (Solar JSOC стартует от 3–5 млн руб./год в зависимости от объёма, BI.ZONE TDR — аналогично). Внутри: 1–2 ИБ-специалиста для координации с провайдером.

Что получите: мониторинг 24/7 по типовым сценариям, реагирование на инциденты L1/L2, базовая TI, ежемесячные отчёты. Чего не получите: глубокой кастомизации под специфику инфраструктуры, внутренней экспертизы, полного контроля над данными.

Сценарий Б: SOC среднего масштаба (20–50 млн руб./год)

Подходит для: компаний 300–1000 сотрудников, организаций с умеренными требованиями по суверенитету данных, первых двух лет on-premise или гибридного SOC.

Примерная структура затрат:

Сценарий В: Полноценный enterprise SOC (80–150+ млн руб./год)

Подходит для: крупных организаций (1000+ сотрудников), объектов КИИ 1–2 категории, финансовых институтов, холдингов с несколькими дочерними компаниями.

Ключевые отличия от Сценария Б: полноценная команда 15–20+ человек с L3, Threat Intelligence аналитиками и выделенным архитектором. Полный технологический стек: SIEM + SOAR + TI + EDR + NTA + UEBA + Deception + Sandbox + Vulnerability Management. Собственный аппаратный комплекс с резервированием. Соответствие требованиям ФСТЭК, регулярные аудиты и пентесты.

Важные нюансы бюджетирования

Не занижать стоимость интеграции: развёртывание SIEM и подключение 50+ источников событий требует 2–6 месяцев работы инженеров — это либо внутренние человеко-часы, либо дорогостоящий консалтинг вендора.

Закладывать стоимость сопровождения: лицензии — это только начало. Обновление правил корреляции, обучение команды, техническая поддержка вендора добавляют 20–30% к базовой стоимости лицензий.

Учитывать инфляцию зарплат: зарплаты в ИБ в 2025 году выросли на 20–35% год к году. Дефицит специалистов структурный — ситуация не изменится в обозримой перспективе.

11. Дорожная карта: запуск SOC за 12 месяцев

Месяцы 1–2: Фундамент

Провести инвентаризацию инфраструктуры и сформировать CMDB. Определить «недопустимые события» и ключевые бизнес-риски. Описать модель угроз и составить карту векторов атак. Договориться о распределении ролей ИТ и ИБ при инцидентах. Написать базовые плейбуки для 5 приоритетных сценариев. Выбрать и согласовать модель SOC (on-prem/гибрид/аутсорсинг). Начать подбор команды ключевых ролей.

Месяцы 3–4: Технологический старт

Развернуть SIEM (пилот на ограниченном наборе источников). Подключить первый приоритетный набор источников: AD, почтовый шлюз, периметровый FW. Развернуть EDR на критичных узлах. Настроить 10–15 базовых правил корреляции под выбранные сценарии. Запустить систему тикетинга/IRP. Провести первые тренировки команды по плейбукам.

Месяцы 5–6: Первый боевой режим

Выйти на L1 в режиме 12/7 (расширить до 24/7 по мере набора команды). Подключить TI-фиды и обогатить алерты контекстом. Провести первый внутренний Red Team-сценарий для проверки покрытия. Собрать и проанализировать статистику за первые 90 дней: сколько алертов, какой процент ложноположительных, среднее время реагирования.

Месяцы 7–9: Оптимизация

Снизить процент ложноположительных срабатываний — настройка вайтлистов, уточнение правил. Расширить покрытие: добавить следующий приоритетный набор источников. Внедрить Asset Management как непрерывный процесс (автоматическое обновление CMDB). Рассмотреть пилот SOAR для топ-3 автоматизируемых сценариев. Запустить регулярную отчётность по KPI для руководства.

Месяцы 10–12: Выход на целевой режим

Выйти на 24/7 по всем линиям (или задокументировать риски нижних уровней покрытия). Провести полный аудит правил корреляции — убрать неэффективные, добавить новые под актуальные угрозы. Запустить первый цикл Threat Hunting. Подготовить итоговый отчёт о готовности SOC и план развития на следующий год. Для КИИ: пройти аттестацию и наладить взаимодействие с ГосСОПКА.

12. Типичные ошибки при построении SOC: что ломает всё с самого начала

По данным AM Live 2026, 47% SOC-команд называют недостаток бюджета ключевым барьером эффективности. 43% — недостаточное знание защищаемых активов. 40% — отсутствие автоматизации. 30% — непонимание бизнес-контекста.

Ниже — систематизированный список ошибок, которые встречают на практике.

Ошибка 1: Начинать с покупки SIEM, а не с целеполагания
Развернуть дорогостоящую систему и потом думать, что в неё подключать — наиболее распространённый сценарий неудачи. SIEM без продуманной логики обнаружения становится дорогим хранилищем логов. Правильный порядок: цели → угрозы → источники → правила → инструменты.

Ошибка 2: Игнорировать Asset Management
Вторая по частоте ошибка. Без актуального реестра активов невозможно правильно расставить приоритеты мониторинга и корректно трактовать алерты. «Неизвестный хост пытается подключиться к SQL-серверу» — это критический инцидент или штатный бэкап? Без Asset Management ответ неизвестен.

Ошибка 3: Занизить численность команды
Запустить SOC с двумя аналитиками «чтобы попробовать» — значит моментально получить выгорание и текучку. 24/7 минимально требует 4–5 человек на первой линии. Ошибка в расчётах численности — одна из самых дорогостоящих, потому что кадровый дефицит в ИБ делает замену специалистов очень долгой и дорогой.

Ошибка 4: Не договориться с ИТ «на берегу»
SOC реагирует на инциденты, но исполняет containment (изоляцию) и remediation (исправление) чаще всего ИТ-подразделение. Если зоны ответственности не разграничены — при первом реальном инциденте начнутся конфликты. Нужно заранее: прописать в регламентах, кто принимает решение об изоляции хоста, кто имеет право отключить сегмент сети.

Ошибка 5: Нет плейбуков — есть только ручное разбирательство
Без формализованных плейбуков каждый инцидент — импровизация. Это замедляет реагирование и создаёт разнобой в качестве обработки в зависимости от того, кто дежурит. Минимальный стартовый набор: фишинг, компрометация учётной записи, ransomware, DDoS, несанкционированный доступ к критичной системе.

Ошибка 6: Игнорировать «alert fatigue» (усталость от алертов)
Система, генерирующая 5 000 алертов в день, из которых 4 800 — ложноположительные, парализует команду. Необходимо с первого дня настраивать вайтлисты, приоритизировать правила, отключать неработающие корреляции. По данным AM Live 2026, только 17% SOC-команд называют alert fatigue основной проблемой — что означает либо хорошо настроенные системы, либо отсутствие честной самооценки.

Ошибка 7: Нет KPI и метрик — нет управления
Если нельзя измерить — нельзя улучшить. Базовый набор KPI для SOC: MTTD (Mean Time to Detect — среднее время обнаружения), MTTR (Mean Time to Respond — среднее время реагирования), процент ложноположительных срабатываний, покрытие инфраструктуры (% активов под мониторингом), количество инцидентов по категориям.

13. AI в SOC: что уже работает в 2026 году, а что пока маркетинг

ИИ в SOC — тема, которая активно обсуждалась на AM Live в феврале 2026 года. По общему мнению экспертов, ИИ в SOC существенно изменил работу, но не заменил аналитиков.

Что реально работает

ML для обнаружения аномалий (UEBA): поведенческий анализ пользователей и сущностей уже в производственной эксплуатации у зрелых SOC. MaxPatrol SIEM использует ML для выявления аномалий и предсказания будущих инцидентов. Реальная ценность — снижение числа пропущенных инцидентов за счёт обнаружения отклонений от базовой линии.

Автоматическая обработка и приоритизация алертов: ML-модели, ранжирующие алерты по вероятности реального инцидента, уже снижают нагрузку на L1 на 40–60% в зрелых реализациях. По данным ISC2 (2024), только 15% рутинных задач L1-аналитиков поддаются полной автоматизации.

Генеративный ИИ как ассистент аналитика: LLM-ассистенты для объяснения кода вредоносных программ, составления отчётов по инцидентам, генерации гипотез Threat Hunting — уже в пилотном использовании у ведущих SOC-провайдеров. Python + ML basics даёт специалисту +40% к зарплате — сигнал рынка о реальной востребованности.

Что пока преувеличено

«Полная замена L1-аналитиков»: Gartner обещает полную автоматизацию SOC к 2030 году. Реальность, по оценке экспертов на AM Live, другая: ИИ снижает нагрузку на L1, но не заменяет человека в контуре принятия решений. Особенно в нестандартных ситуациях, которых в SOC большинство.

«AI нашёл угрозу»: многие вендоры используют слово «AI» для описания правил корреляции, написанных инженерами. Реальный ML в SIEM — это конкретные функциональности (поведенческий анализ, детектирование аномалий), а не маркетинговый ярлык на продукте.

14. FAQ: 12 вопросов о построении SOC

Q 01 Нужен ли SOC компании с 50 сотрудниками?

A Полноценный внутренний SOC — избыточно и финансово нецелесообразно. Но базовые функции SOC нужны всем: мониторинг критичных систем, плейбуки реагирования, хотя бы один человек, ответственный за ИБ. Для таких компаний оптимальный путь — аутсорсинг к MSSP с минимальным пакетом или использование MDR-решений, которые сейчас предлагают все крупные вендоры (Kaspersky MDR, Solar MDR).

Q 02 Сколько времени занимает построение SOC с нуля?

A Выйти на базовый режим работы (первые источники подключены, команда работает, плейбуки написаны) — 3–6 месяцев. Выйти на режим 24/7 с покрытием большей части инфраструктуры — 12–18 месяцев. Достичь уровня зрелости 3 (определённые процессы, Threat Hunting, измеримые KPI) — 2–3 года. Эти сроки реалистичны при правильном старте. Ошибки на фундаментальном этапе удваивают сроки.

Q 03 SIEM обязателен для SOC?

A Да, SIEM — это технологическое ядро SOC. Без централизованного сбора и корреляции событий невозможен систематический мониторинг. Единственное исключение — полный аутсорсинг к провайдеру, у которого SIEM уже развёрнут на его стороне. Для объектов КИИ и организаций с требованиями по суверенитету данных — собственный SIEM обязателен.

Q 04 Что лучше: MaxPatrol SIEM или KUMA?

A Оба продукта зрелые и хорошо закрывают большинство задач. MaxPatrol SIEM имеет преимущество встроенной CMDB и более широкого набора пакетов экспертизы, что особенно важно при построении с нуля. KUMA сильнее для организаций, уже построенных на экосистеме Kaspersky. Практический совет: запустите пилот обоих под конкретные сценарии и критичные источники вашей инфраструктуры — разница видна только на реальных данных.

Q 05 Можно ли использовать OpenSource SIEM (Elasticsearch/OpenSearch + Wazuh)?

A Да, для небольших организаций и как временное решение. Wazuh на базе OpenSearch/Elasticsearch — зрелая открытая платформа с активным сообществом. Экономия значительная. Но: требует квалифицированных инженеров для настройки и сопровождения, нет технической поддержки вендора в боевом режиме, нет сертификации ФСТЭК (критично для КИИ), нет готовых пакетов экспертизы под российские угрозы.

Q 06 Насколько важна интеграция с ГосСОПКА?

A Для объектов КИИ — обязательна по 187-ФЗ. Для остальных — крайне желательна: взаимодействие с НКЦКИ даёт доступ к актуальным IOC, оповещениям об актуальных угрозах и нормативным рекомендациям. Как KUMA, так и MaxPatrol SIEM имеют встроенные модули для интеграции с ГосСОПКА/НКЦКИ.

Q 07 Где найти аналитиков SOC в 2026 году?

A Рынок очень конкурентный: дефицит специалистов оценивается в соотношении 5 вакансий к 1 резюме. Эффективные каналы: hh.ru с активным headhunting, профильные сообщества (Telegram-каналы SOC/ИБ, DEFCON Russia, ZeroNights), партнёрства с профильными кафедрами (МГТУ МИРЭА, НИУ ВШЭ, ИТМО), выращивание Junior из системных администраторов с ИБ-интересом. Главное: предлагайте не только зарплату, но и профессиональный рост — аналитики уходят туда, где учатся.

Q 08 Как доказать руководству необходимость SOC?

A Лучший аргумент — конкретный расчёт потенциального ущерба от инцидента в сравнении со стоимостью SOC. Используйте реальные кейсы: средний ущерб от ransomware для российской компании среднего бизнеса — 15–50 млн рублей (простой, восстановление, репутационный ущерб). Стоимость SOC-lite — 5–12 млн рублей в год. ROI считается просто. Дополнительный аргумент для регулируемых отраслей: санкции за нарушение 187-ФЗ и 152-ФЗ.

Q 09 Что такое Threat Hunting и когда его запускать?

A Threat Hunting — проактивный поиск угроз, которые не обнаружены автоматическими средствами. В отличие от реактивного мониторинга, Threat Hunter сам формирует гипотезы о возможных атаках и проверяет их по данным в SIEM/EDR. Запускать имеет смысл при достижении уровня зрелости SOC 3: когда базовый мониторинг отлажен, команда свободна от постоянного тушения пожаров, и есть инструменты для работы с историческими данными.

Q 10 Чем SOAR отличается от IRP?

A IRP (Incident Response Platform) — система управления жизненным циклом инцидентов: тикетинг, трекинг статусов, история действий, документирование. Это «журнал» и «менеджер задач» SOC. SOAR (Security Orchestration, Automation and Response) — более широкая платформа, включающая автоматизацию реагирования через плейбуки, оркестрацию между системами (SIEM → EDR → FW → уведомление) и функции IRP. Многие современные SOAR включают IRP как функциональный блок.

Q 11 Нужен ли отдельный физический офис для SOC?

A Не обязательно, но желательно для полноценного on-prem SOC с режимом 24/7. Отдельное помещение обеспечивает физическую безопасность, снижает помехи для ночных смен, позволяет использовать визуализационные экраны (видеостену). Для гибридного или виртуального SOC физическое пространство опционально — большинство крупных MSSP работают в распределённом режиме.

Q 12 Как оценить эффективность уже работающего SOC?

A Базовые KPI для самооценки: MTTD — среднее время с момента события до его обнаружения SOC (цель: до 1 часа для критических инцидентов). MTTR — среднее время от обнаружения до containment (цель: до 4 часов). False Positive Rate — процент ложноположительных алертов (цель: ниже 20%). Coverage — процент активов под мониторингом (цель: 80%+ критичных систем). Дополнительно: регулярно проводить Purple Team-учения, где Red Team тестирует обнаружение, а Blue Team (SOC) отрабатывает реагирование.

15. Чек-лист: готов ли ваш SOC к запуску

Блок A: Фундамент (стратегия и процессы)

- [ ] Определены «недопустимые события» и критичные бизнес-активы, которые они защищают
- [ ] Проведена инвентаризация инфраструктуры, существует актуальная CMDB
- [ ] Сформирована модель угроз и определены приоритетные векторы атак
- [ ] Написаны плейбуки минимум для 5 типовых сценариев (фишинг, компрометация учётной записи, ransomware, DDoS, несанкционированный доступ)
- [ ] Разграничены зоны ответственности ИТ и ИБ при инцидентах

Блок B: Команда

- [ ] Назначен руководитель SOC с чёткими полномочиями
- [ ] Укомплектован штат первой линии из расчёта 4–5 аналитиков L1 для 24/7
- [ ] Определены L2/L3 (собственные или через партнёра)
- [ ] Команда прошла обучение работе с выбранным SIEM
- [ ] Проведены тренировочные «учения» по плейбукам до старта боевого режима

Блок C: Технологии

- [ ] Развёрнут SIEM, подключены первые приоритетные источники (AD, FW, почтовый шлюз)
- [ ] Настроены базовые правила корреляции под выбранные сценарии
- [ ] EDR развёрнут на критичных узлах
- [ ] Подключены TI-фиды (хотя бы бесплатные: MISP, ФинЦЕРТ)
- [ ] Работает система тикетинга/IRP

Блок D: Измерение и улучшение

- [ ] Определены и измеряются базовые KPI (MTTD, MTTR, FP Rate)
- [ ] Настроена ежемесячная отчётность для руководства
- [ ] Запланирован первый Purple Team/Red Team через 6 месяцев после запуска
- [ ] Обозначен бюджет на обучение команды на следующий год

> Если все блоки выполнены — SOC готов к запуску в боевом режиме. Статус «готов» не означает «совершенен»: SOC — это непрерывный процесс улучшения, а не проект с финальной датой.

16. Заключение

По данным AM Live 2026 года, у 70% компаний крупного и среднего бизнеса уже есть SOC, но почти у половины — неэффективный. Причина не в инструментах. Причина в фундаменте: нет понимания целей, нет инвентаризации, нет процессов.

Построение эффективного SOC в 2026 году — это трёхлетний проект, а не шестимесячный. Первый год — фундамент и технологический старт. Второй — оптимизация и расширение покрытия. Третий — выход на зрелость с Threat Hunting и измеримыми результатами.

Главные принципы, которые работают на практике: начинать с бизнес-целей и «недопустимых событий», а не с выбора SIEM. Строить команду под задачи, а не задачи под доступную команду. Автоматизировать только то, что уже формализовано. Измерять всё, что поддаётся измерению. Тестировать SOC регулярно — не ждать реального инцидента.

Следующий шаг: запишитесь на практикум по построению SOC от Positive Technologies (следующий поток — апрель 2026), посетите конференции ZeroNights и SOC Forum, присоединитесь к профессиональным Telegram-каналам ИБ-сообщества.

Пять правил эффективного SOC

1. Начинай с целей, а не с инструментов
2. Без Asset Management SIEM — просто дорогое хранилище логов
3. Команда важнее технологий: 11 человек без процессов хуже 5 с чёткими плейбуками
4. Измеряй MTTD и MTTR каждый месяц — это единственный способ понять, улучшается ли SOC
5. Тестируй SOC регулярно через Purple Team — не жди реального инцидента