Как выбрать SIEM: критерии, сценарии и чек-лист

Сначала определите задачи мониторинга и применимые требования к своему контуру. Измерьте поток событий, составьте перечень обязательных источников и сценариев. Проверьте их на пилоте вместе с процессом реагирования. После этого сравните состав поставки, инфраструктуру и стоимость эксплуатации при одинаковых исходных условиях.

SIEM (Security Information and Event Management) собирает события безопасности из источников по всей инфраструктуре — серверов, сетевого оборудования, СУБД, приложений и средств защиты, — приводит их к единому формату, коррелирует между собой и выявляет инциденты, которые не видны ни в одном источнике по отдельности. Это центральный инструмент SOC: без него аналитик видит разрозненные логи, с ним — цепочку событий, складывающуюся в конкретную атаку.

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

Список конкретных продуктов и их сравнение по вендору, реестру и покрытию — на странице класса SIEM.

Ниже — критерии, которые стоит проверять у любого кандидата, независимо от вендора. Вес каждого критерия меняется в зависимости от сценария — это разобрано в следующем разделе.

Один и тот же продукт может быть избыточным для одной компании и недостаточным для другой — вес критериев зависит от того, кто и зачем внедряет систему.

1. Зафиксируйте применимые требования к системе, форму оценки соответствия и условия закупки; проверьте документы выбранной поставки.
2. Измерьте средний и пиковый поток событий, размеры сообщений и прогноз роста на согласованный горизонт эксплуатации.
3. Составьте список источников событий и сверьте его со списком готовых коннекторов у каждого кандидата.
4. Проверьте, обновляются ли правила корреляции автоматически или требуют ручной доработки.
5. Уточните, нужна ли интеграция с ГосСОПКА, и поддерживает ли её продукт «из коробки».
6. Проверьте наличие готовой интеграции с SOAR/IRP, если она есть в контуре или планируется.
7. Оцените модель лицензирования — по EPS, по источникам или по объёму хранения — и её поведение при росте нагрузки.
8. Сравните TCO на одинаковом горизонте: лицензии, инфраструктура, внедрение, обучение, сопровождение и обновления. Стоимость продления поддержки и перехода на новые версии уточните в предложении.
9. Уточните SLA техподдержки вендора и наличие сертифицированных партнёров-интеграторов в вашем регионе.
10. Проверьте, достаточно ли у своей команды экспертизы для эксплуатации, или потребуется MSSP/аутсорс SOC.
11. Запросите пилот или демо-стенд на реальном объёме своих источников, а не на синтетических данных вендора.
12. Сверьте срок действия сертификата ФСТЭК выбранного продукта в госреестре СЗИ ФСТЭК перед подписанием договора.

• Учитывать только средний EPS. Пики, изменения источников, правила и запросы аналитиков могут влиять на нагрузку. Проверяйте условия лицензирования и производительность при согласованном профиле.
• Проверять документы после выбора продукта. Требования к оценке соответствия, версии, исполнению и закупке нужно определить до заключения договора, чтобы не обнаружить несовместимость поставки с требованиями контура.
• Недооценивать экспертизу, нужную для эксплуатации. Мощный SIEM с богатой аналитикой без аналитика, способного писать и тюнить правила корреляции, превращается в дорогое хранилище логов с постоянным потоком ложных срабатываний.
• Сравнивать продукты только по списку функций из презентации. Наличие модуля UEBA или SOAR в маркетинговых материалах не гарантирует, что он реально закрывает задачу без доработки под конкретный ландшафт — это стоит проверять на пилоте.
• Не учитывать внедрение и сопровождение. Сравнивайте полный состав затрат при одинаковых исходных условиях; доля лицензии зависит от проекта и не может быть назначена заранее.

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

Смежные классы, которые часто внедряют вместе с SIEM: EDR — источник событий и точка реагирования на конечных точках, VM (управление уязвимостями) — контекст для приоритизации инцидентов, IDS/IPS — сетевой источник событий для корреляции. Для субъектов КИИ регуляторные требования к системе безопасности разобраны в разделе «КИИ» на SecRadar.