Введение

Построение собственного SOC (Security Operations Center, центр мониторинга и оперативного реагирования на инциденты ИБ) – масштабный проект для любой организации. Первоначальный этап планирования – это фундамент, от которого зависит, насколько четко будет работать механизм идентификации и реагирования на инциденты ИБ.

Основываясь на практическом опыте создания собственного коммерческого SOC (Angara Cyber Resilience Center, ACRC), строительства SOC у наших заказчиков, а также на международных методологиях и практиках, мы расскажем о первых важнейших шагах, которые необходимо выполнить в начале процесса построения SOC.

On-premise или out-source

Первый, пусть и очевидный, но немаловажный шаг – это определить, какой SOC будет в вашей организации: так называемый on-premise (построенный внутри организации), out-source (по сути облачный, находящийся за пределами организации) или гибридный (когда в зависимости от потребностей компания формирует собственную, уникальную модель SOC, в которой часть ролей и часть функционала берет на себя партнер-интегратор – по модели подписки MDRS, а часть реализуется собственными силами и средствами).

Как правило, свои центры мониторинга строят организации, которые обладают большими ИТ- и ИБ-ресурсами, сильными компетенциями и по ряду причин не готовы отдавать данный вид работ внешним провайдерам (например, в случае наличия ряда внешних регуляторных ограничений или внутренних политик). Аутсорсинг услуг SOC выбирают компании, которым нужен результат здесь и сейчас и у которых нет необходимости оставлять этот пласт работ внутри своего периметра. Гибридная модель позволяет максимально выгодно сочетать услуги аутсорсерса с функциями собственных подразделений.

За такой моделью – будущее, поскольку этот формат подразумевает наиболее оптимальное использование ресурсов, финансовых и трудовых. Однако она же требует определенного уровня зрелости как со стороны систем ИБ самого заказчика, так и со стороны функциональных возможностей интегратора-партнера. На сегодняшний день услуги в формате MDRS на российском рынке оказывают единичные компании, среди которых группа компаний Angara. Существуют различные методики оценки необходимого варианта SOC, и их результаты будут сильно зависеть от специфики и целей каждой конкретной организации. В данной статье будет рассмотрен SOC on-premise, поскольку именно такая модель наиболее сложна в реализации и традиционно вызывает много вопросов у наших заказчиков.

Организационная модель

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

Команда безопасности. Отсутствует отдельное структурное подразделение по обнаружению или реагированию на инциденты ИБ. В случае возникновения инцидента ИБ, собираются заранее определенные ресурсы (зачастую из различных подразделений, включая ИТ) для решения проблемы, восстановления работоспособности систем, после чего команда прекращает свою работу.

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

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

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

Гибридная модель – всегда находится в одном из логических промежутков между этими четырьмя моделями.

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

Основные задачи SOC

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

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

Другие компании (обычно это касается представителей ИТ-зависимых отраслей), успешно пройдя этапы целеполагания и определения предпосылок к созданию собственного SOC, не хотят ограничиваться выполнением регуляторных требований и развивают SOC, повышая зрелость как команды, так и всех используемых в SOC процессов и технологий.

Определяем полномочия

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

• Нет полномочий (например, любые решения SOC, или ИБ в целом, предварительно согласовывает ИТ как главенствующая организационная единица);

• Разделяемые полномочия (по части заранее определенных и согласованных операций и процедур для определенного перечня объектов информационной инфраструктуры SOC вправе выполнять действия по реагированию или внесению изменений без каких-либо согласований);

• Полные полномочия (любая операция или процедура в отношении любого объекта информационной инфраструктуры, которую необходимо выполнить на основании результатов работы SOC, выполняется без промедлений и согласований).

Важно отметить, что полномочия SOC никогда не являются и не должны являться абсолютными, даже если SOC имеет «полный авторитет» в рамках какой-либо сферы своей деятельности. Официальные полномочия SOC следует использовать до определенной границы, после которой SOC должен использовать скорее влияние, чем требования, и обязательно прислушиваться к владельцам защищаемых информационных систем и data custodian (в терминологии (ISC)2).

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

Услуги SOC

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

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

Оценка рисков и «SOC-дзен»

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

Обладая даже частью всех этих знаний, можно достичь критически важного для SOC состояния – состояния так называемой ситуационной осведомленности. Это знания о своей информационной инфраструктуре (сети), понимание наиболее значимых и ценных ее частей, особенностей их взаимодействия и преследуемых целях.

Определившись с перечисленными шагами, которые необходимо предпринять в начале построения центра мониторинга, а также достигнув «SOCдзена», или состояния ситуационной осведомленности, заказчик сможет прийти к лучшему понимаю целевой структуры будущего SOC. Это сделает конечную цель более четкой, а значит, и более достижимой.

Источник: Журнал «Директор по безопасности»