SIEM год спустя: первые correlation rules - и реальный брутфорс в первую же неделю

Год назад мы подняли SIEM и начали собирать логи. Целый год. Логи копились, индексировались, занимали место на дисках - и на этом, честно говоря, всё и заканчивалось. Смотреть в этот поток событий руками каждый день невозможно: тысячи строк в час с десятков источников. Без автоматической корреляции SIEM - это дорогой и медленный grep.

На прошлой неделе мы наконец сделали то, что давно откладывали: настроили первые correlation rules.

Почему год ушёл на «просто сбор»

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

Рынок SIEM-систем сейчас выглядит примерно так: ArcSight занимает верхний энтерпрайз-сегмент, IBM Tivoli SIEM активно продвигается в крупные компании, из отечественных есть несколько решений, которые стараются попасть в государственный сектор. Всё это недёшево и требует специалиста под задачу. У нас стоит решение попроще, но с нормальным движком корреляции.

Первое правило: три неудачных входа за минуту

Стартовали с самого очевидного. Правило выглядит примерно так: если с одного источника поступает три или более событий «authentication failed» в течение одной минуты на один и тот же хост - генерируем алерт с приоритетом «высокий» и отправляем уведомление дежурному.

Звучит просто. Реализация потребовала аккуратности:

• Агрегация по источнику. Три неудачных входа от трёх разных пользователей на три разных сервера - это не брутфорс, это обычный понедельник. Нужна группировка: один источник, одна цель.
• Исключение сервисных учёток. У нас есть несколько автоматизированных задач, которые периодически дают сбой и пишут ошибку входа. Если их не исключить - правило будет срабатывать на собственный мониторинг.
• Временное окно. Одна минута оказалась рабочим компромиссом. При пяти минутах брутфорс успеет попробовать слишком много вариантов; при тридцати секундах - начинали прилетать ложные срабатывания от плохо написанных скриптов авторизации.

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

Первая неделя - и сразу попадание

На четвёртый день после включения правила прилетел алерт. Внешний IP, множественные неудачные попытки входа по RDP на один из серверов в DMZ. Попытки шли с интервалом в секунды - явный автоматизированный перебор.

Посмотрели логи вручную: попытки шли около двадцати минут до того, как правило сработало (это уже второй вывод - первоначальный порог «три за минуту» мы поставили, но сам сеанс атаки начался раньше, просто первое время он шёл медленнее). IP из диапазона, который никак не связан ни с нашими клиентами, ни с партнёрами.

Действия были простыми: заблокировали IP через ACL на периметровом роутере. Попытки прекратились. Сервер RDP после инцидента проверили - следов успешного входа не обнаружили, пароли у тестовых учёток в DMZ были достаточно длинными, чтобы за двадцать минут брутфорса не подобраться.

Тем не менее факт неприятный: без правила мы бы этот инцидент просто не заметили. Логи были бы, алерта - нет.

Что это меняет в работе

Одно сработавшее правило за неделю - это не повод делать выводы о покрытии. Это повод делать следующие правила. В списке на ближайший месяц:

• Вход с нового географического источника для привилегированных учёток - пока без автоблокировки, только уведомление.
• Множественные неудачные входы с одного IP на разные хосты - это уже не забытый пароль, а горизонтальный скан.
• Изменение членства в группах AD - для быстрого обнаружения попыток эскалации привилегий.

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

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

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