История развития 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