Несколько лет назад на рынке начался массовый переход разработчиков SIEM с ElasticSearch на ClickHouse. В его пользу звучали такие аргументы, как высокая скорость обработки, колоночная структура данных, параллельная обработка, оптимизация для OLAP-запросов, горизонтальное масштабирование, снижение требований к ресурсам. Однако всегда ли они справедливы и какие из них являются мифами?
Вы не задумывались почему один из крупнейших поставщиков услуг SOC в РФ использует OpenSearch? Почему Amazon (AWS) поддержал проект и продолжает развитие облачного мониторинга на OpenSearch? Почему Microsoft Sentinel, один из лидеров квадранта Gartner по SIEM в 2024 году, использует собственную СУБД? Попробуем разобраться, какие недостатки имеет SIEM на ClickHouse, и расскажем, почему низкие технические требования могут оказаться мифом и обернуться снижением качества расследования инцидентов.
Сторонники ClickHouse приводят множество аргументов, среди которых колоночная структура данных, параллельная обработка, оптимизация для OLAP-запросов, горизонтальное масштабирование, снижение требований к ресурсам. При одинаковом потоке событий Clickhouse требует меньше места, чем OpenSearch или ELK: Click’like SIEM делают нормализацию и корреляцию перед записью событий и хранят данные в сжатом виде. Однако давайте проанализируем, что это на деле означает. Для объективной картины не будем брать компании BigTech с потоком свыше 100 000 EPS, которые обладают большим бюджетом, экспертизой и используют для обеспечения ИБ все доступные инструменты - от связки ELK и ClickHouse до in-memory СУБД. Также исключим сегменты ниже 5000 EPS, где компании часто предпочитают коммерческие SOC. Возьмём компании, работающие в диапазоне 5000 – 100 000 EPS.
Корреляция «на лету»
ClickHouse не заточен на операции типа update и постоянные мелкие insert. И если в SIEM update - редкий и специфичный кейс, то любое новое событие - это insert. Проблему решили пакетной записью: поставили брокер, который собирает данные в bucket и отправляет в базу большими объёмами. Однако если брокер упадёт, то данные не попадут в ClickHouse, а значит мы получим +1 точку отказа и потерю данных в реальном времени. OpenSearch может работать как с брокерами, так и без них, и это не сказывается на производительности.
Нормализованные данные действительно занимают в несколько десятков раз меньше места в ClickHouse, но что же с «сырыми» данными, так называемыми RAW? И вот тут жёсткая схема и структура Click’a играет против: она существенно усложняет быстрое обнаружение неизвестных угроз (может не оказаться нужных сведений/полей) и разработку новых правил (когда нужно новое поле). Кроме того, если нормализация данных или сбор событий настроены неправильно - а такие случаи, к сожалению, происходят часто, - то в процессе расследования аналитикам может не хватать информации.
Как это сказывается на ИБ? В идеальной ситуации, когда, TI-команды вендора опережают злоумышленника, поставляют новые IoC и Feeds без задержек и фолзов - никак. Но в реальности, где существует 0-day, где злоумышленники могут находиться в инфраструктуре месяцами до реализации атаки, а сроки от проникновения до детекта доходят до года, задержка в получении корреляции на несколько минут не станет критичной, а вот возможность быстро «пройтись» по «сырым» данным за последние два месяца и возможность посткорреляции окажутся очень полезны.
Если у вас есть RAW, в которых были следы тактик и техник, неизвестных на момент записи, то вам не надо ждать новых действий злоумышленника. Сроки обнаружения сильно снижаются, давая драгоценное время. Кстати, данные типа WARM можно хранить и на SATA/SAS-массивах в зависимости от потока/объёма/архитектуры - OpenSearch не так требователен к SSD. 200Тб All-Flash СХД будет стоить дороже, чем гибрид на 300Тб (100Тб All-flash + 200Тб дисковой), а за 3 – 5 лет эта разница только увеличится. Таким образом для некоторых сценариев OpenSearch с гибридным хранилищем в долгосрочной перспективе окажется экономически более выгодным.
Жёсткая схема данных, дающая Clickhouse такую эффективность, может мешать заказчикам, которые хотят не потерять данные и иметь возможность ретроспективно обратиться к ним. Тем более это стоит учитывать, если компания использует или создает инновационные технологии: в таком случае подключение новых источников и нормализация событий от них становится не разовой задачей, а процессом. OpenSearch позволит быстро получить данные в сыром виде и работать с ними, не ожидая несколько недель разработки нового коннектора. Это актуально и для частых историй с ошибками в настройках источников: агрегация по полям позволяет снизить объём хранения данных, но именно это же лишает компанию видимости и усиливает требования к компетенциям сотрудников.
Горизонтальное масштабирование
Не вдаваясь глубоко в технику, отметим, что геокластеры Click’like SIEM - редкое явление. Автору известно лишь несколько независимых геораспределённых инсталляций с единым головным окном управления. В OpenSearch же может содержаться порядка пяти схем масштабирования системы, что позволяет заказчику выбирать, что для него важнее: ресурсы или скорость/доступность. Кроме того, OpenSearch/ELK хорошо работает и в высоконагруженных геораспределённых SIEM-системах: на рынке успешно действуют несколько ИБ-геокластеров на базе стека ELK/Opensearch с потоками, превышающими 30 000 событий в секунду на каждый ЦОД.
Снижение требований по ресурсам
Одна из причин, почему разработчики меняют Elastic на ClickHouse под капотом своего решения - это запрос рынка на снижение требований по ресурсам. И он справедлив, однако актуален ровно до тех пор, пока компания жёстко подчиняется требованиям схемы хранения данных и политике хранения. Но верным ли шагом будет покупать решение, под которое вы должны перестроить свой бизнес? Наша компания проводила детальную оценку объёмов и сроков хранения, и в некоторых случаях стоимость «железа» «в лоб», когда мы считаем сервера только под систему, получалась практически одинаковой при использовании и Elastic, и ClickHouse.
Поясню, как мы это выяснили. Мы протестировали SIEM, работающую на Elastic Search, внутри SOC. Объём потока составлял 10 000 EPS, срок хранения событий в нашей терминологии HOT - 14 дней, WARM - 1 месяц, COLD - 2 месяца, архив с возможностью быстрого извлечения индексов за указанный период - 9 месяцев, система с включённым модулем UEBA и модулем анализа netflow.
Учтено резервирование хранилища событий и трёхлетний срок хранения инцидентов. Для чистоты оценки мы брали GPL-цены на серверы под систему. Ключевой момент заключается в том, что HOT+WARM - SSD, а COLD на SATA. OS-архитектура вынуждает нас реплицировать данные для быстрого поиска, и, таким образом, мы одновременно ускоряем поиск и храним данные на трёх нодах, архив на SATA-дисках в S3. ClickHouse же вынужден «держать» HOT+WARM+COLD на SSD + реплику БД в аналогичном сайзинге.
Подчеркну, что хранение инцидентов тут не играет роли: они занимают мало места даже за три года. В случае с тестируемой SIEM - она позволяет хранить информацию на SATA, при этом серверам на ClickHouse надо либо «добивать» SATA-дисками корзину, либо, опять же, использовать для этих целей SSD.
Более того, SIEM на Elastic может обойтись дешевле. В одном из наших кейсов, где заказчик планировал хранить в горячем доступе данные две недели, потом месяц WARM, три месяца COLD и дальше - архив три года при потоке 15 000 EPS, наша система потребовала «железа» на 30% дешевле, чем SIEM на ClickHouse.
Не только визуализация
ClickHouse - это аналитическая база данных, и если ваша команда ИБ состоит из аналитиков, которым важна визуализация и скорость создания огромного количества отчётов, то ClickHouse станет действительно хорошим выбором. Однако для компаний, делающих фокус на исследовательской деятельности, расследованиях и поиске, оптимальным решением будет OpenSearch.
Полнотекстовой поиск OpenSearch позволяет найти любые данные и любое упоминание в кратчайшие сроки. Представим, что ваша команда ИБ получила новые индикаторы компрометации, актуальные для вашего сегмента бизнеса. Процесс их верификации и адаптации занимает время. С помощью OpenSearch вы сможете оперативно, ещё до запуска этого процесса, по регулярному выражению или простым запросом пройтись по всем событиям в поиске метаданных, команд, редких символов и многого другого, и тем самым проверить актуальность угрозы для вашей инфраструктуры. Добавим, что в третьей версии ClickHouse реализована поддержка GPU для ML, что потенциально может ускорить анализ угроз (о том, как это скажется на развитие SIEM, мы расскажем позже).
Вы все еще уверены, что экономия 20 – 30% на CPU, RAM и более высокие требования к SSD-хранилищу стоят отказа от гибкости и возможности работы с «сырыми» данными?
Илья Одинцов, менеджер по продукту NGR Softlab
