Вы не задумывались, почему один из крупнейших поставщиков услуг SOC в РФ использует OpenSearch? Почему Amazon (AWS) поддержал проект и продолжает развитие облачного мониторинга на OpenSearch? Почему Microsoft Sentinel, один из лидеров квадранта Gartner по SIEM в 2024 году, использует собственную СУБД? Попробуем разобраться, какие недостатки имеет SIEM на ClickHouse, и расскажем, почему низкие технические требования могут оказаться мифом и обернуться снижением качества расследования инцидентов.
Сторонники ClickHouse приводят множество аргументов, среди которых колоночная структура данных, параллельная обработка, оптимизация для OLAP-запросов, горизонтальное масштабирование, снижение требований к ресурсам. При одинаковом потоке событий Clickhouse требует меньше места, чем OpenSearch, или ELK: Click’like SIEM делают нормализацию и корреляцию перед записью событий и хранят данные в сжатом виде. Однако давайте проанализируем, что это на деле означает. Для объективной картины не будем брать компании BigTech с потоком свыше 100 000EPS, которые обладают большим бюджетом, экспертизой и используют для обеспечения ИБ все доступные инструменты – от связки ELK и ClickHouse до in-memory СУБД. Также исключим сегменты ниже 5000 EPS, где компании часто предпочитают коммерческие SOC. Возьмём компании, работающие в диапазоне 5000 – 100 000 EPS.
Изображение сгенерировано с помощью Freepik
Корреляция «на лету»
ClickHouse не заточен на операции типа update и постоянные мелкие insert. И если в SIEM update – редкий и специфичный кейс, то любое новое событие – это insert. Проблему решили пакетной записью: поставили брокер, который собирает данные в bucket и отправляет в базу большими объёмами. Однако если брокер упадёт, то данные не попадут в ClickHouse, а значит, мы получим +1 точку отказа и потерю данных в реальном времени. OpenSearch может работать как с брокерами, так и без них, и это не сказывается на производительности.
Нормализованные данные действительно занимают в несколько десятков раз меньше места в ClickHouse, но что же с «сырыми» данными, так называемыми RAW? И вот тут жёсткая схема и структура Click’a играет против: она существенно усложняет быстрое обнаружение неизвестных угроз (может не оказаться нужных сведений/полей) и разработку новых правил (когда нужно новое поле). Кроме того, если нормализация данных или сбор событий настроены неправильно – а такие случаи, к сожалению, происходят часто, – то в процессе расследования аналитикам может не хватать информации.
Как это сказывается на ИБ? В идеальной ситуации, когда TI-команды вендора опережают злоумышленника, поставляют новые IoC и Feeds без задержек и фолзов, – никак. Но в реальности, где существует 0-day, где злоумышленники могут находиться в инфраструктуре месяцами до реализации атаки, а сроки от проникновения до детекта доходят до года, задержка в получении корреляции на несколько минут не станет критичной, а вот возможность быстро «пройтись» по «сырым» данным за последние два месяца и возможность посткорреляции окажутся очень полезны.
Нормализованные данные действительно занимают в несколько десятков раз меньше места в ClickHouse, но что же с «сырыми» данными, так называемыми RAW? И вот тут жёсткая схема и структура Click’a играет против: она существенно усложняет быстрое обнаружение неизвестных угроз (может не оказаться нужных сведений/полей) и разработку новых правил (когда нужно новое поле). Кроме того, если нормализация данных или сбор событий настроены неправильно – а такие случаи, к сожалению, происходят часто, – то в процессе расследования аналитикам может не хватать информации.
Как это сказывается на ИБ? В идеальной ситуации, когда TI-команды вендора опережают злоумышленника, поставляют новые IoC и Feeds без задержек и фолзов, – никак. Но в реальности, где существует 0-day, где злоумышленники могут находиться в инфраструктуре месяцами до реализации атаки, а сроки от проникновения до детекта доходят до года, задержка в получении корреляции на несколько минут не станет критичной, а вот возможность быстро «пройтись» по «сырым» данным за последние два месяца и возможность посткорреляции окажутся очень полезны.
Изображение сгенерировано с помощью Freepik
Снижение требований по ресурсам
Одна из причин, почему разработчики меняют Elastic на ClickHouse под капотом своего решения, – это запрос рынка на снижение требований по ресурсам. И он справедлив, однако актуален ровно до тех пор, пока компания жёстко подчиняется требованиям схемы хранения данных и политике хранения. Но верным ли шагом будет покупать решение, под которое вы должны перестроить свой бизнес? Наша компания проводила детальную оценку объёмов и сроков хранения, и в некоторых случаях стоимость «железа» «в лоб», когда мы считаем сервера только под систему, получалась практически одинаковой при использовании и Elastic, и ClickHouse.
Поясню, как мы это выяснили. Мы протестировали SIEM, работающую на Elastic Search, внутри SOC. Объём потока составлял 10 000EPS, срок хранения событий в нашей терминологии: 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.
Поясню, как мы это выяснили. Мы протестировали SIEM, работающую на Elastic Search, внутри SOC. Объём потока составлял 10 000EPS, срок хранения событий в нашей терминологии: 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 позволяет найти любые данные и любое упоминание в кратчайшие сроки. Представим, что ваша команда ИБ получила новые индикаторы компрометации, актуальные для вашего сегмента бизнеса. Процесс их верификации и адаптации занимает время. C помощью OpenSearch вы cможете оперативно, ещё до запуска этого процесса, по регулярному выражению или простым запросом пройтись по всем событиям в поиске метаданных, команд, редких символов и многого другого, и тем самым проверить актуальность угрозы для вашей инфраструктуры. Добавим, что в третьей версии ClickHouse реализована поддержка GPU для ML, что потенциально может ускорить анализ угроз (о том, как это скажется на развитие SIEM, мы расскажем позже).
Полнотекстовой поиск OpenSearch позволяет найти любые данные и любое упоминание в кратчайшие сроки. Представим, что ваша команда ИБ получила новые индикаторы компрометации, актуальные для вашего сегмента бизнеса. Процесс их верификации и адаптации занимает время. C помощью OpenSearch вы cможете оперативно, ещё до запуска этого процесса, по регулярному выражению или простым запросом пройтись по всем событиям в поиске метаданных, команд, редких символов и многого другого, и тем самым проверить актуальность угрозы для вашей инфраструктуры. Добавим, что в третьей версии ClickHouse реализована поддержка GPU для ML, что потенциально может ускорить анализ угроз (о том, как это скажется на развитие SIEM, мы расскажем позже).
Вы все еще уверены, что экономия 20 – 30% на CPU, RAM и более высокие требования к SSD-хранилищу стоят отказа от гибкости и возможности работы с «сырыми» данными?
Автор: Илья Одинцов, менеджер по продукту NGR Softlab
Источник: 1275.ru
