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

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

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

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

 

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

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

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

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

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

 

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

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

 

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

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

• Есть ли возможность выбрать уровень технической поддержки? Выбрав базовый, можно сэкономить, но более высокий уровень позволит обеспечить более оперативную реакцию вендора на тикет и/или включает дополнительные работы.
• Есть ли гарантированное соглашение SLA для реагирования на запросы пользователей?
• Входит ли разработка парсеров под заказ в техподдержку? Например, в техническую поддержку Kaspersky Unified Monitoring and Analysis Platform 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-решение будет внедряться не в абстрактной инфраструктуре, а в конкретной организации, и для заказчика важнее поддержка именно его источников.

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

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

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

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

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

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

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

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

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

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

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

 

Заключение

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

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