© 1995-2023 Компания «Инфосистемы Джет»
Особенности использования Open Source в SOC
Информационная безопасность Информационная безопасность

Тест-драйв Elastic Stack. Что показало тестирование? Плюсы и минусы ПО с открытым кодом.

23.09.2022

Посетителей: 664

Просмотров: 774

Время просмотра: 2.3

Авторы

Автор
Евгений Вызулин Эксперт по информационной безопасности компании «Инфосистемы Джет»

 

Тест-драйв Elastic Stack. Что показало тестирование?


Плюсы и минусы ПО с открытым кодом

 

Открытый код достаточно хорошо зарекомендовал себя в ИБ. Его применяют даже в российских SIEM-системах: в качестве баз данных и поисковых движков чаще всего используются Elasticsearch и ClickHouse. При этом к Open Source по-прежнему остается масса вопросов. Безопасно ли открытое ПО? Нужно ли проверять код на наличие закладок? Действительно ли это экономно? Сейчас мы тестируем Open Source для SOC, и вот к каким выводам мы пришли.

Открытый код может быть частью SOC, но есть нюансы

 

Использовать Open Source в SOC можно почти на всех участках технологического ядра — от сбора и фильтрации событий до автоматизированного реагирования на угрозы. В качестве SIEM-системы можно взять Elastic Stack (состоит из Elasticsearch, Logstash и Kibana), IRP — TheHive, EDR — Wazuh.

 

 

Мы сравнивали Elastic Stack с проприетарным ПО на стендах, анализировали документацию, смотрели функционал и технические характеристики решения. Результаты получились неоднозначными. Ключевые моменты представлены в табл. 1.

 

Табл. 1. Сравнение ключевых характеристик Elastic Stack и проприетарного ПО

 

Критерии 1, 2, 4 и 5 — это основные недостатки любого Open Source SIEM в сравнении с проприетарными решениями:
Невозможность корреляции в реальном времени ухудшает SLA реагирования на угрозы.


Отсутствие централизованных обновлений и техподдержки усложняет разработку и внедрение.


Отсутствие модуля инвентаризации активов снижает осведомленность об актуальном состоянии ИС.
Некоторые из этих недостатков можно нивелировать с помощью других Open Source решений, но это несет дополнительные сложности в части разработки и внедрения.


Далее мы поделимся результатами нагрузочного тестирования некоторых компонентов Elastic Stack. Тест-драйв еще в процессе: мы снимали информацию «с колес», поэтому пока не можем привести данные по всем составляющим продукта.

Logstash


Первым был компонент Logstash. Его основные функции — нормализация, обогащение, агрегирование и корреляция поступающих событий. Мы реализовали тестовую инфраструктуру со следующими характеристиками Losgtash (см. табл. 2)

Табл. 2. Технические характеристики Logstash

 

Большой объем HDD Logstash не нужен. В основном он используется для ОС и событий самого компонента, поэтому мы взяли 200 Гб. А вот RAM нужна — она используется для обработки событий и хранения очереди. CPU же необходим, чтобы реализовать мультипоточную обработку событий.


Нам стало интересно, сколько EPS сможет обработать Logstash в этой конфигурации. Для этого были подготовлены правила нормализации и тестовые кейсы из событий ПО auditd. На графике 1 представлена зависимость CPU от EPS.

 

График 1. Зависимость CPU от EPS

 

Можно заметить, что после 10000 EPS нагрузка на CPU не изменяется и находится в промежутке между 500 и 600%. Это означает, что используется всего 6 из 10 CPU.


Зависимость RAM от EPS выглядит так (график 2).

 

График 2. Зависимость RAM от EPS

 

На 5000 EPS и более использование RAM составляло 46,5%. Это неудивительно, потому что мы установили значение JVM Heap Logstash’a на 8 Гб (50% от общего объема памяти).


Для анализа объема потока событий, которые Logstash отправляет после обработки, мы настроили взаимодействие с брокером очередей RabbitMQ (график 3).

 

График 3. Зависимость количества исходящих событий от входящих

 

При получении более 15000 EPS Logstash перестает справляться со своевременной обработкой и отправкой событий.

Оставшиеся попадают в очередь, которая хранится в RAM. Это может привести к полной «утечке» RAM и остановке Logstash. Если число правил нормализации, корреляции и обогащения увеличивается, то разность между исходящими и выходящими событиями будет расти.


Проанализировав полученные результаты, мы подготовили сайзинг технических характеристик Logstash в зависимости от EPS (см. табл. 3).

Табл. 3. Сайзинг технических характеристик компонента Logstash

 

Для объема EPS больше 30000 рекомендуем использовать кластер из нескольких компонентов Logstash. Это увеличит отказоустойчивость и скорость обработки событий.


Резюмируем:


Logstash — достаточно серьезный Open Source инструмент, позволяющий обрабатывать большой поток событий. Его можно использовать и без остальных компонентов Elastic Stack. В технологическом ядре SOC Logstash может пригодиться в качестве решения класса Log Management. Среди важных нюансов — сложность синтаксиса правил нормализации, корреляции и обогащения.

 

Elasticsearch


Второй компонент, который попал в поле нашего зрения, — Open Source база данных Elasticsearch. Мы решили сравнить ее с другой открытой БД — ClickHouse.
Главный вопрос, который нас интересовал: «Во сколько раз ClickHouse эффективнее в части хранения данных, чем Elasticsearch?» Мы наполнили их одинаковым объемом событий и использовали RabbitMQ, чтобы посмотреть, сколько долговременной памяти потребуется для хранения несжатых данных.

 

Табл. 4. Эффективность хранения данных

 

ClickHouse — более эффективное решение для задачи хранения данных. Его алгоритмы сжатия в 44 раза лучше, чем у Elasticsearch. При этом Elasticsearch в 13 раз эффективнее по сравнению с хранением данных в сыром виде (см. табл. 4).

 

Резюмируем:


ClickHouse хорошо подходит для долговременного хранения большого объема данных. Нюансом является сложность интеграции с SIEM- и IRP-системами. ClickHouse — реляционная БД, поэтому нужно будет настраивать маппинг.
Elasticsearch уже используется во многих проприетарных SIEM-системах и хорошо себя зарекомендовала. Плюс этой БД — простота интеграции с другими системами. Просто отправляйте в Elasticsearch события в формате JSON, и она их быстро замаппит. Среди нюансов отметим большое потребление ресурсов — для индексации используется много RAM.

 

Рис. 1. Схема архитектуры SOC на Elastic Stack

НА ЗАМЕТКУ

Помимо технических нюансов, у Open Source есть и другие проблемы. Основная — кадровая. На рынке не так много специалистов, которые могут построить эффективные решения на открытом коде. В своей практике мы таких не встречали — приходилось учить и растить. Одно из возможных решений — отдать разработку на аутсорсинг, ведь необходимые эксперты уже есть в ИТ-интеграторах. Возможно, это даже выйдет дешевле, чем содержать людей в штате, ведь «в среднем по больнице» сотрудники, которые умеют работать с открытым кодом, стоят на 50% дороже.
Вторая сложность связана с политической обстановкой. Россию уже частично отключили от Open Source решений, которые мы используем. Да, мы можем взять дистрибутивы через VPN, коммьюнити пока доступно. Но вероятность, что у любого продукта в любой момент могут отключиться обновления, достаточно высока.
Решений здесь несколько. Во-первых, можно использовать отечественный Open Source, например, тот же ClickHouse. Во-вторых, поможет уже упомянутый VPN. Также не стоит брать в работу версии, выпущенные после 24 февраля. Лучше выбрать дистрибутив постарше и развивать своими силами. Необходимо выстроить процессы по безопасной разработке, анализу кода приложений и их обновлений. Если говорить о закладках, поверьте, Backdoor может быть в любом продукте, в том числе вендорском. Открытый код гораздо проще проанализировать на предмет закладок, чем проприетарный.

***
Потенциал Open Source значительно вырос. Но прежде чем внедрять решения с открытым кодом, тщательно проанализируйте потребности вашей компании. Нет смысла переходить на Open Source продукты «просто чтобы они были». Если это не приведет к потере важных экономических или информационных ресурсов или поможет сэкономить, смело используйте открытое ПО. Если уверенности нет, лучше взять проприетарное.

Читайте также

5 кейсов Jet CyberCamp

Уведомления об обновлении тем – в вашей почте

Информационная безопасность - обзор основных положений. Часть 3

Деятельность любой организации подвержена множеству рисков. Нас будут интересовать те из них, которые являются следствием использования информационных технологий.  Управление рисками   Суть работы по управлению рисками состоит в том, чтобы ...

Превосходный SOC, или Рецептура решения инцидентов

Как построить оптимальный SOC и грамотно выстроить процесс решения инцидентов

Выбор широкополосных измерительных антенн в целях контроля эффективности защиты информации

В настоящее время на рынке представлено значительное количество измерительных антенн отечественных и зарубежных фирм-производителей

Услуги информационной безопасности для абонентов в арсенале российских операторов, вендоров и интеграторов

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

Как мы делаем безопасность. Макрофреймворк ИБ «Модель Аэропорт»

Как мы строили ИБ раньше и почему теперь это не работает? Макрофреймворк по ИБ «Модель Аэропорт». Как работать с рисками катастрофических инцидентов ИБ?

Интервью с Игорем Ляпуновым, директором Центра информационной безопасности компании «Инфосистемы Джет»

Не так давно центр информационной безопасности компании «Инфосистемы Джет» подвел итоги своей работы за прошлый год. И сегодня нашим собеседником стал Игорь Ляпунов, директор ЦИБ, который рассказал, какими результатами завершился 2009 г. для центра информационной безопасности.

Облачный SOC - безопасность в аренду

На текущий момент о задаче управления инцидентами ИБ уже сказано очень много ..

«Сезон охоты на русские информсистемы»

Почему кризис в первую очередь ударит по малому и среднему бизнесу? Сколько лет понадобится, чтобы допилить отечественные ИБ-решения? Почему деревянный софт — не главная проблема российского рынка?

Построение системы информационной безопасности на основе Solaris 2.x

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня