Востребованность систем анализа ИБ-событий и управления ими в последнее время растет. Связано это с тем, что без контроля происходящего внутри периметра компании невозможно быть уверенным в надёжности и эффективности смежных систем и процессов защиты. В этой статье эксперт 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
![Версия для печати Версия для печати](https://www.kv.by/sites/all/modules/print/icons/print_icon.png)
Горячие темы