SIEM для финансового клиента: первая неделя Splunk и паттерн, который не видел ни один антивирус

Клиент - небольшой финансовый посредник, около двухсот рабочих мест, куча регуляторных требований и хроническая уверенность в том, что «у нас с безопасностью всё нормально, антивирус стоит везде». Поводом для разговора послужила не конкретная угроза, а скорее нервозность после нескольких громких историй в прошлом году: утечки из банков, компрометации платёжных систем. Клиент хотел понять, что вообще происходит у него внутри сети на уровне событий. Мы предложили пилот на базе Splunk.

Почему Splunk, а не ArcSight

На рынке сейчас два очевидных имени в этом классе решений: ArcSight и Splunk. ArcSight - это серьёзная корпоративная платформа с лицензированием, которое само по себе требует отдельного бюджета и согласования. Для пилота у клиента такого бюджета не было, да и не факт что нужно: ArcSight хорош когда понятно что именно коррелировать и зачем. Splunk 3.x позволяет начать быстрее - загружаешь данные, смотришь что есть, строишь поиски. Лицензия на небольшой объём данных в день укладывается в разумные деньги для пилота.

Архитектура получилась простой: форвардеры на ключевых серверах и рабочих станциях (Windows Event Log, IIS-логи, логи AD-контроллеров), всё сливается в один индексер на отдельной машине. Источники логов к тому моменту у клиента уже были централизованы через syslog-ng на Linux-части - оттуда подключились напрямую.

Первая неделя: настройка и первый сигнал

Первые три дня ушли на то, чтобы разобраться с форматами. Windows-события в Splunk 3.x разбираются через конфиги в props.conf и transforms.conf - это не автоматика, надо руками описывать поля для каждого типа событий, которые интересны. Для Event ID 4624 (успешный вход), 4625 (неуспешный), 4648 (вход с явными учётными данными) - написали отдельные извлечения полей. Без этого получаешь просто строки, поиск работает, но корреляции нет.

На четвёртый день начали строить первые запросы. Один из базовых - статистика входов по времени суток в разрезе учётных записей. Ничего хитрого: sourcetype=wineventlog EventCode=4624 | eval hour=strftime(_time, "%H") | stats count by user, hour. Запустили, посмотрели на тепловую карту.

Картина оказалась интересной. Большинство пользователей - ожидаемо, с 8 до 19, небольшой хвост до 21. Но несколько учётных записей давали регулярные входы в 2-4 ночи. Не разовые - систематические, несколько раз в неделю, каждый раз с одного и того же IP внутри сети.

Что это оказалось

Первая версия - служебные задачи, скрипты, что-то автоматическое. Проверили: у задействованных учёток не было расписаний, задач планировщика, ничего похожего. Обычные пользователи операционного отдела.

Связались с отделом безопасности клиента. Те поначалу пожали плечами: «ну может задержались». Мы показали статистику - конкретные даты, конкретное время, конкретный внутренний IP. IP оказался закреплён за одной из рабочих станций в офисе.

Дальше клиент разбирался сам - это уже их внутренняя история. Нашу задачу мы выполнили: обнаружили паттерн, который никакой антивирус не увидел бы в принципе. Антивирус ловит известные сигнатуры на конкретной машине. Легитимный вход с легитимными учётными данными в нестандартное время - это не вредоносный код, это аномалия в поведении. Её видно только когда смотришь на события в совокупности и в динамике.

Что показал пилот

Несколько выводов, которые стоит записать.

Корреляция требует контекста. Splunk сам по себе не даёт ответов - он даёт данные для вопросов. Запрос «покажи мне подозрительное» не работает. Нужно знать что именно считать подозрительным: аномальное время, нетипичный источник, неожиданная последовательность событий. Это надо формулировать руками.

Первые три источника важнее тридцати остальных. Контроллер домена (AD-события) + VPN-концентратор + рабочие станции дают 80% картины для большинства сценариев. Подключать всё сразу - быстро упереться в лимит индексирования и утонуть в шуме.

Время - ключевое измерение. Большинство аномалий видны не в отдельном событии, а в паттерне по времени. Это банально звучит, но пока не построишь первый такой запрос и не увидишь результат - не ощущается на практике.

Антивирус и SIEM решают разные задачи. Клиент воспринимал антивирус как универсальное средство. После пилота это восприятие поменялось. Аудит информационной безопасности - это не «поставить ещё один продукт», это выстроить видимость того, что происходит в инфраструктуре. Antivirus - это один из источников сигналов, не вся картина.

Где сейчас

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

ArcSight мы тоже смотрели в рамках оценки - там корреляционные правила пишутся в отдельном редакторе, более структурированно, но и порог входа выше. Для клиента, который только начинает строить процесс, Splunk с его поисковым подходом оказался более подходящим стартом. Это не оценка «лучше или хуже» - просто разные точки входа в один и тот же класс задач.

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