Востребованность систем анализа ИБ-событий и управления ими в последнее время растет. Связано это с тем, что без контроля происходящего внутри периметра компании невозможно быть уверенным в надёжности и эффективности смежных систем и процессов защиты. В этой статье эксперт Kaspersky рассказывает, на что стоит обращать внимание при выборе технологии управления информацией и событиями по безопасности — SIEM.
Нетехнические факторы
Выбирая SIEM-решение, не стоит забывать о контексте применения и специфике бизнеса организации. Речь идет об основной задаче организации, в чем бы она ни заключалась: генерации выручки, обеспечении государственной функции и т.д.
Внедрение SIEM — это серьезные и долгосрочные инвестиции. Необходимо убедиться, что они не будут напрасными и что им не грозит несоответствие законодательству, уход вендора с рынка, объявление вендором End-of-sale и т.д.
Стоимость владения
Стоимость владения складывается из стоимости лицензии, «железа», техподдержки и зарплат эксплуатирующего персонала. Рассмотрим, какие требования стоит учесть по первым трем параметрам. Зарплаты сотрудников, работающих с SIEM-системой, зависят от слишком большого количества нюансов (целей и задач вашего отдела мониторинга — SOC, величины инфраструктуры, процессов), их в данной статье обсуждать не будем.
Стоимость лицензий
Сравнивая стоимость лицензий, стоит обратить внимание на следующее:
Как именно считается параметр, по которому происходит лицензирование?
Если это EPS, то считается ли он «на входе» или «на выходе» коллектора, уже после фильтрации и агрегации? Второй вариант будет заметно выгоднее.
Если это узлы — что именно понимается под хостом, как определяется их количество, как считаются виртуальные машины, сетевые устройства, межсетевые экраны?
В качестве метрики лицензирования учитывается пиковое или среднее значение параметра? За какой период?
Требуются ли дополнительные лицензии для установки дополнительных компонентов решения (коллектора, коррелятора, узлов базы данных)?
Что произойдет при превышении лицензии? По истечении срока лицензии?
Какой функционал входит в базовую лицензию, а что потребует приобретения дополнительных лицензий?
Аппаратное обеспечение
Некоторые SIEM-решения бывают весьма «прожорливыми» с точки зрения требуемого «железа». Требования к оборудованию становятся особенно важны в текущих условиях, когда его стоимость заметно повысилась, а доступность не гарантирована. Следует также учесть возможное масштабирование и как будут расти требования к «железу». Также важно, поддерживается ли работа решения в виртуальной инфраструктуре.
Стоимость технической поддержки
Доступ к технической поддержке может продаваться отдельно либо входить в стоимость лицензии ПО. В любом случае желательно обратить внимание на следующее:
Есть ли возможность выбрать уровень технической поддержки? Выбрав базовый, можно сэкономить, но более высокий уровень позволит обеспечить более оперативную реакцию вендора на тикет и/или включает дополнительные работы.
Есть ли гарантированное соглашение SLA для реагирования на запросы пользователей?
Предусмотрена ли возможность подключения специалистов вендора удаленно к инфраструктуре заказчика для решения проблем?
Выбор поставщика
Внедрение 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