SIEM и корреляция событий: как цепочка из трёх событий нашла инсайдера

После того как весной мы развернули Splunk для одного из клиентов и убедились, что агрегация логов - это полезно, следующим логичным шагом стал переход к корреляции. Splunk отлично ищет по логам и строит дашборды, но написать правило «если в течение десяти минут произошло A, потом B, а за ним C - это подозрительно» в нём можно, но неудобно. Для этого нужен настоящий SIEM с движком корреляции.

Разговор про SIEM среди клиентов заметно оживился после первого квартала 2013-го. APT-атаки - целенаправленные, терпеливые, без грубых инструментов - начали всплывать в отчётах Mandiant, в прессе, в разговорах с безопасниками. Классическая история: атакующий сидит в сети месяцами, делает всё медленно и аккуратно, а отдельные события выглядят безобидно. Только в связке они складываются в картину. Вот тут корреляция и нужна.

Выбор и интеграция

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

Интеграция заняла две недели - и это при том, что логи мы уже собирали через Splunk, просто перенаправили часть потоков на SIEM-коллекторы параллельно. Основная работа - написать нормализаторы для тех источников, под которые нет готовых коннекторов. Active Directory и Windows Event Log подключились быстро, корпоративный VPN-шлюз потребовал кастомного парсера.

Про правила корреляции

Вот тут и начинается самое интересное. SIEM из коробки приходит с набором готовых правил - в основном стандартные: многократные неудачные входы, вход с нового географического региона, изменение привилегий. Это полезно, но не это отличает SIEM от просто «хранилища логов с алёртами».

Настоящая ценность - в цепочках. Несколько событий по отдельности не говорят ничего, но в последовательности внутри окна времени они становятся сигналом. Мы потратили первую неделю на проектирование правил, специфичных для инфраструктуры клиента.

Одно из правил выглядело так. Цепочка из трёх элементов:

1. Brute force на учётную запись - более N неудачных попыток входа за M минут с одного источника.
2. Успешный вход той же учётной записью - в течение часа после завершения брутфорса.
3. Массовый доступ к файловому серверу или экспорт данных - большой объём операций чтения/копирования файлов этой же учёткой в течение следующих двух часов.

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

Что произошло на третьей неделе

На третьей неделе после запуска SIEM сработал ровно на это правило.

В три часа ночи началась серия неудачных попыток входа под учётной записью одного из сотрудников отдела продаж - человек работал в компании больше двух лет, ничем особым не выделялся. Попытки шли не с внешнего адреса, а с внутреннего IP - с одной из рабочих станций в офисе. Через сорок минут - успешный вход. Ещё через полтора часа - учётка открыла несколько сотен файлов на общем файловом сервере, включая папки, к которым этот сотрудник в рабочее время почти не обращался: договоры, ценовые таблицы, клиентская база в формате Excel.

SIEM сгенерировал инцидент. В восемь утра дежурный безопасник его увидел.

Разобрались за день. Человек действительно сидел ночью в офисе. Формально не нарушил ни один технический контроль - у него были права на эти файлы. Но контекст - время, объём, тип данных - был нехороший. На разговоре выяснилось, что он уже договорился о переходе к конкуренту и собирал материалы. Увольнение оформили с соответствующими условиями.

Что это значит для правил

Несколько наблюдений по итогу.

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

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

Права - не достаточный контроль. Факт наличия прав на файлы не делает любое обращение к ним нормальным. SIEM позволяет смотреть на поведение, а не только на то, разрешено ли оно технически.

Ложные срабатывания были. Это важно признать. За первые три недели правило на брутфорс срабатывало несколько раз на пользователей, которые просто забыли пароль после отпуска. Мы скорректировали порог и добавили исключение для случаев, когда попытки идут в рабочее время с рабочей станции пользователя. Тюнинг - это не неудача, это нормальная часть процесса.

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