SIEM без зрелости превращается в дорогой генератор тревог
Хороший SOC начинается с нормальной телеметрии и проработанных сценариев, а не с покупки платформы.
SIEM-системы продаются как решение задачи мониторинга безопасности. Подключите источники, настройте правила - и у вас будет видимость того, что происходит в инфраструктуре. Это правда, но неполная. Между "SIEM установлен" и "SIEM работает" лежит дистанция, которую многие компании не проходят.
Я видел несколько внедрений, где система работала - в том смысле, что собирала логи и генерировала алерты. Но в ответ на вопрос "что происходило в инфраструктуре три недели назад в понедельник в районе полуночи" команда смотрела в экран и пожимала плечами. Данные были, смысла из них извлечь не получалось.
Почему коробка не решает задачу
SIEM - это инструмент для обработки и корреляции событий. Чтобы он работал, нужно несколько вещей, каждая из которых требует отдельных усилий.
Во-первых, нужна хорошая телеметрия. Источники должны отдавать события в нужном объёме и формате. Слишком мало - не увидишь атаку. Слишком много - потонешь в шуме и пропустишь то же самое. Большинство организаций начинают с подключения всего, что есть, и получают именно шум. Какой сигнал можно извлечь из логов как источника данных, а не мусора ещё до появления SIEM - отдельная история.
Во-вторых, нужны правила корреляции, написанные под реальные сценарии атак в реальном окружении. Стандартный набор правил из коробки покрывает типовые сигнатуры, но не знает ничего о специфике вашей сети, ваших пользователях и ваших рисках. Чужие правила дают чужие тревоги.
В-третьих, нужны люди, которые умеют с этим работать. Алерт - это не инцидент, это сигнал для расследования. Расследование требует времени, экспертизы и понимания того, что является нормой в данной среде.
Что происходит без зрелости
Типичная картина: SIEM настроен, алертов много, команда быстро учится их игнорировать. Это не злой умысел - это естественная реакция на поток, который невозможно обработать осмысленно. Через несколько месяцев система работает "для галочки": логи пишутся, алерты копятся, реальный мониторинг не происходит.
Это не нейтральная ситуация. Она создаёт иллюзию защищённости при её отсутствии и обходится дорого - лицензии, железо, хранение логов.
Есть и другая сторона: компания, которая переоценивает покрытие SIEM, не инвестирует в другие меры - сегментацию, контроль привилегированного доступа, управление уязвимостями - полагая, что "SIEM смотрит". Метрики ИБ, которые реально что-то говорят руководству, напрямую с этим связаны: если KPI - «количество обработанных алертов», стимул настраивать систему правильно исчезает. Но он смотрит только туда, куда подключён, и только по тем сценариям, которые в него заложены.
С чего начинается настоящий мониторинг
Перед тем как думать о платформе, стоит ответить на несколько вопросов.
Какие источники событий у нас есть и что они реально отдают? Часто оказывается, что ключевые системы либо не пишут логи вообще, либо пишут в формате, из которого нельзя ничего извлечь без дополнительной работы.
Какие сценарии атак для нас наиболее актуальны? Это вопрос о модели угроз, а не о платформе. Перебор паролей, компрометация учётной записи администратора, утечка через электронную почту - это разные сценарии с разными индикаторами.
Кто будет реагировать на алерты и как быстро? Если ответа нет - алерты будут накапливаться.
Фильтр перед бюджетом
Прежде чем одобрять расходы на SIEM, стоит задать себе несколько вопросов:
- Есть ли у нас перечень критичных активов, события с которых должны мониториться в первую очередь?
- Написан ли хотя бы минимальный набор сценариев - что именно мы ищем и что считается аномалией?
- Есть ли выделенный ресурс для работы с алертами - человек или команда?
- Настроена ли базовая телеметрия на ключевых системах до подключения к SIEM?
- Как будет выглядеть успех через шесть месяцев - что именно должно улучшиться?
Если ответов нет - SIEM будет дорогим генератором тревог. Зрелость процессов, а не платформа - вот что определяет результат.