Разбегаются глаза. Какую модель функционирования SOC выбрать?

Разбегаются глаза. Какую модель функционирования SOC выбрать?

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

У каждой из этих полярных позиций есть свои сторонники и противники. Сторонники коммерческих SOC, которые, как правило, в этих центрах и работают, ратуют за то, что они оказывают профессиональные услуги в режиме 24×7 и имеют в штате высококлассных аналитиков и специалистов. Сторонники противоположной позиции считают, что, строя собственный SOC, не будут утеряны компетенции сотрудников, а также не будет потерян контроль над достаточно чувствительной информацией. Кто же прав? Какой из двух вариантов построения SOC является правильным?

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

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

МОДЕЛЬ «МОГУ И ХОЧУ»

Это та модель, когда мы имеем и возможности, и ресурсы для построения собственного центра мониторинга. В этом случае мы закупаем нужные инструменты или создаём их своими руками, нанимаем высококлассных аналитиков и разрабатываем для них как план обучения, так и карьерный путь развития (а иначе они уйдут от нас, когда поднаберутся опыта), мы покупаем подписку на сервисы Threat Intelligence. При этом мы готовы к достаточно небольшой скорости развёртывания собственного центра – обычно этот срок занимает от года и выше, и это ещё оптимистичная оценка. SOC постоянно развивается, и на достаточно зрелый уровень он выходит только через 2–3 года эксплуатации.

Считается, и это неслучайно, что основные затраты при построении собственного SOC приходятся на закупку решений, составляющих технологический стек будущего центра мониторинга – SIEM для сбора сигналов тревоги, SOAR/IRP для управления инцидентами и автоматизации реагирования, TIP для обработки данных об угрозах, платформу для взаимодействия аналитиков и членов команды реагирования, платформу для хранения и обмена знаниями. SOC нового поколения также включает, помимо SIEM, ещё и решение по анализу сетевого трафика (NTA или NDR), решение по мониторингу активности на оконечных устройствах (EDR), а также при необходимости решение по мониторингу облачных сред (CASB). Если добавить сюда различные утилиты для проведения форензики (анализа памяти, реверс-инжиниринга), хранилище данных, сервера и персональные компьютеры, то сумма выходит достаточно кругленькая.

Отчасти поэтому, чтобы снизить риски санкций (как американских, мешающих использованию некоторых отечественных решений, так и российских, называющихся «импортозамещением»), а также для получения большей гибкости в решаемых задачах, многие компании строят свои SOC на компонентах opensource (например, связка ELK + MISP + TheHive), а также используют иные способы экономии (рис. 1).

Рисунок 1. Экономические аспекты оценки модели построения SOC

А ведь в собственном SOC нам надо ещё посчитать фонд оплаты труда для недешёвых аналитиков, работающих в 2–3 смены, их обучение, мебель, помещение и даже шредеры для уничтожения бумаг. В целом собственный SOC – это удовольствие недешёвое.

МОДЕЛЬ «ХОЧУ, НО НЕ МОГУ»

На противоположной стороне у нас находится аутсорсинговый SOC, услугами которого мы пользуемся, чтобы снять с себя все хлопоты по мониторингу и реагированию на инциденты. В этом случае все описанные ранее затраты у нас ложатся на выбранного партнёра, а мы уходим от модели капитальных затрат к операционным, которые выплачиваются небольшими частями ежегодно или ежеквартально; последний вариант, однако, у нас в регионе не очень развит. Учитывая полную противоположность этой модели, можно даже привести таблицу их сравнения, которая покажет плюсы и минусы обоих вариантов (рис. 2).

Рисунок 2. Сравнение двух основных подходов к построению SOC

Вроде бы кажется, что аутсорсинговый SOC обладает всеми преимуществами и не имеет недостатков, но это не так. Во-первых, в этом варианте построения центра мониторинга мы со временем теряем собственные компетенции и, если нам придётся по каким-то причинам расстаться с выбранным партнёром, мы останемся у разбитого корыта – никто нам уже не поможет оперативно разобраться с нашими инцидентами ИБ. Во-вторых, аутсорсинговый SOC всё равно требует контроля со стороны заказчика, что также требует и определённого инструментария, и персонала, который будет как минимум проводить анализ защищённости SOC (пентестеры или red team), а также оценивать результаты работы внешнего SOC и быть посредником между ним и внутренней ИТ-службой, которая должна будет реализовывать рекомендации по реагированию на инциденты и устранению причин, к ним приведших. В-третьих, любая внешняя организация гораздо хуже разбирается в вашей внутренней инфраструктуре, бизнес- и иных процессах, и поэтому реакция на некоторые инциденты может быть не всегда той, которую вы ждёте или которая лучше всего подходит к вашей ситуации. В-четвёртых, любая внешняя компания предлагает обычно типизированные сервисы, которые подходят большинству заказчиков. Если вы захотите чего-то особенного и выходящего за рамки привычных услуг SOC или их наполнения, то вам придётся раскошелиться – на коннекторы к вашим бизнес-системам, на особые условия реагирования (например, для изолированных систем), на написание собственных правил обнаружения и т. п. Ну и, наконец, не забывайте, что канал связи с вашим аутсорсинговым SOC может вдруг выйти из строя, снизится его пропускная способность или качество обслуживания, что тоже повлияет на оказываемые вам услуги SOC.

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

МОДЕЛЬ «ЕСТЬ ЧЕМ, НО НЕ С КЕМ»

Но существуют и иные модели организации центров мониторинга. Например, нередка ситуация, когда в организации есть весь необходимый инструментарий для сбора сигналов тревоги и расследования инцидентов, но нет людей для этого. Причём причиной может быть как нехватка денег на квалифицированные кадры, так и внутренняя политика компании, которая имеет чётко определённую численность разных подразделений и не может увеличивать её по своему желанию. В этом случае у нас получается SOC по модели «Managed SIEM» (условное название), в котором мы берём от внешнего SOC только персонал (аутстаффинг), который либо располагается на нашей территории, либо подключается к нашим техническим решениям удалённо.

В этой модели промежуточного SOC основной головной болью будет контроль персонала, получившего доступ к нашей инфраструктуре гораздо более глубокий, чем в случае с аутсорсингом, при котором аналитики и специалисты по реагированию работают с инструментарием, расположенным на своей территории. Кроме того, придётся открывать большее число каналов для доступа к SIEM, IRP, TIP и т. п., что может быть небезопасно, особенно если злоумышленники сначала атакуют провайдера услуг SOC, а через него уже и самих его заказчиков. По данным SOC Секретной службы США, начиная с 2019 года число атак на провайдеров услуг многократно возросло (только в 2019-м их было более 60). Размещение внешнего персонала на своей территории в этом случае выглядит предпочтительнее, но тогда придётся задуматься о выделении отдельного помещения, а то и не одного, для этих людей.

МОДЕЛЬ «ЕСТЬ С КЕМ, НО НЕЧЕМ»

Четвёртая распространённая модель построения SOCзаключается в том, что у компании могут быть квалифицированные специалисты, но нет ресурсов на закупку дорогостоящих коммерческих SIEM, SOAR, TIP и т. п. В этом случае нам остаётся либо осваивать opensource (в таком случае эта модель превращается в первую), либо обращаться к услугам инструментов, развёрнутых в облаке (условно эту модель можно назвать SIEM-as-a-Service). Последний вариант, кстати, является достаточно неплохой альтернативой в случаях, когда вы редко сталкиваетесь с продвинутыми злоумышленниками, а про государственных хакеров слышали только по ТВ или читали в Интернете. В этом случае вам необязательно строить дорогостоящий SOC, но функции мониторинга и анализа событий безопасности вам всё равно нужны.

Эта модель позволяет быстро проверять новые возможности и гипотезы без установки нового ПО (достаточно просто «на время» арендовать услугу из облака). Отсутствие необходимости установки ПО (а по статистике 45% компаний тратит только на внедрение SIEM более 3 месяцев) также снимает с нас головную боль по его масштабированию, обновлению, устранению уязвимостей и т. п. Также в зависимости от выбранной платформы в неё уже могут быть встроены различные плейбуки (дежурные процедуры реагирования), представлен каталог сценариев (usecase), применяться инструментарии обогащения событий и т. п.

ЧЕТЫРЕ МОДЕЛИ

Рисунок 3. Четыре основных модели построения технологического стека SOC

В итоге у нас получается четыре основных модели построения центра мониторинга и реагирования на инциденты ИБ, из которых Managed SIEM является наиболее редкой. И у каждой из этих моделей есть свои преимущества и недостатки, которые не дают однозначного выбора в пользу одной из них (рис. 3, 4).

Рисунок 4. Экспресс-сравнение основных моделей построения технологического стека SOC

МОДЕЛЬ «ВСЕГО ПОНЕМНОГУ»

Но не стоит думать, что этими четырьмя моделями всё ограничивается. На самом деле существуют и различные промежуточные варианты, которые находятся где-то между всеми этими моделями. Например, мало кто содержит собственных специалистов по реверс-инжинирингу вредоносного ПО. Эта функция отдаётся обычно на аутсорсинг, и то не на постоянной основе, а эпизодически, по мере появления ранее неизвестного ПО, которое вызывает подозрения, но на которое никак не реагирует имеющаяся песочница.

Другой пример. Согласно статистике некоторых российских коммерческих SOC число их заказчиков, выбравших не только мониторинг, но ещё и реагирование на выявленные инциденты, невелико – всего около 15%. Иными словами, 85% пользователей аутсорсинговых SOC отдают только мониторинг, но реагирование оставляют за собой, что требует не только соответствующих инструментов, но и специалистов.

Третий вариант гибридной модели заключается в том, что на стороне внешнего SOC реализуется только первая линия анализа событий безопасности, которые после обработки, классификации, приоритизации и объединения в инциденты, попадают на вторую и третью линию, расположенную уже на стороне заказчика. Кстати, возможен и противоположный вариант – первичный анализ осуществляется на стороне заказчика, а анализ со стороны более квалифицированных аналитиков требует привлечения внешнего SOC. А анализ в нерабочее время, выходные и праздничные дни? Кто его осуществлять будет, если у вас нет возможности обеспечить работу центра в режиме 7×24, а только в режиме 5×8?

А ведь мы рассмотрели только основные услуги, которые оказывает SOC, –мониторинг и реагирование на инциденты. А redteam’инг или фишинговые симуляции, которые тоже могут входить в сервисный каталог центра мониторинга?

ЧТО ВЫБРАТЬ?

Какую же тогда модель центра мониторинга и реагирования на инциденты выбрать? Какая из них будет более правильной? Может показаться, что ответа нет, но это не так. Он есть, и называется он «сервисная стратегия SOC». В ней определяются все исходные данные, которые влияют на выбор модели, – имеющиеся ресурсы, ожидания, желаемые результаты и сроки их достижения, распределённость компании и функционирование в разных часовых поясах и юрисдикциях, наличие инсорсинговой компании в холдинге, временные параметры, модель нарушителя, требования законодательства, квалификация персонала, возможности ИТ-службы, зависимость бизнеса от информационных технологий, культура компании. И это только часть вопросов, которые повлияют на решение о том, какой модели SOC надо придерживаться (рис. 5).

Рисунок 5. Компоненты сервисной стратегии SOC

Главное, задать эти вопросы в самом начале пути под названием «центр мониторинга и реагирования на инциденты ИБ». Именно ответы на них позволят не только определить модель функционирования SOC, но и оказываемые им сервисы, ключевые процессы, необходимые для их реализации, оргштатную структуру и режим работы аналитиков SOC, программу их обучения и т. п. И только в самом конце мы подойдём к вопросу архитектуры SOC и технологического стека, лежащего в её основе. И только в таком порядке. Удачи вам на этом непростом пути!