На сегодняшний день компаниям важно найти ответы на два вопроса:
1. Какие ИБ-решения выбрать, чтобы не пострадать от санкций?
2. Какие конкурентоспособные SIEM-системы стоит рассмотреть?
Публикуем для вас статью о российской SIEM-системе — RuSIEM. Подробно о том, что такое SIEM-системы, об их важности и какие задачи решают мы рассказывали в статье «Задача — мониторинг сети: знакомимся с российскими SIEM».
В данной статье рассмотрим именно 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. Клиентские средства АРМ операторов системы с установленным веб-браузером.
Что было дальше?
Задача первого заказчика, естественно, была решена. За ней последовала длительная адаптация продукта под его конкретные потребности, которые росли вместе с нагрузкой и спектром решаемых задач. Однако результаты проделанной работы позволили уже через год создать первую коробочную версию продукта и выйти с ней на массовый рынок.
Все последующие годы мы дорабатывали систему, почти каждый месяц внося в нее большое количество изменений. Мы зарегистрировали компанию и включили систему в реестр отечественного ПО, стали резидентом «Сколково», получили сертификат ФСТЭК России, в результате чего колоссально вырос объем клиентской базы.
Система перешла с Ubuntu 14 на поддерживаемые версии, мы создали ее бесплатную версию и разработали модуль аналитики для платной. Разработали собственную шину данных, парсеры и коннекторы, отказались от Hadoop и провели большое количество других существенных изменений.
Самое важное о развитии RuSIEM:
- 2014 — создание продукта.
- 2015 — анонс функциональности первой коробочной версии и первая партия ключей для пилотных проектов. Появление симптоматики, Workflow и улучшение работы с инцидентами.
- 2016 — появление взаимосвязей, отчётов, модуля аналитики.
- 2017 — появление бесплатной версии продукта. Внедрение мультиязычности, собственной шины RuSIEM MQ. Переход с influxdb на БД разработки Яндекс — ClickHouse.
- 15.08.2017 — RuSIEM включена в реестр российского ПО.
- 2018 — обновление API и возможность управления всеми нодами удаленно, с единого интерфейса.
- 2019 — возможность создавать собственные парсеры и подключать любой источник самостоятельно.
- 2020 — поддержка Ubuntu 18. Функционал мониторинга внутренних микросервисов системы, функционал подключения подчиненных серверов. Закончена полноценная интеграция c R-Vision.
- 2021 — переработаны корневые сервисы RuSIEM: Оптимизирован поиск по событиям, оптимизирована аналитика. Добавлена статистика по парсерам, статистика по отработке корреляции. Поддержка Telnet и SSH для агента и модулей.
- 19.05.2021 — система получила сертификат ФСТЭК.
- С лета 2021 — в парсер добавлена функция разбора xml, добавлена первая версия модуля активов. Добавлена поддержка матрицы MITRE, модули Sysmon и System Info. Реализована поддержка ElasticSearch 7. Переработаны интерфейс для дашбордов событий и функционал симптоматики.
АВТОР
👉 Ещё больше о российских ИБ-решениях в целях импортозамещения читайте здесь.
#информационная безопасность #информационные технологии #системное администрирование #сетевые технологии #it #импортозамещение