Есть три подхода к организации мониторинга и реагирования на киберинциденты. Одни компании предпочитают подключение ко внешнему провайдеру (MSSP), другие строят собственный SOC (Security Operations Center). Встречается и гибридная модель, когда часть функций по мониторингу и реагированию остаётся у MSSP, а часть — в зоне ответственности самой компании.
- Введение
- Варианты запуска мониторинга и реагирования
- Что важно учесть при создании внутреннего SOC
- Два пути создания SOC
- 4.1. Первый вариант
- 4.2. Второй вариант
- Выводы
Введение
В третьем квартале 2024 года специалисты BI.ZONE TDR зафиксировали на 8 % больше киберинцидентов, чем во втором. При этом доля инцидентов высокой критической значимости, которые способны нанести существенный ущерб, снизилась. Если в организации выстроены процессы непрерывного мониторинга и реагирования, действия атакующих оказываются пресечены на ранней стадии. Даже если им удаётся обойти системы превентивной защиты, специалисты выявляют действия киберпреступников до того, как те успевают продвинуться вглубь ИТ‑инфраструктуры и нанести ущерб.
Соответствующие задачи решает SOC. Можно выделить три способа запуска центра мониторинга и реагирования на инциденты. Какой из них выбрать, зависит от конкретной компании и ряда факторов.
В статье рассматриваются эти факторы, варианты запуска функции оперативного мониторинга и реагирования, а также нюансы, которые важно учитывать при создании собственного SOC.
Варианты запуска мониторинга и реагирования
Выбор схемы запуска SOC зависит от характеристик организации, зрелости её процессов и особенностей инфраструктуры. Для некоторых компаний годятся сразу несколько вариантов. В таких случаях выбор будет зависеть от приоритетов организации.
Вариант № 1. Подключение к коммерческому SOC
Организация может использовать внешний SOC, например BI.ZONE TDR — сервис для выявления и предупреждения киберугроз, а также реагирования на них под управлением экспертов. Поставщик услуги настраивает сбор событий с различных источников в инфраструктуре заказчика. В случае с BI.ZONE TDR у клиента также устанавливаются EDR-агенты, которые существенно расширяют возможности мониторинга. Все логи передаются провайдеру и анализируются в системах на его стороне.
В зависимости от тарифа внешний SOC может давать заказчику рекомендации по дальнейшим действиям в случае выявления инцидентов или даже заниматься активным реагированием — в частности, с помощью EDR-агентов или СЗИ заказчика.
Такая схема подходит в следующих ситуациях:
- У организации нет возможности привлечь высококвалифицированных аналитиков и экспертов в нужном количестве.
- Компания не считает целесообразным инвестировать в реализацию собственного SOC, но понимает важность и необходимость функции мониторинга и реагирования на инциденты.
- Организации важны управляемая «в моменте» модель лицензирования и стоимость.
- Есть необходимость оперативно запустить функции SOC (в срок до одного месяца).
- У компании нет специфических требований и ограничений в части аутсорсинга (например, с точки зрения законодательства или отраслевых требований).
Вариант № 2. Гибридная модель
В этом случае часть функций передаётся внешнему SOC (мониторинг, компьютерная криминалистика, анализ угроз и др.), а другие остаются в зоне ответственности компании (активное реагирование, эксплуатация инфраструктуры SOС и др.). Такая модель подразумевает, что компоненты платформы SOC располагаются в инфраструктуре заказчика и эксплуатируются как провайдером, так и специалистами самой организации.
Гибридная модель подойдёт в следующих ситуациях:
- У организации есть ресурсы для того, чтобы использовать компоненты платформы SOC (SIEM, EDR и пр.) совместно с MSSP. Специалисты заказчика готовы самостоятельно работать с событиями, разрабатывать правила, подключать источники и т. д.
- Компании трудно самостоятельно обеспечить функцию мониторинга и реагирования в режиме 24×7, либо у неё вообще нет такой возможности.
- События и оповещения о возможных инцидентах (алерты) не должны покидать периметр компании, а компоненты SOC должны располагаться в инфраструктуре согласно внутренним стандартам или нормам законодательства.
- Наработанный за время взаимодействия с коммерческим SOC контент (правила корреляции событий, индикаторы компрометации) должен оставаться внутри организации в случае отключения или смены MSSP.
- Компания готова отдать на аутсорсинг не имеющие критической значимости для бизнеса функции, например выявление инцидентов и анализ угроз, а техническое реагирование оставить за собой.
Вариант № 3. Запуск собственного SOC
Это тот случай, когда все связанные с мониторингом и реагированием функции находятся в зоне ответственности самой компании. Возможен также вариант с переходным периодом, в течение которого собственный SOC будет сопровождаться сервисом от внешнего провайдера. Закупка необходимого аппаратного и программного обеспечения, наём персонала — уже полностью на стороне самой компании.
Критерии, которые определяют необходимость строить внутренний SOC, следующие:
- У организации есть собственная инфраструктура федерального или регионального масштаба, либо требуется выстроить мониторинг и реагирование внутри холдинга.
- Имеющуюся потребность в мониторинге и реагировании не могут закрыть коммерческие SOC (из-за ограничений по доступу, специфичного инструментария и т. д.).
- Есть необходимость постоянно и на высоком уровне вовлекать персонал SOC в бизнес-процессы компании.
- Организация сама планирует выйти на рынок MSSP и предлагать свои услуги по мониторингу и реагированию другим компаниям.
Кибербезопасность — поддерживающая функция для бизнес-процессов. Как следствие, выбор схемы остаётся на усмотрение организации и зависит от её потребностей. Однако при изменении обстоятельств или стоящих перед компанией задач возможен переход от одной модели к другой. Так, для клиентов сервиса BI.ZONE TDR предусмотрена опция бесшовной миграции в гибридную модель или в собственный SOC.
Что важно учесть при создании внутреннего SOC
Некоторые компании через два-три месяца после создания собственного центра мониторинга сталкиваются с проблемами, которых никто не предвидел на старте проекта. Чтобы избежать дополнительных временных и финансовых затрат, необходимо с самого начала уделить пристальное внимание ряду моментов.
Функции будущего SOC
Кроме мониторинга и реагирования это также могут быть инвентаризация активов, устранение уязвимостей, защита веб-ресурсов и т. д. Формируя перечень функций SOC, нужно реально оценить текущие ресурсы и учесть планы по численности персонала и его компетенциям.
Также важно чётко определить, какие процессы, в которые владельцы бизнеса готовы инвестировать, важно оставить внутри компании, а какие функции SOC стоит отдать внешнему провайдеру и обращаться к нему при необходимости. Например, процессы мониторинга и реагирования выстраиваются внутри организации, а анализ угроз, расследование инцидентов, защиту веб-ресурсов можно получать в виде услуг от MSSP.
Организационная структура SOC
Речь здесь идёт как о физическом расположении, так и о логической организации. Неверно выбранная локация может в дальнейшем не соответствовать зарплатным возможностям компании. Другая потенциальная проблема: если в выбранном регионе нет профильных вузов, будет трудно найти квалифицированные кадры для SOC. И самое важное, что необходимо учесть, — это наличие персонала, который обладает сильными компетенциями на момент начала создания центра мониторинга и сможет стать ядром сильной команды будущего SOC.
Логическая организация структуры может быть как локальной (то есть все сотрудники SOC находятся в одном регионе), так и распределённой. Во втором случае важно учитывать часовые пояса подразделений, организовывать сменный график, а для инженеров реагирования стоит предусмотреть локальное присутствие на объекте.
Расположение ядра платформы SOC и его юридическая принадлежность
Этот момент особенно актуален для компаний с распределённой инфраструктурой федерального или регионального уровня или крупных холдингов. Нужно определить на момент старта проекта наличие виртуальных и аппаратных ресурсов, средств организации каналов связи и защиты, которые могут быть дальше использованы для решения задач SOC.
Важный аспект — юридическая сторона вопроса: какому юрлицу будет принадлежать платформа SOC и как будет выстроено взаимодействие с другими компаниями холдинга и регуляторами с точки зрения соответствия законодательству. Например, может потребоваться получить лицензию ФСТЭК России на ТЗКИ с соответствующими пунктами.
Целевой уровень зрелости SOC и сроки его достижения
Важно реально соотнести такие аспекты, как актуальность киберугроз для компании, ценность защищаемых ресурсов, значимость информационных систем, требования регуляторов, с границами бюджета, выделенного на реализацию проекта. Исходя из этих данных формируются концепция SOC, дорожная карта создания и развития SOC и финансово-экономическое обоснование. Если не уделить этому должного внимания, есть риск запросить сверхбюджеты на построение SOC и в итоге получить отказ в финансировании от владельцев бизнеса.
Актуальные для компании киберугрозы
Необходимо определить ландшафт угроз, актуальный для компании. Во-первых, это позволит правильно приоритизировать подключение источников событий и подобрать необходимые инструменты для мониторинга и реагирования, чтобы противостоять реальным атакам.
Во-вторых, это важно при разработке собственного контента SOC. Если он не учитывает актуальные угрозы, в итоге окажется, что компания не готова к их отражению. То же самое можно сказать и о «коробочном» типовом контенте от вендора, не учитывающем специфику инфраструктуры. Через два-три месяца такие правила создают большой поток срабатываний («шум»), которые не дают полных данных для принятия решения.
Два пути создания SOC
Уделив внимание всем этим пяти аспектам запуска мониторинга и реагирования, компания сможет понять, какой вариант создания SOC ей подходит. BI.ZONE предлагает клиентам два варианта.
Первый вариант
Он подойдёт для компаний, которые готовы подключиться к сервису BI.ZONE TDR на переходный период и затем полностью перевести функции сервиса в собственный SOC. За время взаимодействия специалисты заказчика начинают понимать, что они могут получить от центра мониторинга, что выходит за рамки и какие требования к собственному SOC нужно сформулировать.
Параллельно с участием экспертов BI.ZONE TDR определяются целевая архитектура подключения, перечень систем, с которых потенциально возможен и целесообразен сбор событий, а также методы сбора. Появляется понимание того, как команда SOC будет работать с потоком событий и алертов. Всё это в дальнейшем позволит выстроить правильную организационную структуру. Переход платформы SOC и функций от BI.ZONE TDR на сторону клиента происходит поэтапно и без потери качества, по мере появления необходимого персонала у клиента. Процесс миграции сопровождается обучением сотрудников заказчика по разработанным экспертами BI.ZONE TDR программам.
Второй вариант
Он подойдёт для компаний, у которых есть ограничения по доступу к инфраструктуре. Также это вариант для организаций с уже существующим специфичным инструментарием, потребностями в нетипичном SLA и т. д. Консультанты-методологи и архитекторы в рамках услуги BI.ZONE SOC Consulting проводят сбор и анализ данных, которые становятся основой для эскизного и технического проекта будущего SOC. Параллельно проектированию составляется карта процессов и формируется перечень частных процессов SOC. BI.ZONE может оставаться для компании внешним консультантом по сложным кейсам, делиться контентом SOC и информацией о киберугрозах, а также проводить киберучения.
Выводы
Эффективное предотвращение современных киберугроз невозможно без выстроенного мониторинга и реагирования на инциденты. Создание собственного SOC — трудоёмкий и затратный процесс для любой компании. По данным BI.ZONE SOC Consulting, на создание внутреннего центра мониторинга и реагирования в среднем уходит полтора-два года. Пройти этот путь гораздо проще совместно с экспертами, которые имеют обширный опыт работы с разными организациями и учитывают специфику конкретного заказчика.
В таком случае сроки запуска внутреннего SOC сократятся в два-три раза. При этом и финансовые затраты, по подсчётам BI.ZONE, уменьшатся на 25–30 % по сравнению с ситуацией, когда компания строит центр мониторинга своими силами. В дальнейшем, взаимодействуя с экспертами, организация сможет совершенствовать внутренний SOC, поддерживая высокий уровень защищённости инфраструктуры и обеспечивая безопасность бизнес-процессов.
