Несколько SIEM-систем в одной инфраструктуре: когда разделять задачи, а когда объединять функции

Классическая модель построения центра мониторинга ИБ (Security Operations Center, SOC) обычно предполагает наличие одной централизованной системы класса Security Information and Event Management (SIEM-), в которую поступают события ИБ от всех значимых источников ИТ-инфраструктуры. На одной платформе выполняются их сбор, нормализация и корреляция, регистрация инцидентов ИБ и долговременное хранение данных. Это упрощает сопровождение решения и интеграцию с источниками, а также позволяет выстроить единые процессы работы SOC.

На практике крупные организации нередко одновременно эксплуатируют две или даже три SIEM-системы. При этом часть связанных задач можно объединять в одной платформе. Solar SIEM совмещает функции SIEM и SOAR и поддерживает цикл от обнаружения инцидента до автоматизированного реагирования. Почему компаниям все же нужны несколько платформ и когда такая архитектура оправдана – рассмотрим в этом материале.

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

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

Отсюда возникают два основных вопроса:

1. Какие обстоятельства приводят организации к одновременному использованию нескольких SIEM-систем?

2. В каких случаях их совместная работа даёт практический эффект и оправдывает дополнительные технические и организационные затраты?

Как так вышло: типовые причины появления нескольких SIEM-систем

Импортозамещение и поэтапная миграция

Один из распространённых сценариев для российских организаций – переход с зарубежных SIEM-систем на отечественные решения. Компания может внедрять Solar SIEM или другую отечественную платформу, продолжая использовать прежнее решение от зарубежного производителя либо инфраструктуру на базе Elastic Stack.

Одномоментно перейти на новую платформу обычно сложно. За годы эксплуатации в прежней SIEM-системе накапливаются значительные наработки, включая правила нормализации и корреляции, отчёты, пользовательские запросы и фильтры, а также сложные кастомные интеграции. Перенос всей этой экосистемы на новую SIEM-платформу – сложный, местами «болезненный» и длительный процесс, требующий существенных ресурсов.

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

Холдинговая структура, слияния и поглощения

В крупных холдингах отдельные дочерние и зависимые общества (ДЗО) часто развивают собственные центры мониторинга ИБ и используют разные SIEM-системы. После объединения головная организация получает несколько отдельных контуров мониторинга со своими источниками данных, экспертным контентом, процессами и командами аналитиков.

Перевод всех ДЗО на одну SIEM-платформу не всегда экономически и организационно оправдан. У внедрённых систем есть сроки амортизации, а централизованная миграция требует переработки экспертного контента и переобучения персонала. На переходном этапе это может снизить качество мониторинга ИБ.

Кроме того, отдельные ДЗО могут работать в разных регуляторных условиях или находиться на разных уровнях зрелости. SIEM-платформа, рассчитанная, например, на требования к объектам КИИ первой категории значимости или ГИС первого класса защищённости, для части контуров может оказаться избыточной.

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

Намеренное разделение задач

Иногда несколько SIEM-систем закладывают в архитектуру изначально. Такой сценарий встречается в организациях с крупной распределённой ИТ-инфраструктурой, большими объёмами данных и разными требованиями к их обработке.

Например, одна SIEM-система может использоваться для оперативной корреляции событий ИБ и поддержки первой линии SOC, другая – обслуживать сегмент КИИ, технологическую сеть или иной изолированный контур с особыми требованиями к размещению и защите данных. Ещё одна платформа или несколько компонентов могут отвечать за централизованный сбор, предобработку и долговременное хранение данных.

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

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

Такая схема работает, если для каждой платформы заранее определены задача, зона ответственности и правила обмена данными.

Как их поженить: архитектурные модели совместной работы нескольких SIEM-систем

Модель 1. Независимая параллельная обработка

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

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

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

Модель 2. Функциональное разделение на слои

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

Для сбора можно использовать специализированные коллекторы, брокеры сообщений, решения на базе открытого программного обеспечения, отдельные модули Elastic Stack, включая Beats и Logstash, платформы потоковой обработки, например Apache Kafka, а также системы класса Log Management, частично реализующие функции SIEM. Выбор зависит от состава и объёма источников данных, требований к отказоустойчивости, особенностей ИТ-инфраструктуры и уже работающих в ней решений.

Слой сбора может принимать не только традиционные события ИБ. В общий поток входят журналы аудита прикладного ПО и баз данных, сетевая телеметрия NetFlow/IPFIX, фрагменты копии сетевого трафика, системные и диагностические журналы, метрики производительности оборудования и сервисов и другие данные о состоянии ИТ-инфраструктуры.

Собранные данные поступают в централизованное хранилище класса Data Lake или Data Lakehouse либо в staging-слой классического Data Warehouse. Там хранятся исходные данные для ретроспективного анализа, отчётности, смежных ИТ-задач и передачи в SIEM-системы.

В саму SIEM поступают события ИБ и контекстные данные, необходимые для корреляции, сценариев детектирования и регистрации инцидентов. За счёт этого снижаются нагрузка на систему и расходы на лицензирование.

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

Модель 3. Сегментное разделение

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

Такую схему используют крупные холдинги и территориально распределённые организации, где отдельные подразделения имеют собственные центры мониторинга ИБ. Аналогично работают поставщики ИБ-услуг, включая MSSP- и MDR-провайдеров: им необходимо разделять данные разных заказчиков, экспертный контент и процессы реагирования на инциденты.

Зоны ответственности при этом могут распределяться по-разному. Одна SIEM-система, например, отвечает за корпоративную ИТ-инфраструктуру, другая – за сегмент КИИ или технологическую сеть. Часть филиалов, ДЗО или менее критичных систем можно передать на мониторинг внешнему MDR-провайдеру с собственной SIEM-системой.

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

Недостатком подобной архитектуры является необходимость централизованного управления инцидентами и координации процессов мониторинга между различными платформами и командами. Для формирования единой картины состояния ИБ нужно наладить обмен информацией между платформами и договориться об общей классификации. Процесс реагирования между командами тоже должен быть согласован. На практике для этого используют IRP/SOAR-платформы или другие средства централизованного управления инцидентами ИБ.

Когда «больше» равно «лучше»: преимущества многоплатформенной архитектуры

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

· разные компоненты могут отвечать за сбор, хранение и анализ данных, а отдельные SIEM-системы – за свои сегменты инфраструктуры;

· слои сбора, анализа и хранения можно масштабировать независимо друг от друга;

· часть задач сбора и хранения может уже решаться в ИТ-инфраструктуре другими средствами, что снижает нагрузку на SIEM и расходы на её лицензирование;

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

Сложности применения многоплатформенной архитектуры

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

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

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

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

Рекомендации для SIEM-заводчиков

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

· Определить назначение каждой платформы (исключить дублирование функций и заранее распределить роли между компонентами архитектуры).

· Минимизировать дублирование потоков данных (использовать параллельную обработку только при миграции, тестировании или других обоснованных сценариях).

· Разделять функции сбора, анализа и хранения (использовать специализированные решения для каждого слоя).

· Стандартизировать обработку данных: по возможности унифицировать классификацию ИТ/IP-активов, пользователей, событий и инцидентов ИБ, чтобы она не зависела от конкретной SIEM-системы.

· Отдельно нужно решить вопрос централизованного управления инцидентами ИБ, используя соответствующие решения.

· При выборе платформы стоит учитывать и объем экспертного контента, который команде придется создавать и поддерживать самостоятельно. В Solar SIEM уже входит готовый экспертный контент Solar JSOC – правила корреляции, сценарии и индикаторы компрометации.

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

Подведем итоги

Мы рассмотрели три наиболее распространенные модели совместного использования нескольких SIEM-систем, хотя на практике возможны и другие варианты построения многоплатформенной архитектуры.

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

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