TS Solution
TS Solution
Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪
Настройки cookie
Обязательные cookies
Эти файлы cookie необходимы для того, чтобы вы могли пользоваться сайтом и его функциями. Их нельзя отключить. Они устанавливаются в ответ на ваши запросы, такие как настройка ваших предпочтений конфиденциальности, вход в систему или заполнение форм.
Аналитические cookies
Disabled
Эти файлы cookie собирают информацию, чтобы помочь нам понять, как используются наши веб-сайты или насколько эффективны наши маркетинговые кампании, или чтобы помочь нам настроить наши веб-сайты для вас.
Рекламные cookies
Disabled
Эти файлы cookie предоставляют рекламным компаниям информацию о вашей активности в Интернете, чтобы помочь им предоставлять вам более релевантную онлайн-рекламу или ограничивать количество показов рекламы. Эта информация может быть передана другим рекламным компаниям.
2 декабря 2021

История развития RuSIEM

С чего все начиналось?

Любая ИТ-система создается с какой-то целью. Одни системы начинаются с идеи, другие — с желания проверить определенную гипотезу. Некоторые решения создаются с целью заработка или исходя из текущих потребностей клиента/клиентов или рынка.

Система RuSIEM появилась примерно по этому же принципу. Первому заказчику компании нужно было иметь возможность управлять событиями информационной безопасности. Это был 2014 год, когда были введены санкции против России. Почти все производители SIEM, представленных тогда в России, были из США, и при малейшем сомнении отказывали интеграторам в поставке. Также произошло и с заказчиком компании RuSIEM. Он обратился к нам, мы предложили решение на базе связки open source решений класса Log management (предназначенных для сбора событий, хранения и навигации по ним), известных как ELK (Elasticsearch-Logstash-Kibana).

Однако решение имело много минусов:

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

  • в качестве операционной системы — модифицированная Ubuntu Server 14, оптимизированная под высокую нагрузку и производительность;
  • для сбора событий — модифицированный и расширенный новыми модулями logstash базовой версии 1.4.2;
  • коллекторы для сбора и понимания поступающих событий — собственная разработка на базе logstash версий 1.2–1.4;
  • в качестве оперативного хранилищ данных — Elasticsearch 0.9;
  • в качестве брокера, соединяющего компоненты, — собственная разработка;
  • веб-сервер: Аpache 2.x или Ngnix 1.4;
  • веб-интерфейс построен на модифицированной Kibana 3;
  • для выборки событий в интерфейсе использовался язык Luciene, позволяющий осуществлять поиск по хранилищу с гибкими условиями с использованием синтаксиса, понятного оператору;
  • для долгосрочного хранения и полнотекстового поиска используется NoSQL, хранилище Hadoop, поиск по которому также доступен из веб-интерфейса;
  • в качестве агента для Windows и Linux-систем — NXLog Community Edition версии 2.8;
  • форвардер, принимающий на себя тяжелые, затратные по быстродействию операции по разбору событий, по набору компонент аналогичен управляющему серверу.

Результат

В результате мы получили решение со следующими характеристиками:

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

Описание компонентов полученного решения

В состав средств обеспечения сбора и обработки событий входит ряд важных компонентов.

1. Управляющий сервер — базовый компонент (выделенный сервер), предназначенный для сбора, нормализации, автоматического обогащения событий дополнительной полезной информацией, хранения и обработки событий с целевых систем. Управляющий сервер устанавливается на модифицированную open source операционную систему Ubuntu Server.

2. Хранилище данных — компонент, предназначенный для хранения событий и сопутствующих данных. Хранилище данных включает в себя несколько разновидностей NoSQL open source баз данных. Физически по умолчанию располагается на управляющем сервере, но как компонент может быть вынесен на выделенный сервер в составе одного или нескольких кластеров для обеспечения масштабируемости и увеличения производительности системы. Количество разнесенных нод не ограничивается.

3. Веб-сервер. Физически располагается на управляющем сервере, но для увеличения производительности может быть вынесен на выделенный сервер вместе с базой данных. Посредством защищенного протокола HTTPS веб-сервер предоставляет консоль для управления, навигации по событиям, выгрузки событий и построения отчетов.

4. Агент для операционной системы Windows — компонент, выполненный в виде инсталляционного пакета, устанавливаемого на конечную операционную систему для локального сбора событий из Windows EventLog.

5. Коллекторы для пассивного сбора событий (сетевые файловые и т. п.) — компонент для сбора событий. Физически располагаются на управляющем сервере или на форвардере. Коллекторы отвечают за понимание принимаемого формата событий, их нормализацию и обработку событий.

6. Форвардер (выделенный сервер) — компонент, устанавливаемый только при необходимости масштабирования системы, увеличения производительности, обеспечения работы на медленных каналах связи. Основная его роль — сбор и предварительная обработка событий (нормализация, классификация, категоризация).

7. Клиентские средства АРМ операторов системы с установленным веб-браузером.

Рисунок 1. Структурная схема

Что было дальше?

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

Все последующие годы мы дорабатывали систему, почти каждый месяц внося в нее большое количество изменений. Мы зарегистрировали компанию и включили систему в реестр отечественного ПО, стали резидентом «Сколково», получили сертификат ФСТЭК России, в результате чего колоссально вырос объем клиентской базы.

Система перешла с Ubuntu 14 на поддерживаемые версии, мы создали ее бесплатную версию и разработали модуль аналитики для платной. Разработали собственную шину данных, парсеры и коннекторы, отказались от Hadoop и провели большое количество других существенных изменений.
Рисунок 2. Текущая архитектура SIEM-системы RuSIEM.

Историческая справка

Давайте посмотрим более детально историю развития RuSIEM
2014
2014
Самое начало пути
Создание продукта, найм разработчиков.
02.02.2015
02.02.2015
Анонс функциональности первой коробочной версии
Первая коробочная версия включаючает базовый функционал SIEM-решения. Начало проработки корреляции.
16.02.2015
16.02.2015
Первая партия ключей для пилотных проектов
23.03.2015
23.03.2015
Реалтайм и историческая корреляция
10.06.2015
10.06.2015
Появление симптоматики
25.12.2015
25.12.2015
Появление Workflow и улучшение работы с инцидентами
05.03.2016
05.03.2016
Появление взаимосвязей
21.04.2016
21.04.2016
Появление отчетов
24.06.2016
24.06.2016
Появление модуля аналитики, который стал важным моментом в развитии продукта
15.03.2017
15.03.2017
Появление мультиязычности
17.04.2017
17.04.2017
Появление бесплатной версии продукта
15.06.2017
15.06.2017
Появление собственной шины RuSIEM MQ
14.07.2017
14.07.2017
Переход с influxdb на БД разработки Яндекс — ClickHouse
15.08.2017
15.08.2017
RuSIEM включена в реестр российского ПО
Приказ Минкомсвязи РФ от 15.08.2017 № 421, Приложение 1, № пп. 25, реестровый № 3808.
19.01.2018
19.01.2018
Обновление API и возможность управления всеми нодами удаленно, с единого интерфейса
21.02.2019
21.02.2019
Возможность создавать собственные парсеры и подключать любой источник самостоятельно
04.05.2020
04.05.2020
Поддержка Ubuntu 18
23.11.2020
23.11.2020
Функционал мониторинга внутренних микросервисов системы, функционал подключения подчиненных серверов
26.11.2020
26.11.2020
Возможность ручного обновления системы, в дополнение к автоматическому
20.12.2020
20.12.2020
Закончена полноценная интеграция c R-Vision
Контроль целостности компонентов систем, а также произведена оптимизация работы систем под Ubuntu18. Реализована привязка событий к инцидентам: теперь событие является частью сущности инцидента и время хранения события на них не распространяется, инциденты хранятся неограниченное время.
12.02.2021
12.02.2021
Переработаны корневые сервисы RuSIEM
Оптимизирован поиск по событиям, оптимизирована аналитика, сильно уменьшено требование к ресурсам для ее работы. Система интегрирована с FinCERT, произведена оптимизация ядра и функций корреляций, добавлена статистика по скорости работы корреляции.
15.03.2021
15.03.2021
Добавлена статистика по парсерам, статистика по отработке корреляции
Модуль RuSIEM IоС, позволяющий работать с индикаторами компрометации RuSIEM. В списки добавлена поддержка TTL (Time tо leave).
22.04.2021
22.04.2021
Поддержка Telnet и SSH для агента и модулей
Возможность установки агента через групповые политики, доработан инсталлятор RuSIEM в части установки системы и продолжение оптимизации демонов RuSIEM, в части уменьшения нагрузки на систему.
19.05.2021
19.05.2021
Система получила сертификат ФСТЭК
28.05.2021
28.05.2021
Полноценный запуск документации в формате Wiki
docs.rusiem.com
14.06.2021
14.06.2021
В парсер добавлена функция разбора xml, добавлена первая версия модуля активов
Добавлены динамические списки в систему. Добавлена поддержка матрицы MITRE. Реализована поддержка ElasticSearch 7.
21.07.2021
21.07.2021
Добавлены модули Sysmon и System Info для получения информации по системе с агентом
Архивация событий системы на внешнее хранилище и управление архивами через интерфейс. Улучшено шифрование при взаимодействии агента с RuSIEM. Переработано API взаимодействия систему.
Октябрь 2021
Октябрь 2021
Технологически переработан интерфейс для дашбордов событий. Полностью переработан функционал симптоматики
За счет этого увеличилась скорость работы и появились новые возможности обогащения. Благодаря сбору информации в system.info теперь в активах можно автоматически загружать и обогащать информацию с агента. Для активов добавлены скрипты автозагрузки – как информации по самому активу, так и уязвимостей. Обновлена база геоданных. Создана возможность создания инцидентов вручную. Появился новый виджет с последними инцидентами.
Автор статьи:
Максим Степченков
Совладелец компании RuSIEM

Консультация