Prelude SIEM

Проект появился в 1998 году, когда автор начал разработку собственной системы обнаружения вторжений для Unix-подобных сред^[1]. Замысел опередил сложившуюся терминологию: вместо единственного детектора автор предложил шину событий, к которой подключаются любые средства защиты, — идея, которую позднее оформили в классе систем управления событиями безопасности^[4]. Первые годы проект развивался в форме открытой разработки: появились библиотека libprelude, менеджер событий и анализатор журналов Prelude-LML, а в 2002—2003 годах к ним добавились веб-консоль Prewikka и коррелятор^[5]. Имя проекта — «Prelude» — закрепилось за всей платформой: компоненты получили приставку, а консоль сохранила собственное историческое название.

Для сопровождения проекта была создана компания PreludeIDS Technologies; в начале 2010-х годов она объединилась с разработчиком системы мониторинга Vigilo, и проект перешёл под крыло французской компании CS GROUP^[1]. В этот период система позиционировалась в двух редакциях: открытая Prelude OSS для оценки и небольших внедрений и коммерческая Prelude SIEM с расширенными характеристиками производительности^[1]. Разработка открытой редакции продолжается: выпуски компонентов относятся к ветке 5.2, а система входит в официальные репозитории распространённых дистрибутивов — Fedora, RedHat, CentOS, Debian, Ubuntu, Mageia, Arch Linux и openSUSE^[6]. Собственные страницы выпусков ведутся для каждого компонента: консоли^[7], библиотеки^[8] и анализатора журналов^[9]. Путь от детектора к платформе повторяет эволюцию всего направления. Ранняя литература описывала обнаружение вторжений как задачу распознавания следа атаки в потоке событий, а позднейшие работы свели её к задаче управления этими потоками — сбора, хранения и осмысленного сопоставления^[10]. Prelude среди немногих проектов прошёл этот путь целиком, сохранив и историческую совместимость с наследованными детекторами, и развитие современных компонентов^[1].

Система построена по классической схеме «сенсоры — коллектор — консоль». Источники событий подключаются через библиотеку libprelude, которая обслуживает соединения с коллектором, повторное подключение при отказе и асинхронную отправку сообщений; библиотека избавляет разработчиков сенсоров от забот о передаче и оформлении событий^[11]. Коллектор prelude-manager принимает защищённые соединения от распределённых сенсоров и других менеджеров и сохраняет полученные события в выбранный администратором носитель — базу данных, журнал или почтовую очередь^[3]. Соединения между компонентами защищены: сенсоры подключаются к менеджеру через аутентификацию сторон, и подлинность сторон подтверждается криптографическими сертификатами, что делает возможным сбор событий через недоверенные сети^[3]. Все события при передаче получают общую структуру, поэтому замена конкретного детектора на другой не требует перестройки приёмной стороны: менеджер и консоль работают с унифицированным потоком^[11].

Консоль Prewikka

Веб-консоль Prewikka была написана Markus Alkio и Miika Keskinen, переписана и поддержана командой проекта и быстро стала штатным интерфейсом системы^[5]. Консоль работает как приложение поверх веб-сервера и доступна из браузера по HTTP. Консоль предоставляет контекстную фильтрацию, агрегацию событий, просмотр приоритетов и свойства инцидентов, а также подключение расширений — приложений, добавляющих отчёты и представления^[5]. Для оператора консоль является главной точкой работы: отсюда запускается разбор инцидента, отбор событий по источникам и адресатам, просмотр хода корреляции^[10].

Библиотека libprelude — несущая конструкция всей системы: она даёт разработчикам сенсоров готовый каркас, устраняя повторение одинаковой работы в каждом средстве защиты^[11]. Библиотека ведёт список менеджеров и переключается между ними, если все настроенные узлы недоступны, а при восстановлении связи выполняет повторное подключение автоматически^[11]. Отправка сообщений асинхронна: сенсор не блокируется даже при задержках в сети и продолжает работу, пока библиотека доставляет события^[11]. В комплект входят также универсальный прикладной интерфейс конфигурации, объединяющий параметры командной строки, файла настроек и регистрационных значений, и средства работы с подпиской пользователей — типовыми подписчиками событий в системе^[11].

Написанная на языке Си, библиотека служит основой для привязок к другим языкам, благодаря чему сенсоры системы создавались на Perl и Python^[11]. Предохранительные механизмы на стороне библиотеки отвечают и за достоверность: сообщения снабжаются служебными сведениями, позволяющими менеджеру отличить источники и оценить полноту потока событий^[11]. В документации проекта подчёркивается, что именно библиотечный подход сделал экосистему Prelude расширяемой: новое средство защиты подключается к шине событий без переделки самой системы^[11]. Отдельное значение имеет отказоустойчивость на стороне источника: сенсор с библиотекой не теряет события при кратковременной недоступности менеджера, а переключение на резервный узел происходит без участия администратора^[11]. Асинхронный интерфейс сообщений и асинхронные таймеры дают сенсорам возможность продолжать собственную работу, пока доставка выполняется в фоне, что принципиально для средств защиты, работающих на скорости сети^[11]. Конфигурационный интерфейс библиотеки унифицирует параметры: одинаковые настройки соединения читаются из командной строки, файла и окружения, что упрощает типовые сценарии развёртывания^[11].

Единый формат обмена сообщениями — «Intrusion Detection Message Exchange Format» — был создан рабочей группой IETF при участии команды Prelude и опубликован как документ RFC 4765 в 2007 году^[2]. Формат описывает XML-модель сообщения об обнаружении: идентификаторы, классификация, время, источники и цели атаки, оценка серьёзности и дополнительные данные^[2]. Стандарт возник из практической потребности: детекторы разных производителей выдавали оповещения в собственных форматах, и сопоставление их друг с другом оставалось ручной работой^[4].

В Prelude формат выполняет роль общего языка: все события, независимо от происхождения — от сетевого детектора, из системного журнала или от антивируса, — нормализуются к IDMEF прежде, чем попадут в менеджер и коррелятор^[1]. Спецификация определяет и понятие цели сообщения — сервиса, на который направлена атака, и понятие узла-источника, что позволяет коррелятору связывать события по общим участникам^[2]. Хотя рабочая группа IETF завершила работу, формат остаётся фактическим средством обмена оповещениями для систем класса Prelude и описан в учебной литературе по обнаружению вторжений как эталонная модель сообщения^[13]. Спецификация различает два типа сообщений: собственно оповещение об обнаружении и «сердцебиение» — периодическое свидетельство работоспособности источника, по отсутствию которого приёмник судит о молчащем сенсоре^[2]. Такое разделение позволило системе отслеживать не только атаки, но и здоровье самой инфраструктуры мониторинга: отключившийся детектор — событие не менее важное, чем обнаруженная атака, поскольку делает оператора слепым^[2]. Учебные руководства используют эту модель при объяснении устройства систем обнаружения: поля сообщения задают структуру разбора инцидента — от классификации к источникам и целям^[13].

Принцип «без агентов» определяет отношение системы к источникам: Prelude не устанавливает собственное ПО на наблюдаемые машины, а принимает события от уже работающих средств^[1]. Штатная поддержка заявлена для детектора Snort, средства контроля целостности Samhain, системы OSSEC, аудита ядра auditd, детектора Suricata, беспроводного анализатора Kismet и антивируса ClamAV. Журналы системного уровня собираются анализатором Prelude-LML из файлов и по сети — через UDP-приём syslog-сообщений^[1][15].

Анализатор журналов закрывает класс источников, который не выдаёт структурированных оповещений: он разбирает записи файлов и потоки syslog, применяет набор правил на регулярных выражениях и превращает подозрительные записи в события IDMEF^[15]. Задача распознавания следов подбора паролей, необычных вызовов, сканирования портов средствами вроде nmap-подобных утилит решается именно на этом слое^[16]. Для сетевого слоя важен и анализ пакетов: литература по анализу трафика описывает те же приёмы разборки протоколов, на которых строятся правила детекторов, питающих систему^[17]. Разнообразие источников — принципиальное требование к системе класса: ограничение одним типом детекторов оставляет аналитика слепым к целым классам нападений, видимым лишь в журналах или лишь в сетевом трафике^[10]. Поэтому перечень штатно поддерживаемых сенсоров покрывает уровни от сети до прикладных программ, а для прочих средств остаётся универсальный путь через журналы и syslog^[1]. Практические руководства по мониторингу оценивают сбор данных как первый и самый трудоёмкий этап построения наблюдения: без устойчивого потока событий от всех значимых узлов дальнейшие слои анализа не имеют материала^[14].

Типовое развёртывание начинается с установки менеджера и выбранной базы данных, затем подключаются сенсоры и настраивается консоль^[5]. В распространённых дистрибутивах компоненты доступны пакетами, что упрощает сопровождение: обновления системы приходят вместе с обновлениями дистрибутива^[1]. Для отказоустойчивости используется свойство менеджера принимать соединения от нижестоящих узлов: два менеджера образуют пару, и библиотека сенсора переключается на резервный при недоступности основного^[3][11]. Такая доступность исторически сыграла роль в распространении проекта: администраторы знакомились с системой через знакомый пакетный механизм, без сборки из исходного кода.

При планировании внедрения система позиционируется отдельно для малых сред и для промышленных нагрузок: открытая редакция предназначена для оценки, исследований и небольших развёртываний, тогда как коммерческая редакция обещает существенно большие характеристики производительности^[1]. Руководства по построению защиты периметра описывают типовую топологию такого класса: детекторы в демилитаризованной зоне и на периметре сети, приёмники журналов на серверах, консоль оператора во внутреннем сегменте^[18]. Prelude укладывается в эту схему: распределение ролей между компонентами соответствует классическим рекомендациям, а иерархия менеджеров позволяет масштабировать сбор^[18]. Планирование производительности опирается на свойства менеджера: расчётное число одновременных подключений, средний поток событий и глубину хранения выбирают по размеру наблюдаемой инфраструктуры^[3]. Руководства по внедрению систем класса подчёркивают организационную сторону: ещё до первой установки следует определить перечень собираемых журналов, ответственных за разбор оповещений и формы отчётности, иначе система превращается в склад данных без владельца^[10]. Опыт обучения специалистов показывает, что работа с реальным потоком событий — с его шумом, пропусками и ложными срабатываниями — составляет необходимую часть подготовки аналитика^[14].

Класс систем управления событиями безопасности сформировался из слияния двух потоков: средств обнаружения вторжений, порождающих оповещения, и средств управления журналами, собирающих учётные записи о работе систем^[10]. Прикладной задачей класса названо централизованное представление всей картины безопасности: собирать, нормализовать, сортировать, агрегировать, коррелировать и предоставлять отчёты по всем событиям, независимо от производителя породивших их средств^[1]. Методология мониторинга предполагает, что данные собираются не ради хранения: центральная фигура процесса — аналитик, который по последовательности событий распознаёт ход атаки и восстанавливает её сценарий^[14].

Prelude занимает в этом классе место раннего открытого воплощения идеи: заявленный набор функций — сбор, нормализация, сортировка, агрегация, корреляция и отчёты — совпадает с каноническим перечнем функций систем управления событиями^[1][10]. Отечественные исследователи, формулировавшие задачи разработки систем мониторинга событий информационной безопасности, описывали те же требования — полнота охвата источников, единое представление, возможность автоматической обработки. Традиционные методы обработки данных контроля параметров инфраструктуры, отмечали они, отстают от потребностей практики^[19]. Те же исследователи видели перспективу в автоматизации самого анализа: в качестве основы для разработки систем мониторинга событий информационной безопасности предлагались нейросетевые системы, способные улавливать закономерности, плохо описываемые ручными правилами^[19]. Открытая архитектура Prelude с программируемым коррелятором оставляла место таким расширениям: новый метод анализа подключается как дополнительный слой обработки событий, не ломая существующий поток^[12].

Слой корреляции выделяет из потока событий связанные последовательности: одиночное оповещение детектора редко говорит о реальном нападении, тогда как серия связанных оповещений от разных средств говорит уже уверенно^[13]. В Prelude-Correlator правила корреляции оформлены на мощном языке программирования, что позволяет описывать сценарии любой сложности — от простых порогов до многоходовых цепочек, связывающих сетевое оповещение с записью журнала и изменением целостности файла^[12]. Результат корреляции возвращается в общий поток как новое событие повышенного приоритета и попадает в консоль оператора^[12].

Конечная цель корреляции — сокращение времени реагирования. Исследователи систем реагирования на инциденты подчёркивают, что эффективность реагирования определяется способностью быстро локализовать инцидент и выполнить заранее заданные действия, а для этого нужен автоматизированный контур: база знаний сценариев угроз и уязвимостей, связанная с механизмами обнаружения^[20]. Коррелятор Prelude в этом контуре занимает место поставщика распознанных сценариев: его события используются как триггеры процедур реагирования, а детализация IDMEF-сообщений — как исходные данные для разбора^[2][12].

Из систем того же класса Prelude чаще всего сопоставляют с OSSIM и Wazuh: обе также распространяются свободно и объединяют сбор событий с корреляцией^[1]. Различия лежат в акцентах. Prelude исторически вырос из детектора вторжений и строится вокруг единого формата оповещений IDMEF, тогда как системы следующего поколения делают упор на собственных агентах и интеграции с экосистемой правил^[10]. Режим «без агентов» остаётся визитной карточкой Prelude: там, где установка агентов невозможна — на сетевом оборудовании, на чужих серверах, в межевом сегменте, — сбор через журналы и syslog остаётся единственным доступным способом^[1].

По отношению к детекторам Prelude выступает не соперником, а объединяющим слоем: сетевой детектор Snort, средства аудита и контроля целостности сохраняют самостоятельность и лишь отдают системе свои оповещения^[1]. Детектор класса Snort описан в литературе как типовой сенсор периметра: набор правил сигнатурного обнаружения, вывод оповещений в унифицированном виде, интеграция с приёмниками^[21]. Задача Prelude — свести оповещения этих сенсоров в единую картину и снять с аналитика работу по ручному сопоставлению^[10]. Выбор между системами класса определяют три вопроса: наличие агентов на наблюдаемых машинах, принятый формат обмена оповещениями и гибкость корреляции^[10]. Prelude отвечает на них характерно: агентов нет, формат — международный IDMEF, корреляция программируется на универсальном языке, что даёт преимущество в разнородных средах с большим числом унаследованных средств^[1][12]. Для сред, построенных на современных агентах и облачных сервисах, сравнение может склоняться в сторону альтернативных систем, и проект честно обозначает целевую нишу открытой редакции — оценка и небольшие развёртывания^[1].

Открытая редакция имеет заявленные рамки: официальная страница проекта прямо предупреждает, что характеристики производительности Prelude OSS заметно ниже коммерческой редакции, и предназначение открытой версии — оценка, исследования и небольшие среды^[1]. Консоль Prewikka выпадает из пакетов части дистрибутивов, что вынуждает администраторов собирать её отдельно^[1]. Формат IDMEF, будучи историческим достижением проекта, остался вне практического стандарта: рабочая группа IETF завершила деятельность, документ имеет статус экспериментального, и современные системы чаще применяют собственные схемы обмена^[2].

Сторонняя критика систем класса затрагивает и Prelude. Опыт внедрений показывает, что стоимость владения определяется не лицензией, а настройкой: без проработанных правил корреляции система выдаёт поток низкоприоритетных оповещений, в котором реальная атака теряется^[10]. Литература по мониторингу предостерегает и от обратной крайности — попытки автоматизировать реагирование до того, как отлажен сбор и проверка достоверности событий^[14]. Наконец, инфраструктура проекта чувствительна к устойчивости сопровождения: официальные сайты проекта в отдельные периоды оказывались недоступны, и документацию приходилось искать в архивах и репозиториях исходного кода^[1]. Достоверность картины зависит и от самих источников: журналы с неоднородными форматами, узлы с несинхронизированным временем и периодически молчащие сенсоры искажают последовательность событий, а вместе с ней — и выводы корреляции^[14]. Поэтому наладка источников — сверка часов, нормализация форматов, контроль «сердцебиения» сенсоров — рассматривается в литературе как обязательный этап, без которого даже правильно установленная система показывает искажённую картину^[2][10].