Какой SOC выбрать?Свой, аутсорсинговый или гибридный

Каковы же главные критерии выбора в пользу использования локального Security Operations Center, для кого он актуален? Думаю, не открою тайну, если скажу, что основной SOCостроитель – компании и корпорации сегмента Enterprise. Именно в этом сегменте департамент информационной безопасности имеет значительный штатный состав, собственные бюджеты и четко очерченный круг решаемых задач. Высокая ценность защищаемой информации, большое количество различных средств ее защиты, территориально распределенная структура, количество работников в несколько тысяч человек – если эти критерии относятся к профилю компании, наверняка создание собственного SOC – вопрос времени.

Основой любого центра мониторинга и реагирования на инциденты информационной безопасности являются следующие компоненты:

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

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

Персонал, контент, процессы

Про дефицит специалистов и инженеров ИБ на российском рынке написано немало статей. Поиск одного аналитика зачастую занимает несколько месяцев, в зависимости от предлагаемых условий. Далее необходимо еще до полугода, в зависимости от квалификации сотрудника, для полноценного включения его в работу. Если же у компании существуют требования к организации мониторинга 24х7, то ситуация усложняется еще больше.

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

Наполнение SIEM-системы контентом является важнейшей задачей, т.к. базовый набор правил "из коробки" не способен закрыть все потенциальные векторы угроз для компании, особенно класса Enterprise. Для решения данной задачи необходим архитектор SIEM-системы, который будет выстраивать контент в зависимости от поставленных перед SOC целей, адаптировать его под инфраструктуру, реализовывать сценарии выявления инцидентов в бизнес-приложениях. Также необходимы инженеры для подключения источников и написания коннекторов к приложениям, администратор, обеспечивающий работоспособность и занимающийся "железной" архитектурой.

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

SOC as Service

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

Другим важным аспектом, который стоит учитывать при построении собственного центра мониторинга, является желание бизнеса выделять деньги на обеспечение безопасности здесь и сейчас. Он часто не готов ждать 1–2 года, пока "взлетает" внутренний SOC.

Здесь и поможет сервис-провайдер, "закрыв" переходный период до запуска собственного Security Operations Center, встроив свои процессы в текущую модель информационной безопасности компании.

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

Если вы используете SOC as Service, то сразу решаете проблему персонала (как инженеров, так и аналитиков), наполнения контентом SIEM-системы, разработки регламентов и процессов взаимодействия при обнаружении, разборе и противодействии инцидентам – все задачи ложатся на плечи аутсорсера. При этом сервис-провайдер учитывает специфику компании и внутренние требования к организации процесса. В регламенте отражается четкое разделение ответственностей между заказчиком и подрядчиком.

Но если компания настроена на строительство собственного SOC, в рамках переходного периода наиболее интересным вариантом к рассмотрению является использование гибридной модели Security Operations Center, подразумевающей под собой использование собственной SIEM-системы, которую сервис-провайдер забирает на администрирование и "приземляет" на нее контент, оптимизируя под заказчика. Гибридный вариант также решает задачу быстрого поиска команды мониторинга, что дает дополнительное время компании на поиск собственной команды.

Гибридный SOC

Давайте остановимся подробнее на архитектуре данного решения.

В случае гибридной модели SIEM-система приобретается на средства компании и располагается в ее инфраструктуре. Выбор нужного решения является сложным вопросом, и при решении использовать гибридный SOC необходимо учитывать тенденции рынка и мнение компании, оказывающей аутсорсинговые услуги. Большинство отечественных сервис-провайдеров на данный момент используют HP ArcSight, хотя в последнее время поднимаются разговоры об использовании IBM QRadar, Splunk и даже российских SIEM-систем в качестве платформы оказания сервиса по мониторингу и реагированию на инциденты.

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

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

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

Помимо регламента регистрации и оповещения по инцидентам ИБ, важным процессом является процедура взаимодействия с ключевыми подразделениями при разборе инцидентов и противодействия угрозам. Период оказания сервиса позволит создать представление о том, как выстраивать взаимодействие с ИТ-отделом, службой сервис-деска, бизнес-подразделениями к моменту запуска внутреннего SOC.

При использовании гибридного варианта решаются в том числе те немногие проблемы использования облачного SOC, которые тревожат некоторые компании:

1. События информационной безопасности с систем-источников компании остаются в ее инфраструктуре.
2. После отключения от услуги сервис-провайдера у компании остается система сбора событий, которую можно использовать далее.
3. Загрузка интернет-канала при гибридном варианте значительно ниже, чем при облачном варианте подключения.

Даже при отключении от услуг сервис-провайдера регламенты, процедуры, отработанные с сервис-провайдером, можно использовать в рамках внутреннего Security Operations Center, собрав собственную команду аналитиков, администраторов и инженеров мониторинга. Также большинство аутсорсеров позволяют "выкупить" контент и помогают в нем разобраться. Таким образом, когда команда будет готова, наберется опыта в разборе и расследовании инцидентов, необходимо будет лишь перевести SIEM-систему под свой контроль и бесшовно продолжить мониторинг инцидентов.

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