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

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

23.09.2022

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

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

Время просмотра: 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

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

О лицензировании и сертификации в области защиты информации

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

Как реагировать на нарушения информационной безопасности

Цель настоящего документа – сформулировать ожидания Интернет-сообщества по отношению к группам реагирования на нарушения информационной безопасности (Computer Security Incident Response Teams, CSIRTs). Нет возможности определить набор ...

«Самое страшное уже позади, а самое сложное — впереди»: угрозы 2022 глазами Jet CSIRT

Динамика роста ИБ-инцидентов за последние месяцы? Кто стоит за этими киберпреступлениями? Что делать, чтобы подготовиться к актуальным угрозам?

Сертификация средств, включающих криптографические компоненты

Интервью заместителя начальника Главного управления ФАПСИ Гермогенова Александра Петровича информационному бюллетеню JetInfo  1. Федеральное агентство правительственной связи и информации при Президенте РФ – мощное ведомство с многогранной ...

Аудит информационных систем

Под термином аудит Информационной Системы понимается системный процесс получения и оценки объективных данных о текущем состоянии ИС, действиях и событиях, происходящих в ней, устанавливающий уровень их соответствия определенному критерию ...

ИБ-ликбез в формате small talk. Под капотом — защита облаков, Deception, киберполигон

Пошаговый чек-лист для построения защиты облаков с нуля. Рекомендации, как выстроить Digital Risk Protection, и подборка Open Source утилит. Сравнение трех лидеров рынка автопентестов: PenTera, Cymulate, Cronus CyBot.

«Информационная безопасность банков»: что прогнозируют российские ИБ-специалисты

Появились ли за последние два месяца новые ИБ-угрозы? Из-за чего происходит «окирпичивание» оборудования? Почему текущие проблемы — это только начало?

Аттестация автоматизированных систем

В современных условиях наиболее перспективным способом проверки достигнутого качества функционирования и уровня защищенности автоматизированных систем (АС) является процедура аттестации. В то время как для многих коммерческих АС аттестация ...

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





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







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







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







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








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

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

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

            Спасибо!

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

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