На проверке Гибридный SOC на практике: как распределить функции между внутренней командой и провайдером

[Сергей Попов]

За последние два года я перевёл SOC двух организаций из чисто инхаус-формата в гибридный. В обоих случаях самым сложным оказался не выбор провайдера, а чёткое разграничение зон ответственности. В первом проекте провайдер «проспал» lateral movement по RDP (T1021.001) - у него не было доступа к контексту внутренней сети, и об аномальных RDP-подключениях между серверами он узнал через 14 часов, когда атакующий уже закрепился. После этого инцидента мы полностью пересмотрели матрицу распределения функций. Этот документ лёг в основу второго проекта, где MTTD на аналогичные сценарии упал до 23 минут.

Почему гибридная модель SOC становится стандартом​

По данным блога D3 Security (со ссылкой на исследование Gartner 2023 года о стратегиях SOC, без указания точной публикации), около 63% организаций используют гибридную модель - сочетание внутреннего персонала и внешних ресурсов. Полностью внутренний SOC тянут 34%, преимущественно крупные структуры, способные содержать круглосуточную смену. По тем же данным, процессы и технологии объясняют около 70% вариации успеха SOC, а больше половины организаций пересматривают операционную модель минимум раз в квартал.

На российском рынке картина похожая - с поправкой на кадровый голод. По данным опроса К2 Кибербезопасность (100+ ИТ- и ИБ-директоров, дата и методология публично не раскрыты), только у 20% компаний работают все три компонента SOC - люди, технологии, процессы. Проваливаются чаще всего процессы и персонал, а не технологии. 91% компаний считают приоритетом реальную защиту, а не формальное соответствие требованиям регулятора. Звучит красиво - на практике «реальная защита» без людей и процессов остаётся SIEM-ом, который пишет логи в пустоту.

Типичный путь к гибридному SOC выглядит так:

1. Компания разворачивает SIEM (MaxPatrol SIEM, KUMA, QRadar) и нанимает 3–4 аналитиков.
2. Через полгода выясняется, что 24/7 покрытие требует минимум 8–10 человек с учётом отпусков и больничных.
3. Ночные смены убивают мотивацию - текучка растёт.
4. Руководство отдаёт ночной мониторинг провайдеру - и начинаются проблемы разграничения.

На Gartner Security & Risk Management Summit 2023 (по материалам Splunk) представители Just Eat рассказали обратный кейс: они перешли от полного аутсорсинга к гибриду, потому что MSSP не адаптировался к изменениям в архитектуре и вместо реагирования постоянно переспрашивал «а что это значит?». Один из участников круглого стола назвал своего провайдера «TSSP - ticketing security service provider» - создаёт тикеты, не имея ни полномочий, ни контекста для реальных действий. В итоге MSSP генерировал дополнительную нагрузку на внутреннюю команду, а не снимал её. Знакомая ситуация, правда?

Сравнение трёх моделей SOC: trade-off таблица​

Прежде чем копать в матрицу распределения функций гибридного SOC, зафиксирую отличия моделей. Таблица основана на данных EN-источников (Bridewell, DigitalXRAID, Splunk roundtable) и нашей практике. По оценкам DigitalXRAID (без указания даты публикации), инхаус-вариант может стоить от 500 000 фунтов стерлингов в год, управляемый - от 5 фунтов в час. Ниже - ориентировочные оценки стоимости для российского рынка, основанные на опыте автора (без претензии на репрезентативность).

Критерий	Инхаус SOC	Полный аутсорсинг (MSSP)	Гибридный SOC (co-managed)
Стоимость запуска (год, ориентировочно)	~40–60 млн руб.* (персонал + SIEM + инфраструктура)	~3–8 млн руб./год* (подписка)	~15–30 млн руб.* (ядро + подписка на L1)
Время до боеспособности	6–12 месяцев	2–4 недели	2–4 месяца
24/7 покрытие	Требует 8–12 FTE	Нативно	L1 - провайдер, L2/L3 - инхаус (on-call)
Глубина контекста	Максимальная	Минимальная (шаблонные правила)	Средняя-высокая (при правильном онбординге)
Контроль данных	Полный	Данные у провайдера или в его облаке	SIEM on-prem, провайдер - удалённый доступ
Кадровые риски	Высокие (выгорание, текучка 30–40%/год)	Низкие (проблема провайдера)	Умеренные (ядро меньше, ротация проще)
Регуляторные риски (ФЗ-187)	Минимальные	Требуют договорного покрытия	Требуют чёткой RACI-матрицы
Кастомизация detection-контента	Полная	Ограниченная (пакеты правил)	Кастомные правила - инхаус, baseline - провайдер
Threat hunting	Нативно	Обычно за рамками ответственности провайдера	Инхаус-команда, с ограниченным участием провайдера при зрелом co-managed процессе

Инхаус достаточен, когда бюджет от 60 млн руб./год, есть устойчивый кадровый pipeline и высокие требования к конфиденциальности (финтех, оборонка). Полный аутсорсинг оправдан для компаний до 500 сотрудников без собственной ИБ-экспертизы - нужен быстрый запуск за 2–4 недели. Гибрид нужен среднему и крупному бизнесу с 2–5 ИБ-специалистами, собственным SIEM и требованиями ФЗ-187 по обеспечению безопасности ЗОКИИ.

Матрица распределения функций в гибридном SOC​

Это ядро статьи - конкретная таблица, которую можно адаптировать под свою организацию. В Bridewell подчёркивают: «The most successful models offer flexibility rather than a rigid responsibilities matrix». Спорить тут не с чем, но без стартовой матрицы гибкость превращается в хаос.

Что нельзя отдавать провайдеру​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Что отдаётся провайдеру​

Функция	Обоснование	Условия передачи
Мониторинг L1 (triage) 24/7	Экономия 5–7 FTE, снижение выгорания	SLA: классификация ≤15 мин, эскалация L2 ≤30 мин
Поддержка инфраструктуры SIEM	Рутина, не требует бизнес-контекста	Доступ через jump-host, аудит всех действий
Базовый detection-контент (vendor-пакеты)	Экономия времени на стандартные use cases	Ревью инхаус-командой перед включением в прод
Health-мониторинг сбора событий	Первая линия контроля полноты данных	Алерт инхаус-команде при потере источника >5 мин

Co-managed зона: где 80% конфликтов​

Самая проблемная область. Принцип простой: для каждой функции в co-managed зоне назначается один владелец решения (decision owner) и один исполнитель. Совпадают - отлично. Не совпадают - описывается точка эскалации. Без этого - бесконечный пинг-понг тикетами.

Функция	Владелец решения	Исполнитель	Координация
Расследование L2	Инхаус	День - инхаус, ночь - провайдер с эскалацией	Playbook в SOAR с точками передачи
Тюнинг правил (снижение FP)	Инхаус	Провайдер предлагает, инхаус утверждает	Еженедельный FP review
Vulnerability management	Инхаус	Провайдер - сканирование, инхаус - приоритизация	SLA на передачу отчёта: 24 часа
Отчётность и метрики	Инхаус	Провайдер - сбор данных, инхаус - анализ	Ежемесячный отчёт + квартальный review

Интеграция SIEM и процессов с внешним провайдером​

Техническая интеграция - вторая точка отказа после разграничения ответственности. Три элемента: архитектура доступа, тикет-система и разделение detection-контента.

Архитектура доступа​

Провайдер подключается через выделенный jump-host с MFA. Все действия логируются в отдельный индекс SIEM. В MaxPatrol SIEM это реализуется через отдельную роль с ограниченными правами - только чтение событий и управление назначенными инцидентами. В Splunk - через RBAC с кастомной ролью, ограниченной конкретными индексами. В QRadar - через Security Profiles с ограничением по log source groups.

Учётные записи провайдера - отдельные именованные аккаунты, привязанные к конкретным аналитикам. Никаких групповых учёток - это не только best practice, но и требование для аудита. Valid Accounts (T1078) - один из основных векторов атак, и мониторинг аккаунтов провайдера должен быть не менее строгим, чем мониторинг привилегированных учёток сотрудников. На одном проекте мы поймали ситуацию, когда аналитик провайдера залогинился ночью с нетипичного IP - оказалось, работал из дома через мобильный интернет. Но алерт сработал корректно, и это хороший знак.

Тикет-система и SOAR​

Два рабочих варианта:

Единая тикет-система - провайдер работает в вашей IRP/SOAR (Security Vision, R-Vision, Palo Alto XSOAR). Единый журнал, нет потери контекста при эскалации. Минус: нужно выдавать доступ к внутренней системе.

Двусторонняя интеграция - у провайдера своя тикет-система, синхронизация через API. Инцидент создаётся у провайдера, при эскалации дублируется в вашу IRP с полным контекстом. Плюс - изоляция систем. Минус - задержка синхронизации и риск потери данных при сбое API.

На практике первый вариант лучше для гибридного SOC, второй - для чистого аутсорсинга. В одном проекте мы использовали Security Vision с ролью «Внешний аналитик» - доступ только к назначенным инцидентам и связанным событиям, без возможности видеть полную карту инфраструктуры. Работает.

Разграничение detection-контента​

Правила корреляции в SIEM делятся на три категории:

Vendor-пакет - стандартные правила от разработчика SIEM или провайдера. Покрывают baseline: брутфорс, аномальные логины, базовое вредоносное ПО. Провайдер отвечает за поддержку и обновление.

Кастомные правила - специфичные для вашей инфраструктуры. Обнаружение Scheduled Task (T1053.005) на контроллерах домена, PowerShell (T1059.001) с обфусцированными параметрами на серверах бухгалтерии. Создаёт и поддерживает инхаус-команда.

Threat intelligence-driven правила - IoC-фиды, YARA, Sigma из open-source. Провайдер поставляет обновления, инхаус-команда адаптирует под среду.

Ключевая ошибка - позволить провайдеру отключать или модифицировать кастомные правила без согласования. Реальный пример: правило срабатывало на создание Local Account (T1136.001) с последующим добавлением в группу администраторов. Провайдер классифицировал это как FP, потому что не знал - в этом OU учётные записи создаются только через ServiceNow workflow. Любое создание вручную - аномалия. Провайдер этого контекста не имел, правило выключил, и мы узнали об этом через неделю на ревью. Вот почему decision owner для кастомных правил - всегда инхаус.

Метрики контроля качества гибридного SOC​

Без метрик разговор о качестве - пустое. Набор ниже реально используется для оценки провайдера в рамках распределения функций SOC:

Метрика	Целевое значение	Как измерять	Действия при отклонении
MTTD (Mean Time to Detect)	≤30 мин для P1	Разница между timestamp первого события и создания инцидента	Ревью правил, проверка полноты источников
MTTR (Mean Time to Respond)	≤4 ч (рабочее), ≤8 ч (нерабочее)	Разница между созданием инцидента и первым containment-действием	Оптимизация playbook, пересмотр эскалации
FP rate	≤20% от общего потока	Еженедельный подсчёт FP/TP по закрытым инцидентам	Тюнинг правил, whitelist
Покрытие источников	100% критических активов	Heartbeat-мониторинг	Алерт при пропадании >5 мин
Эскалация L1→L2	≤15 мин (P1), ≤30 мин (P2)	Timestamp в тикет-системе	Штрафные санкции в SLA
Качество тикетов	≥4 обязательных поля (IoC, хосты, timeline, рекомендации)	Аудит 10% тикетов ежемесячно	Обратная связь, обучение аналитиков

Метрика, которую часто забывают: detection coverage по MITRE ATT&CK. Раз в квартал маппим активные правила на матрицу. Если провайдер отвечает за L1 - у него должно быть покрытие минимум по Initial Access и Execution. Техники Lateral Movement (T1021.001, Remote Desktop Protocol) и Defense Evasion (T1562.001, Disable or Modify Tools; T1070.001, Clear Windows Event Logs) - зона совместной ответственности с приоритетом инхаус-команды, потому что их обнаружение требует понимания нормального поведения сети. Провайдер не знает, что у вас админы привыкли ходить по RDP на три сервера в 2 ночи - а ваша команда знает.

Регуляторные ограничения при аутсорсинге SOC-функций​

Для субъектов КИИ (ФЗ-187) ограничение жёсткое: ответственность за обеспечение безопасности ЗОКИИ несёт субъект, а не подрядчик. Приказ ФСТЭК №239 определяет набор мер (ИАФ, УПД, АУД, РСБ и др.), выполнение которых можно делегировать технически, но не юридически.

На практике это требует трёх вещей:

1. Договор с провайдером содержит явное описание мер из Приказа №239, которые провайдер реализует. Без этого при проверке ФСТЭК субъект КИИ не подтвердит выполнение требований.
2. Взаимодействие с НКЦКИ (ГосСОПКА) - обязанность субъекта КИИ. Провайдер может готовить карточку инцидента, но отправляет её субъект. Тут без вариантов.
3. Хранение логов - если SIEM на площадке заказчика, вопросов нет. Если в облаке провайдера - необходимо соответствие требованиям к хранению (обычно 6–12 месяцев для ЗОКИИ) и доступ для проверяющих.

Для ИСПДн (ФЗ-152) ситуация мягче: оператор ПДн вправе поручить обработку третьему лицу (ст. 6), но при условии согласия субъектов и обеспечения конфиденциальности (ст. 7). Провайдер SOC, обрабатывающий логи с ПДн - обработчик по поручению, и договор должен соответствовать требованиям закона.

Чеклист запуска гибридного SOC​

Готовый чеклист для передачи руководителю проекта по построению SOC:

1. Инвентаризация активов и источников событий. Полный список критических систем для подключения к SIEM. Без этого провайдер мониторит 30% инфраструктуры и считает, что всё в порядке. Соответствует NIST CSF v2.0, ID.AM-01.
2. RACI-матрица по каждой функции SOC. Документ на 1–2 страницы. Каждая строка - конкретное действие (не «мониторинг», а «классификация алерта P2 в нерабочее время»).
3. SLA-документ с числовыми порогами: MTTD, MTTR, FP rate, время эскалации. Штрафные санкции за нарушение - иначе SLA останется декларацией.
4. Технический онбординг провайдера. Карта сети, список привилегированных УЗ, описание стандартных workflow (миграции, деплоймент, бэкап-задачи) - всё, что генерирует «шум» и может быть спутано с атакой.
5. Playbooks в SOAR для каждого типа инцидента с точками эскалации: на каком шаге L1 (провайдер) передаёт L2 (инхаус) и какой контекст обязателен при передаче.
6. Мониторинг действий провайдера. Отдельный набор правил в SIEM для отслеживания активности учётных записей провайдера: аномальное время входа, доступ к нетипичным системам, массовый экспорт событий.
7. Квартальный аудит detection-контента. Маппинг правил на MITRE ATT&CK, проверка покрытия, выявление слепых зон.
8. План выхода (exit strategy). Как забрать функции обратно: документация всех правил, экспорт playbooks, переходный период 2–3 месяца.
9. Регуляторная обвязка. Для субъектов КИИ: приложение к договору с перечнем мер Приказа ФСТЭК №239, порядок взаимодействия с ГосСОПКА, разграничение ответственности.
10. Baseline метрик. Измерить MTTD, MTTR, FP rate до передачи функций провайдеру. Без baseline невозможно оценить, стало лучше или хуже.

Когда я впервые выстраивал гибридную модель, главной ошибкой была вера в то, что провайдер «разберётся сам». Не разберётся. MSSP работает одновременно с десятками клиентов, и без детального онбординга ваша инфраструктура для него - один из множества безликих потоков событий.

Разница между провайдером, который открывает тикеты с пометкой «anomaly detected, please investigate», и тем, который пишет «нетипичное RDP-подключение от сервера X к серверу Y, оба в сегменте PCI DSS, пользователь Z обычно не работает в 3:00» - это не уровень сервиса. Это качество онбординга, за которое отвечает ваша команда.

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

Если в штате нет хотя бы двух человек, способных написать правило корреляции и разобрать инцидент до root cause - начинайте с полного аутсорсинга и параллельно выращивайте команду. На форуме codeby есть тред, где разбираем подобные кейсы разграничения ответственности между инхаус-командой и MSSP - стоит заглянуть.