Не бывает одинаковых SOCов

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

Одним из популярных вопросов является такой "Мы решили построить у себя SOC. А что он должен делать?" Или компания имеет SOC (по крайней мере она так считает) и хочет сравнить себя с другими SOCами на рынке. Обе этих темы, особенно первая, говорит о двух вещах. Во-первых, сегодня нет устоявшегося определения, что же такое Security Operations Center? Даже по-крупному, можно выделить три ключевых направления, каждое из которых может называться модным термином SOC:

• Группа реагирования на инциденты (CSIRT). Основное предназначение такого подразделение - бороться с инцидентами и мониторинг только способствует решению этой задачи. Но его может и не быть вовсе внутри CSIRT или он может быть вынесен за пределы CSIRT, например, в ИТ. Схожая схема уже много лет реализована в Cisco и при правильно выстроенных процессах и взаимодействии между ИТ и ИБ является вполне работоспособной.
• Центр мониторинга ИБ. Это, можно так назвать, классическое понимание SOC, в ядре которого размещается SIEM и который, получая сигналы тревоги от кучи источников, запускает процессы обогащения этих данных и реагирования на инциденты, если они подтверждаются.
• Центр управления кибербезопасностью. Этот вариант реализуется в компаниях, в которых давно и успешно для компании выстроены процессы ИБ, но они достаточно монолитны и их сложно разделять. В таком сценарии мониторинг ИБ или реагирование на инциденты сложно отделить от управления средствами защиты - все делается всеми. 
• Центр поддержки ИБ. Это вольная трактовка аббревиатуры CDC, Cyber Defense Center, которая означает создание государственного центра ИБ, основная задача которого собирать данные об инцидентах и на их основе формировать рекомендации по борьбе с ними. Это некий аналог наших ФинЦЕРТ или ГосСОПКИ.

А все потому, что SOC строится исходя из разных предпосылок и задач. Даже на технологическом уровне, от того, с какими типами источников вы работаете, будет зависеть, будут похожи SOCи между собой или нет. Но SOC - это не только связка SIEM, SOAR и TIP, как трех основных платформ (их на самом деле чуть больше, но NTA, UEBA, EDR, находятся на стыке источников данных и платформ мониторинга). Это еще и сервисная стратегия, которой мало уделяют внимания при строительстве SOC, но которая и определяет каким он в итоге будет. Без нее SOC строится "снизу вверх", от технологического стека к набору процессов и поддерживающих их playbook.

С сервисной стратегией мы строим SOC "сверху вниз" и отталкиваемся от того, что нужно бизнесу в части мониторинга. Но про это я уже отдельно писал. Но даже если вернуться к более распространенной модели построения SOC "снизу вверх", даже в этом случае могут быть реализованы совершенно различные сервисы, которые повлияют и на упомянутый вначале заметки вопрос.

Вы только мониторите события безопасности, полученные из разнородных источников, или еще проводите активный Threat Hunting? Вы потребляете или создает контент Threat Intelligence? Вы "делаете SOC" для себя или помогаете внешним организациям? Red Team и фишинговые симуляции являются частью вашего SOC? Достаточно посмотреть на эти 4 вопроса (а их можно задать гораздо больше), чтобы понять, что сервисный каталог SOC, а значит и он сам, будет отличаться от организации к организации. Даже при его совпадении у вас начнутся отличия в сервисной модели (что-то вы будете делать самостоятельно, а что-то отдадите на аутсорсинг), а также на уровне технологического стека и компетенций аналитиков.

Отсюда простой вывод, который подтверждается практикой построения и аудита SOCов в Cisco, - двух одинаковых SOCов не бывает. Поэтому и не бывает универсального ответа на вопрос "Что такое SOC?". Поэтому так важно уметь сначала договориться о терминах, а уже потом спорить :-)