Импортозамещение SIEM: что важно учесть
SIEM является одной из основополагающих систем в инфраструктуре организации для обеспечения информационной безопасности. На текущий момент большое число крупных организаций используют SIEM-системы иностранных вендоров. Это связано с тем, что на момент их покупки и внедрения на рынке объективно не было российских решений, которые удовлетворяли бы требованиям пользователей. Однако, сейчас ситуация изменилась. Появилось достаточное количество SIEM-систем отечественного производства, а у российских компаний остро встал вопрос об импортозамещении иностранного ПО.
Потребность в импортозамещении иностранных SIEM систем вызвана следующими основными причинами:
- требования законодательства в части импортозамещения;
- требования регуляторов по использованию отечественного ПО в области информационной безопасности;
- санкции (или возможность таких санкций) со стороны иностранных государств, которые препятствуют поставке и поддержке ПО со стороны производителей;
- уход (или риски ухода) иностранных компаний с российского рынка.
Кроме того, использование ПО иностранных производителей зачастую связано с дополнительными неудобствами, такими как отсутствие поддержки на русском языке, невозможность оперативно добавить новую функцию в ПО по запросу пользователей (feature request), стоимость ПО и поддержки в иностранной валюте (привязана к валютному курсу) и пр.
Трудности, с которыми приходится сталкиваться при импортозамещении SIEM систем
К сожалению, на практике импортозамещение SIEM системы происходит не так просто, как хотелось бы. Это довольно сложный процесс, который может потребовать значительных ресурсов и времени. Для его реализации необходимо решить ряд задач.
- Выбор решения. Нарынке сейчас представлено достаточное количество SIEM систем отечественного производства. Пользователю необходимо выбрать из них ту систему, которая удовлетворит его потребностям и будет соответствовать его возможностям. Система должна иметь необходимый функционал, позволять интегрироваться с существующей ИТ- и ИБ-инфраструктурой. Стоимость владения системой должна соответствовать бюджету заказчика. Для выбора SIEM системы многие организации используют сравнительные таблицы по интересующим их критериям. Однако этого бывает недостаточно, поскольку перечень критериев, как правило, недостаточно исчерпывающий, а описания характеристик систем в таблице носят довольно общий характер. Поэтому пользователи прибегают к пилотному тестированию, которое гораздо более точно позволяет оценить соответствие системы потребностям. Однако проведение качественного тестирование является довольно ресурсоёмким и требующим временных затрат, поэтому протестировать все имеющиеся на рынке SIEM системы получается долго и дорого.
- Архитектура. Архитектура новой SIEM может сильно отличаться от архитектуры используемой системы. Это может привести к значительным изменениям в инфраструктуре организации. К примеру, архитектура новой SIEM может быть значительно более требовательней с точки зрения количества и мощности аппаратных ресурсов.
- Сбор данных. Внедрение новой SIEM системы может привести к необходимости настройки новых механизмов сбора событий для каждого целевого источника, включая их подключение, настройку парсеров и механизмов фильтрации. В крупных организациях источников событий может несколько тысяч.
- Копирование данных. При внедрении новой SIEM системы может потребоваться копирование всех исторических данных из старой. Эта задача не всегда является разрешимой, поскольку информация в старой системе может храниться в закрытом формате. В этих случаях может помочь использование специальных механизмов (специальных типов коннекторов), которые необходимо правильно настроить и протестировать. Кроме того, такое копирование может занять много времени, поскольку это терабайты информации.
- Копирование контента. Помимо копирования «сырых данных», необходимо также перенести весь созданных контент, а это могут быть сотни правил, дашбордов, активных листов, активных каналов и пр. В некоторых случаях даже просто перенести их в новую SIEM систему не получится, так как в ней может использоваться другая логика обработки информации и может быть реализован другой механизм создания ресурсов. В этом случае придётся разрабатывать весь контент заново и, практически, «с нуля».
- Обучение. Интерфейс и логика новой системы могут значительно отличаться от ранее используемой. Тогда сотрудникам, которые годами работали с одной системой, придётся в сжатые сроки научится использовать и обслуживать новую SIEM. Это касается не только операторов и аналитиков, выполняющих отслеживание и расследование инцидентов. Разработчикам ресурсов и администраторам тоже необходимо будет пройти обучение и привыкнуть к новой системе.
На что стоит обратить внимание при выборе SIEM системы
Архитектура SIEM системы
Способ поставки новой SIEM системы
Стоит обратить внимание каким образом поставляется новая SIEM система: в виде ПО или ПАК (программно-аппаратный комплекс). В первом случае необходимо оценить системные требования новой SIEM системы, чтобы выделить ресурсы под инсталляцию, а также узнать возможности развёртывания системы в среде виртуализации, которая используется в компании. Во втором — оценить состав ПАК, чтобы выделить под него место в серверной, а также узнать срок поставки, включая отгрузку производителем и логистику до места использования.
Масштабируемость
Структура крупных организаций часто меняется, происходят изменения филиальной структуры, а также слияния и поглощения компаний. Поэтому при выборе системы SIEM необходимо учитывать возможности её масштабирования по тем направлениям, которые будут актуальны для вашей организации:
- подключение новых источников данных;
- увеличение потока данных;
- увеличение объёмов хранения данных;
- увеличение срока хранения данных;
- увеличение количества специалистов, работающих с системой;
- увеличение количества запросов к системе;
- увеличение количества правил корреляции, которые обрабатывают события;
- внедрение в филиалах собственных SIEM-систем с построением иерархической структуры.
Архитектура системы должна быть такой, чтобы процесс масштабирования по нужным направлениям не вызывал больших трудностей.
Поддержка филиальной структуры предприятия
Если организация имеет филиальную структуру, то может потребоваться мониторинг событий ИБ в филиалах. В этом случае используют следующие подходы.
- Установка в филиалах коннекторов, которые осуществляют сбор событий и отправку их в центральный офис, где установлена SIEM система. Тогда все события хранятся и обрабатываются централизованно.
- Установка в филиалах собственных инсталляций SIEM систем. В этом случае события из филиалов обрабатываются локально, а в SIEM центрального офиса отправляется, как правило, только информация об инцидентах.
Что ставить в филиал, коннектор или SIEM, обычно определяется наличием в филиале собственной SOC команды, которая сможет обрабатывать локальные инциденты ИБ. Если такая команда (состоящая хотя бы из одного специалиста) имеется, то можно рассмотреть вариант с установкой SIEM.
Поток событий
Основной характеристикой производительности SIEM системы является возможность обработки входного потока событий, который зависит от размеров организации и количества подключаемых к SIEM целевых систем. Необходимо выяснить, какое количество событий в секунду (EPS) система способна обрабатывать. При этом нужно различать средние и пиковые значения EPS, которые могут значительно отличаться. Также EPSявляется важным параметром, поскольку часто используется производителями в правилах лицензирования и влияет на стоимость продукта.
Разграничения прав доступа
Если в вашей организации количество пользователей SIEM больше одного человека, то может потребоваться ролевая модель управления пользователями и разграничение прав доступа. Обычно различают роли администраторов, операторов и аналитиков. Также может потребоваться разграничение доступа по типам ресурсам. Например, сотрудник, отвечающий за сетевую безопасность, может видеть только события и инциденты с сетевых устройств. Аналогичным образом настраивается разграничение доступа по филиалам и подразделениям организации.
Сбор и нормализация событий
Способ сбора событий
При выборе новой SIEM системы важную роль играет способ сбора событий с целевых систем. Различают агентский и безагентский способы.
При агентском сборе событий необходимо устанавливать агент (службу сбора событий) на каждой рабочей станции и сервере. Как правило, это может подойти только для небольших организаций, поскольку для крупных компаний «ещё один агент» — это известная проблема, усложняющая жизнь.
При безагентском сборе событий достаточно развернуть один или несколько (зависит от размера организации) серверов коннекторов и/или включить аудит на целевых системах. Такой тип сбора событий намного удобнее в разворачивании и последующем администрировании.
Обеспечение гарантированной доставки событий
Ключевым параметром успешного сбора событий является доставка и сохранение всех событий из целевых источников без потерь. В противном случае (если события теряются) такой системе нет доверия.
В современных SIEM системах используются следующие механизмы гарантированной доставки событий:
- буферизация событий на коннекторах при потере соединения;
- счётчики и контрольные суммы собранных и доставленных событий;
- журналирование и анализ ошибок, возникающих при сборе и доставке событий (например, ошибки парсинга или перегрузка коннекторов);
- проверка регулярности поступления событий с источников;
- использование шин данных, очередей и/или сетевых протоколов гарантированный доставки данных.
Нормализация событий
После успешного сбора событий их необходимо корректно обработать (распарсить) и передать на хранение и дальнейшее использование. В современной SIEM системе инструменты нормализации событий (парсеры) должны иметь возможность быстрой и гибкой настройки без привлечения специалистов вендора.
Наличие коннекторов для ключевых источников событий
Для эффективного эксплуатирования SIEM системы необходимо подключить к ней целевые системы. Поэтому стоит заранее узнать у вендора список целевых систем, с которыми имеется возможность интеграции, и наличие рекомендаций по их настройке.
Хранение событий и инцидентов
После сбора событий в SIEM системе они сохраняются во внутренней базе данных (БД). В зависимости от потребностей вашей организации стоит обратить внимание на следующие параметры используемой БД:
- скорость обработки запросов;
- возможность хранения нормализованных и ненормализованных событий;
- коэффициент сжатия данных при хранении;
- возможности масштабирования и кластеризации;
- аппаратные требования, возможность работать в виртуальной среде или на СХД;
- возможность создания отказоустойчивых конфигураций;
- возможности архивирования данных за истекший период хранения.
Интерфейс пользователя
Основным инструментом работы аналитика и оператора SOC является консоль SIEM системы, которая позволяет просматривать события, выполнять их анализ и расследование инцидентов. При выборе новой SIEM системы следует уделять внимание удобству интерфейса консоли, поскольку от этого напрямую зависит эффективность работы специалистов SOC.
Функционал консоли SIEM системы
Консоль новой SIEM системы должна обладать следующим функционалом:
- наличие средств визуализации событий как:
- активный канал (АК) служит для детального отображения событий в режиме реального времени или за определенный промежуток времени.
- мониторы данных — графический элемент для более удобного отображения событий, чаще всего представляет собой график или диаграмму;
- инструментальные панели (дашборд) — представляет собой несколько дата мониторов, объединённых для мониторинга определенной задачи (например, выполнение требований стандарта PCI DSS);
- отчёты — документы, отражающие состояние информационной безопасности организации по результатам мониторинга.
- наличие механизмов анализа событий:
- конструктор создания правил корреляции событий;
- конструктор создания активных листов, которые используется в правилах корреляции и при составлении отчётов.
Большую часть времени аналитик/оператор проводит за работой с активными каналами и дашбордами, поэтому следующие функции и возможности интерфейса могут оказаться полезными:
- гибкая настройка свойств активного канала (выбор временного диапазона, периода обновления данных, добавление/удаление полей данных);
- возможность написания запросов к данным из окна активного канала (например, с помощью конструктора запросов);
- наличие контекстного поиска по таблице активного канала;
- наличие в активном канале механизмов фильтрации, сортировки и группировки событий, а также наличие функций подведения итогов и подсчёта событий;
- выгрузка данных активного канала в различные форматы;
- конструктор создания дата мониторов и дашбордов;
- гибкая настройка дата мониторов с выбором типа отображения данных, временного диапазона, периода обновления данных;
Также SIEM система должна позволять создавать различного рода отчёты. Для этого будет полезным конструктор создания отчётов, позволяющий создавать шаблоны отчётов и выбирать способы визуализации информации о результатах мониторинга. Далее система должна уметь рассылать сформированные отчёты по электронной почте по расписанию.
Корреляция событий
В настоящее время SIEM системы предлагают 2 способа корреляции событий:
- корреляция в режиме реального времени;
- корреляция «по запросам».
Корреляция в режиме реального времени предполагает срабатывание правил корреляции в момент поступления событий от коннектора в ядро системы. Этот вариант имеет следующие достоинства:
- за счёт срабатывания режиме реального времени, система мгновенно предоставляет информацию о произошедших инцидентах ИБ;
- снижается нагрузка на базу данных.
Вариант работы корреляции «по запросам», в свою очередь, выдаёт данные об инцидентах с задержкой и значительно повышает нагрузку на базу данных за счёт необходимости постоянного выполнения запросов.
В консоли SIEMсистеме должен быть реализован конструктор написания правил для выявления инцидентов ИБ. Дополнительным плюсом будет наличие готовых механизмов переноса правил из одной SIEMсистеме в другую, что значительно сократит время миграции.
Возможность доработки системы под нужды заказчика
Если рассматриваемая система не имеет одной или нескольких требуемых функций, стоит уточнить у вендора возможность и сроки разработки дополнительного функционала системы «под запрос». Возможно окажется, что этот функционал уже запланирован в «roadmap» производителя.
Сценарии импортозамещения (миграции)
В зависимости от решаемых задач и сложившейся ситуации, организация может выбрать один из возможных сценариев миграции на отечественную SIEM систему.
Сценарий 1. «Быстрое» импортозамещение
Этот сценарий предполагает замену иностранной SIEM на новую в кратчайшие сроки. Выполняется копирование всех данных и ресурсов из имеющейся SIEM системы в новую, после чего новая система сразу вводится в промышленную эксплуатацию, а эксплуатация старой системы прекращается.
Плюсы и минусы такого варианта миграции
Плюсы
- быстро выполняются требования по импортозамещению;
- больше нет необходимости тратить ресурсы на эксплуатацию и поддержку старой IEM системы, которую потом все равно придётся выбросить.
Минусы
- необходимость копирования исторических данных;
- сжатые сроки на адаптацию сотрудников для работы с новой системой;
- возможность потери событий в момент перехода с одной системы на другую;
- нет возможности посмотреть исторические данные в интерфейсе старой SIEM.
Данный сценарий миграции на новую SIEM систему является наиболее рискованным и трудозатратным, поэтому есть смысл его использовать только в том случае если эксплуатировать иностранную систему больше нет возможности, например, из-за санкций.
Сценарий 2. «Постепенное» импортозамещение
В данном сценарии новая SIEMсистема разворачивается параллельно с имеющейся SIEM системой. В течение некоторого времени обе системы работают параллельно, при этом данные о событиях ИБ сохраняются в обеих системах. После некоторого периода (к примеру, полгода) старая SIEM система выводится из эксплуатации и остаётся в качестве архивного хранения исторических данных. За время параллельной работы обеих систем в новой SIEM системе накапливаются данные за этот период. Пользователи имеют возможность в течение этого времени обучиться работать в новой системе и протестировать работу перенесённых из старой системы ресурсов, таких как правила корреляции и активные каналы.
Плюсы и минусы такого варианта миграции
Плюсы
- переход на новую систему происходит плавно;
- сотрудники постепенно учатся работать и привыкают к новой системе;
- можно использовать старую SIEM для просмотра исторических данных;
- выполняются требования регуляторов по импортозамещению выбросить.
Минусы
- необходимо поддерживать в рабочем состоянии 2 системы в течение некоторого периода времени.
Данный сценарий миграции на новую SIEM систему видится наиболее подходящим для большинства пользователей, так как позволяет постепенно перейти на новую систему без риска потери данных и даёт возможность сотрудникам без стресса начать работать с новой системой.
Сценарий 3. Параллельная работа двух SIEM систем
В данном сценарии новая система разворачивается параллельно с имеющейся SIEM системой. Этот сценарий имеет смысл в том случае, когда эксплуатация существующей SIEM системы может быть продолжена, но не может быть расширена для решения новых задач, например, для подключения дополнительных источников событий. Тогда для мониторинга новых систем можно использовать инсталляцию новой системы (если она обладает такими возможностями). Одним из достоинств такой архитектуры является возможность новой SIEM производить мониторинг работоспособности используемой иностранной SIEM системы, что может быть критично, например, при отсутствии технической поддержки со стороны вендора.
Плюсы и минусы такого варианта миграции
Плюсы
- продолжение использования существующей системы;
- выполняются требования регуляторов по импортозамещению.
Минусы
- увеличивается нагрузка на сотрудников, т.к. необходимо поддерживать в рабочем состоянии 2 системы.
Данный сценарий миграции имеет смысл, когда эксплуатация существующей иностранной SIEM системы может быть продолжена. Недостатком является необходимость использовать и обслуживать две SIEM системы.
Итоги
Подводя итог хочется сказать, что разумным подходом при импортозамещении SIEM системы будет подготовка конкретного списка требований к новой системе в целом, а также к её функционалу. При этом можно опираться на практику использования существующей импортной системы. Например, проверить, что новая система реализует те же возможности, что сейчас используются в старой. Полезным будет разделить требования на обязательные (необходимые) и желаемые. А также решить какой сценарий импортозамещения следует использовать в конкретном случае исходя из имеющихся условий и возможностей.
Авторы статьи: Ульяна Кочеткова, руководитель проектов «АТБ», Михаил Хлестов, генеральный директор ООО «САВРУС»
Полный текст статьи читайте на CNews