Что такое SOC и почему с ним всё равно нужен SOAR

На встречах с заказчиками я регулярно слышу одну и ту же фразу: «У нас есть SOC, зачем нам ещё SOAR?» Вопрос честный. Чтобы на него ответить, нужно сначала разобраться, что такое SOC, что он делает и — что важнее — чего он не делает.

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

Что такое SOC простыми словами

SOC (Security Operations Center) — центр мониторинга и реагирования на инциденты информационной безопасности. Это не коробка и не программа, а функция: люди, процессы и технологии, которые круглосуточно смотрят на события в инфраструктуре, отличают атаку от шума и запускают реагирование.

Хорошая аналогия — пульт охраны. Датчики стоят по всему зданию, но смысл появляется, только когда кто-⁠то на пульте видит сработку, понимает, что это не кошка, и знает, кому звонить. SOC — такой пульт для цифровой инфраструктуры. Датчиками служат СЗИ, журналы серверов, сетевое оборудование, почта и облачные сервисы.

Задачи SOC обычно сводятся к пяти:

• Мониторинг — сбор и анализ событий в режиме 24/7.
• Детектирование — выявление подозрительной активности по правилам корреляции, индикаторам компрометации и поведенческим моделям.
• Анализ и расследование — ответы на вопросы «что произошло, насколько это серьёзно, что затронуто».
• Реагирование — сдерживание, устранение последствий, восстановление. Здесь начинается самое интересное, к этому вернёмся ниже.
• Улучшение — новые правила детектирования, разбор инцидентов, отчётность руководству и регулятору.

Линии SOC: чем заняты L1, L2 и L3

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

Рядом с линиями обычно работают инженеры, которые подключают источники и следят за здоровьем SIEM, аналитики киберразведки и руководитель SOC. В небольших командах роли совмещаются: один человек бывает и L2, и L3.

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

Из чего состоит центр мониторинга ИБ: люди, процессы, технологии

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

Люди

Аналитики всех линий, инженеры, руководитель. Дефицит кадров в ИБ ощущают все: по данным «Ведомостей» (2025), на одну вакансию в ИБ приходится 7 резюме, но 80 % кандидатов не готовы к реальной работе. Поэтому время сильных специалистов стоит тратить на мышление, а не на копирование IP-⁠адресов между окнами.

Процессы

Регламенты мониторинга и эскалации, классификация инцидентов, SLA, порядок взаимодействия с ИТ и владельцами систем, порядок уведомления регуляторов. Без процессов даже сильная команда работает по памяти, а память в три часа ночи подводит.

Технологии

• SIEM — сбор и корреляция событий, основной инструмент детектирования.
• EDR — видимость и действия на конечных точках: процессы, файлы, изоляция хоста.
• TI (Threat Intelligence) — индикаторы компрометации и контекст об угрозах и атакующих группировках.
• SOAR — оркестрация СЗИ и автоматизация реагирования по плейбукам. Подробно о классе — в статье «Что такое SOAR».
• Вокруг них — сканеры уязвимостей, учёт активов, ITSM, сетевые сенсоры, песочницы.

Обратите внимание: SIEM, EDR и TI отвечают в основном на вопрос «что происходит». SOAR отвечает на вопрос «что мы с этим делаем». Это различие станет ключевым через пару разделов.

Модели SOC: собственный, коммерческий и гибридный

Строить или покупать — первый стратегический вопрос. На практике вариантов три, и у каждого своя цена.

Отдельно отмечу: для субъектов КИИ центр мониторинга — это ещё и взаимодействие с ГосСОПКА по 187-⁠ФЗ. Задачу можно решать своими силами или через провайдера, но обязанности субъекта КИИ при этом никуда не деваются.

Как выбрать модель SOC

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

1. Сколько у вас людей в ИБ и готовы ли вы держать смены 24/7? Круглосуточный мониторинг — это несколько человек только на одну линию, с учётом отпусков и больничных. Если такой команды нет и не будет, полноценный собственный SOC — не ваш старт.
2. Насколько специфична инфраструктура? Промышленные сети, собственные разработки, нестандартные бизнес-процессы — всё это внешнему провайдеру придётся долго изучать.
3. Какие требования регуляторов? КИИ, персональные данные, отраслевые нормы влияют на то, какие данные можно отдавать наружу и кто отвечает за уведомления.
4. Кто и как будет реагировать? Кто в три часа ночи изолирует хост, заблокирует учётную запись и поменяет правило на межсетевом экране? Если ответа нет — у вас не SOC, а мониторинг.
5. Как будет расти функция? Гибридная модель часто оказывается разумным переходным этапом: провайдер закрывает круглосуточный мониторинг, а внутренняя команда набирает экспертизу.

Четвёртый вопрос — главный. И именно на нём спотыкаются чаще всего.

SOC и SOAR: почему реагирование всё равно остаётся у вас

Вот тезис, ради которого я сел за эту статью. SOC — особенно внешний — обнаруживает инцидент и сообщает о нём. Реагировать всё равно приходится вам: внутри своего периметра, своими правами и по своим процессам.

Причин три, и все они не про качество провайдера, а про устройство ответственности.

• Доступы. У внешнего SOC, как правило, нет административных прав в вашей инфраструктуре — и не должно быть. Права администратора домена или управление межсетевыми экранами у подрядчика — это новая точка компрометации, а атака через подрядчика давно стала известным вектором. Некоторые провайдеры предлагают активное реагирование через свои агенты EDR, но и тогда их полномочия ограничены договором и набором действий на конечных точках.
• Контекст. Только вы знаете, что сервер, который SOC предлагает изолировать, — это касса в разгар распродажи, а учётная запись «подозрительного» пользователя принадлежит финансовому директору в командировке. Решение о сдерживании — всегда баланс риска и бизнеса, и принимает его владелец бизнеса.
• Ответственность. Уведомить Роскомнадзор об утечке персональных данных в течение 24 часов по 152-⁠ФЗ, проинформировать НКЦКИ об инциденте на объекте КИИ, восстановить сервис из резервной копии — всё это обязанности заказчика. Провайдер может помочь с документами, но подпись и сроки — ваши.

В итоге между «SOC увидел» и «инцидент локализован» появляется стык: уведомление от провайдера, дежурный заказчика, поиск ответственных, ручные действия в пяти консолях. Именно на этом стыке теряются часы. В разговорах с заказчиками я раз за разом вижу одно и то же: время уходит не на обнаружение, а на передачу.

Мини-⁠сценарий: 03:40, алерт от SOC

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

Логика узнаваема: без SOAR реагирование начинается, когда проснётся нужный человек. С SOAR — когда пришло уведомление.

Важно: SOAR ничего не делает «сам по себе». Какие действия выполняются автоматически, а какие ждут подтверждения человека, решаете вы — в плейбуке, заранее и на свежую голову, а не в четыре утра. Для собственного SOC аргумент тот же, только стык проходит не между компаниями, а между ИБ и ИТ.

SOC и SOAR: кто за что отвечает

Как это устроено в Versium

Мы в Versium проектировали модуль SOAR именно под эту границу. Платформа разворачивается в контуре заказчика на Linux x86-64 через Docker Compose — онлайн или из офлайн-архива, с PostgreSQL 17 в составе поставки. Уведомления SOC и инциденты из KUMA, MaxPatrol SIEM, RuSIEM, Smart Monitor, BI.ZONE EDR, KATA, Kaspersky Security Center и PT NAD приходят в систему без дублей при повторной загрузке, обогащаются и запускают плейбук: изоляция хоста, блокировка учётной записи и сброс пароля в Active Directory, блокировка отправителя, запрет хеша в KATA, задачи ответственным с эскалацией по таймауту, оповещение смены в Telegram, VK Teams, DION или по почте. Инциденты, о которых нужно сообщить регулятору, попадают в очередь к уведомлению НКЦКИ, а каждый шаг сохраняется в истории инцидента.

Для провайдеров и холдингов есть мультиарендность на группах доступа — данные разных юрлиц и клиентов разделены внутри одной инсталляции. Коннекторы пишутся на .NET прямо в редакторе платформы, к любой таблице есть REST API, а внешние системы могут присылать события вебхуками, поэтому интеграцию с нестандартной системой может сделать сам заказчик или партнёр. Подробнее об архитектуре — на странице платформы.

С чего начать

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

1. 01

   Выберите один сценарий

   Самый частый и понятный — например, фишинг или подозрительный вход. Не пытайтесь автоматизировать всё сразу.

2. 02

   Договоритесь о границах

   Какие действия выполняются автоматически, какие — после подтверждения и кто подтверждает ночью.

3. 03

   Подключите источники и исполнителей

   Канал уведомлений от SOC, почтовый сервер, каталог учётных записей, межсетевой экран, мессенджер дежурной смены.

4. 04

   Протестируйте и расширяйте

   Прогоните сценарий на учениях, затем добавляйте следующие.

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