Open Source в SOC

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

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

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

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

Logstash

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

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

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

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

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

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

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

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

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

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

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

Резюмируем:

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

Elasticsearch

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

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

Резюмируем:

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

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

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