Крупные компании нередко используют несколько SIEM-систем одновременно. Разбираемся, почему возникает такая архитектура, как распределить роли между платформами и в каких случаях разделение функций оправдывает дополнительные затраты.
- 1. Введение
- 2. Как так вышло: типовые причины появления нескольких SIEM-систем
- 3. Как их поженить: архитектурные модели совместной работы нескольких SIEM-систем
- 4. Когда «больше» равно «лучше»: преимущества многоплатформенной архитектуры
- 5. Сложности применения многоплатформенной архитектуры
- 6. Рекомендации для SIEM-заводчиков
- 7. Выводы
Введение
Классическая модель построения центра мониторинга ИБ (Security Operations Center, SOC) обычно предполагает наличие одной централизованной системы класса Security Information and Event Management (SIEM), в которую поступают события ИБ от всех значимых источников ИТ-инфраструктуры. На одной платформе выполняются их сбор, нормализация и корреляция, регистрация инцидентов ИБ и долговременное хранение данных. Это упрощает сопровождение решения и интеграцию с источниками, а также позволяет выстроить единые процессы работы SOC.
На практике крупные организации нередко одновременно эксплуатируют две или даже три SIEM-системы. При этом часть связанных задач можно объединять в одной платформе. Solar SIEM совмещает функции SIEM и SOAR и поддерживает цикл от обнаружения инцидента до автоматизированного реагирования. В материале рассмотрим, почему компаниям всё же нужно несколько платформ и когда такая архитектура оправдана.
Причины появления нескольких SIEM-систем в одной инфраструктуре могут быть как вынужденными, так и осознанными. К первым относятся историческое развитие ИТ-инфраструктуры, импортозамещение, слияние компаний и невозможность быстро отказаться от ранее внедрённого решения. Во втором случае роли между платформами распределяют изначально.
Эффективность такой архитектуры зависит прежде всего от того, как распределены эти роли. Без общего архитектурного замысла несколько платформ приводят к дублированию данных, корреляционных правил и инцидентов ИБ, усложняют сопровождение и увеличивают стоимость эксплуатации. При грамотном распределении задач SIEM-системы могут дополнять друг друга и формировать более гибкую архитектуру.
Отсюда возникают два основных вопроса:
- Какие обстоятельства приводят организации к одновременному использованию нескольких SIEM-систем?
- В каких случаях их совместная работа даёт практический эффект и оправдывает дополнительные технические и организационные затраты?
Эти вопросы стоит рассматривать вместе: причины появления нескольких SIEM-систем определяют подходящую модель их взаимодействия. Сначала разберём основные сценарии, а затем — способы распределения функций между платформами.
Как так вышло: типовые причины появления нескольких SIEM-систем
Несколько 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-заводчиков
При проектировании многоплатформенной архитектуры целесообразно придерживаться следующих принципов:
- определить назначение каждой платформы, исключить дублирование функций и заранее распределить роли между компонентами архитектуры;
- минимизировать дублирование потоков данных и использовать параллельную обработку только при миграции, тестировании или в других обоснованных сценариях;
- разделить функции сбора, анализа и хранения данных между специализированными решениями;
- по возможности унифицировать классификацию ИТ- и ИБ-активов, пользователей, событий и инцидентов ИБ, чтобы она не зависела от конкретной SIEM-системы;
- предусмотреть централизованное управление инцидентами ИБ с помощью соответствующих решений;
- учитывать объём экспертного контента, который команде придётся создавать и поддерживать самостоятельно. В Solar SIEM готовый экспертный контент Solar JSOC — правила корреляции, сценарии и индикаторы компрометации — входит в поставку;
- проектировать архитектуру с учётом дальнейшего развития и масштабирования, чтобы подключение новых источников данных, сегментов, филиалов и платформ не требовало перестройки всей системы.
Главный принцип — каждая новая платформа должна решать конкретную задачу. Если её роль нельзя чётко сформулировать, добавление ещё одной системы, скорее всего, только усложнит архитектуру.
Выводы
Мы рассмотрели три наиболее распространённые модели совместного использования нескольких SIEM-систем, хотя на практике возможны и другие варианты построения многоплатформенной архитектуры.
Использование нескольких SIEM-систем оправдано, если у каждой платформы есть своя задача и понятное место в общей системе мониторинга ИБ. Если системы дублируют друг друга, организация получает рост стоимости владения и усложнение эксплуатации без заметного повышения эффективности мониторинга ИБ.
При проектировании системы мониторинга ИБ важно заранее определить роль каждой платформы, её зону ответственности и правила взаимодействия с другими компонентами. Там, где функции тесно связаны, их объединение в одной платформе сокращает число интеграций и упрощает сопровождение. По этой логике построен Solar SIEM: функции SIEM и SOAR объединены в одном решении, а многоплатформенная архитектура остаётся оправданной для задач, которые действительно требуют разделения по сегментам, ролям или слоям.
Статья подготовлена при участии руководителя группы архитектуры Solar JSOC Александра Кузнецова.
