13 Октября 2022 10:00 | 13 Окт 2022 10:00 | |

Поделиться

Как выбирать коммерческий SIEM в 2022 году?

Введение

В данной статье разберем, как текущая ситуация влияет на выбор SIEM, что изменилось, а что продолжает быть важным в 2022 году. Попробуем оценить это не только с технической стороны, но и со стороны бизнеса организации.

Нетехнические факторы

Выбирая SIEM-решение, не стоит забывать о контексте применения и специфике бизнеса организации. Речь идет об основной задаче организации, в чем бы она ни заключалась: генерации выручки, обеспечении государственной функции и т.д.

Внедрение SIEM — это серьезные и долгосрочные инвестиции. Необходимо убедиться, что они не будут напрасными и что им не грозит несоответствие законодательству, уход вендора с рынка, санкции, объявление вендором End-of-sale и т.д.

Соответствие политике импортозамещения

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

1. наличии сертификата на соответствие требованиям ФСТЭК с требуемым уровнем доверия. Проверить наличие можно в Реестре сертифицированных средств защиты информации ФСТЭК. Имейте в виду, что данные в реестре обновляются с определенной задержкой и информация о наличии сертификата попадает туда не моментально;
2. наличии информации о продукте в Реестре отечественного ПО;
3. поддержке работы всех компонентов на отечественных ОС, в том числе Astra Linux, «Альт Линукс», МСВС;
4. серверы обновлений производителя находятся на территории РФ (если применимо);
5. наличии русскоговорящей техподдержки.

Это минимальный набор, для вашего конкретного случая могут быть актуальны дополнительные сертификаты или требования соответствующих нормативно-правовых актов. Решение «Лаборатории Касперского» Kaspersky Unified Monitoring and Analysis Platform (KUMA) соответствует этим пяти требованиям.

Стоимость владения

Стоимость владения складывается из стоимости лицензии, «железа», техподдержки и зарплат эксплуатирующего персонала. Рассмотрим, какие требования стоит учесть по первым трем параметрам. Зарплаты сотрудников, работающих с SIEM-системой, зависят от слишком большого количества нюансов (целей и задач вашего отдела мониторинга — SOC, величины инфраструктуры, процессов), их в данной статье обсуждать не будем.

Стоимость лицензий

Сравнивая стоимость лицензий, стоит обратить внимание на следующее:

• Как именно считается параметр, по которому происходит лицензирование?
  • Если это EPS, то считается ли он «на входе» или «на выходе» коллектора, уже после фильтрации и агрегации? Второй вариант будет заметно выгоднее.
  • Если это узлы — что именно понимается под хостом, как определяется их количество, как считаются виртуальные машины, сетевые устройства, межсетевые экраны?
• В качестве метрики лицензирования учитывается пиковое или среднее значение параметра? За какой период?
• Требуются ли дополнительные лицензии для установки дополнительных компонентов решения (коллектора, коррелятора, узлов базы данных)?
• Что произойдет при превышении лицензии? По истечении срока лицензии?
• Какой функционал входит в базовую лицензию, а что потребует приобретения дополнительных лицензий?

Аппаратное обеспечение

Некоторые SIEM-решения бывают весьма «прожорливыми» с точки зрения требуемого «железа». Требования к оборудованию становятся особенно важны в текущих условиях, когда его стоимость заметно повысилась, а доступность не гарантирована. Следует также учесть возможное масштабирование и как будут расти требования к «железу». Также важно, поддерживается ли работа решения в виртуальной инфраструктуре.

Стоимость технической поддержки

Доступ к технической поддержке может продаваться отдельно либо входить в стоимость лицензии ПО. В любом случае желательно обратить внимание на следующее:

• Есть ли возможность выбрать уровень технической поддержки? Выбрав базовый, можно сэкономить, но более высокий уровень позволит обеспечить более оперативную реакцию вендора на тикет и/или включает дополнительные работы.
• Есть ли гарантированное соглашение SLA для реагирования на запросы пользователей?
• Входит ли разработка парсеров под заказ в техподдержку? Например, в техническую поддержку KUMA входит создание от 10 парсеров.
• Предусмотрена ли возможность подключения специалистов вендора удаленно к инфраструктуре заказчика для решения проблем?

Выбор поставщика

Внедрение SIEM — всегда достаточно длительный проект и долгосрочные инвестиции. Миграция на другие решения всегда достаточно сложная. Поэтому есть смысл с самого начала постараться минимизировать некоторые риски, такие как:

• уход вендора с рынка;
• прекращение разработки продукта;
• низкий темп разработки по причине нехватки ресурсов;
• прекращение развития или недоступность продукта по причине недоступности сторонних компонентов. Если решение построено на сторонних компонентах и/или OEM-компонентах, в один момент они могут стать недоступны (в том числе из-за санкций). Поэтому важно обращать внимание на ключевые компоненты решения: какие из них — собственная разработка вендора, а какие — сторонние.

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

Технические критерии выбора SIEM

Архитектура и масштабирование

Стоит обратить внимание на то, каким образом может масштабироваться инсталляция. Даже если сегодня у вас один офис и достаточно базового «все-в-одном», лучше заложить возможность роста нагрузки и количества площадок.

На какие моменты стоит обратить внимание:

• Производительность решения — и при каких условиях она достигается:
  • Какова производительность на один узел, без балансировки?
  • Совокупная, с балансировкой?
  • Какие аппаратные ресурсы при этом требуются?
  • Как влияет количество и сложность правил корреляции, обогащения, обработки данных на производительность решения?
• Поддержка горизонтального и вертикального масштабирования — то есть расширение системы возможно как за счет добавления новых серверов, так и за счет добавления аппаратных ресурсов существующим серверам.
• Возможность работы в отказоустойчивом режиме.
• Поддержка различных вариантов инсталляции — «все-в-одном», геораспределенная, иерархическая. Плюс возможность масштабировать системы от наиболее простого варианта к более сложному.
• Поддержка отделяемого агента/коллектора, который устанавливается на удаленную площадку, собирает и обрабатывает данные, обеспечивает сжатие при передаче.
• Поддержка иерархической инсталляции — внедрение нескольких инсталляций SIEM в режиме parent-child в иерархической структуре. Это актуально для холдингов с дочерними организациями, MSSP и других организаций со сложной организационной структурой. Поддержка иерархической модели дает возможность, с одной стороны, реализовать независимую инсталляцию для каждой «дочки»/клиента/подведомственной организации, а с другой — объединить все эти инсталляции в единой консоли управления, задавать глобальные конфигурации, видеть алерты со всех инсталляций.
• Мультитенантность — возможность разделить одну инсталляцию SIEM на несколько логических «доменов», назначив каждому из них разные правила корреляции, права доступа аналитиков, фильтры, дашборды и другие настройки конфигурации и контента SIEM. Такая функциональность особенно актуальна для MSSP, которые могут использовать одну инсталляцию SIEM сразу для нескольких клиентов и экономить тем самым средства и время на администрирование, лицензии и т. д.
• Централизованное управление из единой консоли, желательно веб-интерфейс.

Сбор, обработка и хранение данных

Централизованная работа с логами является основной функцией любого SIEM. На что стоит обратить внимание:

• Поддержка кэширования данных на коллекторах/агентах — в случае краткосрочной недоступности центральных компонентов системы на основной площадке (например, «упали» каналы связи), данные не потеряются, а будут накапливаться в кэше. Очень желательно, чтобы была возможность настраивать размер кэша.
• Список поддерживаемых протоколов и форматов логирования. Чем этот список длиннее, тем лучше. Хорошо, если система поддерживает из коробки такие стандартные форматы как CEF, JSON, key-value, XML, CSV. Также обязательна возможность написания regexp для нестандартных форматов.
• Возможность фильтрации, агрегации, обогащения и другой обработки данных на коллекторе.
• Поддержка сбора и обработки xFlow телеметрии — Netflow 5/9, IPFIX, sFlow и т. д.

С точки зрения хранения данных стоит обратить внимание на такие критерии:

• Компрессия данных — хорошо бы, чтобы при хранении данных в основной базе SIEM-решения была возможность их «сжать», чтобы они занимали меньше места на дисках, чем исходные. Обычно коэффициент компрессии указывается в виде «х:1», где х — коэффициент сжатия исходных данных. Обратите внимание, что некоторые решения на рынке не поддерживают компрессию данных вообще в силу архитектурных особенностей.
• Возможность сохранения «сырых» (raw) событий — наряду с нормализованными событиями полезно иметь возможность сохранять и необработанные, «сырые» события. Это необходимо как для выполнения требований законодательства (неизменность исходного события), так и с точки зрения расследования инцидента (может понадобиться дополнительная, ненормализованная информация из события), или же просто для тестирования правил нормализации. Желательно, чтобы сохранение «сырых» событий было настраиваемой опцией и была возможность включить ее только для некоторых источников данных.
• Возможность гибко настраивать время хранения (retention period) для разных источников данных.
• Возможность архивировать данные на внешние накопители для долговременного хранения.

Обогащение событий

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

• внутреннюю — данные о внутренней инфраструктуре организации, пользователях, хостах, и т.д. Обычно это информация из LDAP, DNS, внутренних систем (HR, СКУД, CMDB, отчеты сканнеров защищенности);
• внешнюю — данные об «окружающей среде», такие как известные вредоносные URL, hash-суммы файлов, IP-адреса, а также контекст их применения (актуальность, критичность, связь с АРТ-кампаниями).

Поиск по событиям

Еще одна ключевая функция SIEM — это предоставление инструментов для поиска и анализа собранных данных. Важные функции, на которые стоит обратить внимание:

• Возможность использования расширенного языка поисковых запросов для поиска по событиям, например SPL в Splunk, Lucene/EQL в ELK или классический SQL. Вариант с SQL предпочтительнее, так как знаком многим и не требует изучения.
• Возможность сохранять поисковые запросы — чтобы не набирать каждый раз одни и те же условия.
• Возможность задавать наборы полей для отображения.
• Возможность экспортировать события в текстовый файл (например, CSV).
• Возможность создавать дашборды из поискового запроса.
• Возможность поиска по «сырым» событиям.

Корреляция

Корреляция событий безопасности — тоже одна из ключевых функций SIEM. На что рекомендуем обратить внимание:

• Корреляции в режиме реального времени — в некоторых решениях (Splunk, Elastic) нет коррелятора как такового. Алерты генерируются как результаты автоматических поисковых запросов к БД с событиями. Такой подход вполне имеет право на жизнь, но все же обладает некоторыми минусами — часто нельзя сформировать более сложную детектирующую логику, требует больше ресурсов, производительность ниже.
• Возможность использования активных листов (или аналогов) в правилах корреляции. С помощью этого механизма мы, по сути, получаем возможность долговременно хранить определенные значения (IP, имена пользователей, хостов и т.д.). Это существенно расширяет возможности создания корреляционной логики.
• Поддержка математических операций при корреляции— возможность оперировать результатами математических функций в правилах корреляции.
• Возможность ретроспективного анализа — запуск новых правил корреляции на ранее собранных данных.

Отчеты и дашборды

Рекомендуем обратить внимание на следующие функции:

• возможность легко изменять вид, тип, размер, позицию виджетов на дашборде;
• возможность гибко строить дашборд на базе поискового запроса;
• возможность гибко задавать временные интервалы и вид виджета (pie chart, диаграмма, таблица);
• возможность задавать виджеты с сравнением за разные временные интервалы;
• возможность drill-down на дашбордах к событиям;
• возможность формировать и отправлять отчеты по расписанию;
• возможность выгружать отчет в виде файла (html, pdf).

Контент «из коробки»

Поддерживаемые источники «из коробки»

Одна из основных задач SIEM — обработка данных с различных источников (СЗИ, коммутационного оборудования, ПО и т. д.) и приведение их к единому унифицированному формату. Этот процесс называется нормализацией. У каждого SIEM есть определенный набор правил нормализации «их коробки», определяющий поддерживаемые источники. Чем больше и полнее список поддерживаемых источников «из коробки», тем лучше. С другой стороны, SIEM-решение будет внедряться не в абстрактной инфраструктуре, а в конкретной организации, и для заказчика важнее поддержка именно его источников.

Фото: © HayDmitriy / Фотобанк Фотодженика

К тому же на первом этапе перечень подключаемых источников обычно довольно стандартный — фаерволлы, антивирусы, логи Windows, DNS, DHCP, Netflow. В дальнейшем экспертиза администраторов копится и становится важнее, насколько удобные инструменты SIEM предоставляет для разработки собственных правил нормализации. Поэтому стоит обращать внимание не столько на количество поддерживаемых источников, сколько на следующие моменты:

• Поддерживаются ли источники, которые вы планируете подключить на первом этапе?
• Есть ли возможность подключить неподдерживаемый «из коробки» источник без помощи вендора. Можно ли написать «парсер» самостоятельно или с помощью интегратора, не привлекая вендора?
• Насколько удобно и просто пользоваться средствами самостоятельной разработки/доработки правил нормализации. Есть ли графический интерфейс для создания правил или нужно изучить специальный программный язык производителя и писать правило в «коде»?
• Какие виды транспорта, форматы и типы источников поддерживаются?

Правила корреляции «из коробки»

Это еще один критерий, который присутствует в любом сравнении, в вопросах заказчиков или брошюре вендора.

Распространенное мнение гласит, что, чем больше правил предоставляет вендор и чем чаще выпускает пакеты новых, тем лучше. Это считается чуть ли не одной из самых важных характеристик SIEM-решения. На другом полюсе мнение скептиков, которые считают, что правила от вендора ни на что не годны.

Следует придерживаться «золотой середины» — безусловно, не стоит рассчитывать, что правила из коробки, без минимального тюнинга, нормально заработают в вашей инфраструктуре. Вас просто завалит тонной ложных срабатываний.

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

На что стоит обратить внимание при оценке контента от вендора:

• Правила должны быть хорошо документированы — описана логика работы, требуемые источники данных, id событий, варианты имплементации и обработки ложных срабатываний.
• Возможность кастомизации/тюнинга под инфраструктуру заказчика — правила должны предоставлять возможность (где это применимо) вносить учетные записи, имена хостов, IP и другую контекстную информацию, релевантную для инфраструктуры заказчика.
• Возможность модифицировать, копировать, отключать и просматривать логику срабатывания правила.
• Привязка к MITRE TTP — привязка детектирующей логики к техникам и тактикам матрицы MITRE, своего рода уже стандарт де-факто.

Возможности API

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

Заключение

В текущей ситуации при выборе SIEM стоит учитывать не только технические критерии, но и многие другие факторы — устойчивость к санкциям, соответствие политике импортозамещения, надежность и устойчивость поставщика.

Автор статьи Сергей Штин, эксперт по информационной безопасности «Лаборатории Касперского».

Поделиться

Короткая ссылка