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