Solar Dozor 7.9 + MaxPatrol SIEM: настройка коннектора и правила корреляции для аномальной выгрузки

После того как разговор об оборотных штрафах за утечки ПДн перешёл из категории «когда-нибудь» в категорию «первое чтение Госдумы», у нескольких клиентов разом возник следующий вопрос: DLP стоит, события есть - но как это всё видит SIEM? Один из таких проектов - подключение Solar Dozor к MaxPatrol SIEM - мы завершили как раз к выходу версии 7.9, и по горячим следам фиксируем, что там оказалось нетривиальным.

Точка старта

Solar Dozor уже работал у клиента в режиме «наблюдаем, политики настроены, инциденты копятся в веб-интерфейсе». MaxPatrol SIEM стоял отдельно, кормился логами с сетевых устройств, AD, антивируса. Два инструмента в двух окнах - это не мониторинг, это иллюзия мониторинга.

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

Solar Dozor 7.9 объявил штатную поддержку двух каналов для интеграции с SIEM: Syslog в формате CEF и REST API. Теоретически - хорошо, практически - надо проверять.

Syslog CEF: настройка и подводные камни

CEF (Common Event Format) - формат, который MaxPatrol SIEM понимает нативно, и логически он кажется самым простым путём. В Solar Dozor настройка живёт в разделе интеграций: указываешь адрес SIEM-коллектора, порт, протокол (UDP или TCP - выбирайте TCP, если не хотите терять события при всплесках), уровень детализации событий.

Первая неожиданность - маппинг полей. CEF-заголовок содержит стандартные поля (deviceVendor, deviceProduct, name, severity), но DLP-специфика едет в extension-части, и там Solar Dozor кладёт собственные кастомные поля: имя пользователя, канал перехвата, классификатор политики, направление передачи. В MaxPatrol SIEM эти поля нужно описать вручную в нормализаторе - иначе они попадут в «сырой» текст события и на них нельзя будет строить условия в правилах.

Мы потратили время на то, чтобы выписать все кастомные поля из документации к Dozor 7.9, сопоставить с реальными событиями и прописать нормализацию. Итого нормализатор получился примерно на 40 полей - не огромный, но нудный.

Вторая неожиданность - временные метки. Solar Dozor пишет время в CEF по своему системному времени, но если NTP настроен кривовато (а на изолированных контурах это встречается), расхождение в несколько минут ломает корреляцию: события DLP и события AD про одного пользователя в одно время перестают «склеиваться». Проверяйте синхронизацию времени до начала, а не после.

REST API: когда нужно больше контекста

Syslog CEF - это поток событий в реальном времени. REST API Solar Dozor нужен для другой задачи: когда в SIEM сработало правило и аналитик хочет вытащить полный контекст инцидента - вложения, скриншоты перехваченного контента, историю нарушений конкретного пользователя.

Мы настроили интеграцию по второму сценарию: при создании инцидента в MaxPatrol SIEM правило автоматически делает запрос к REST API Solar Dozor и подтягивает расширенные данные по тому же событию. Технически это реализуется через action в правиле корреляции - MaxPatrol умеет делать HTTP-запросы во внешние системы.

Здесь важный момент: REST API Solar Dozor 7.9 требует авторизации по токену, токен нужно хранить в секрете, и его надо ротировать. Мы вынесли токен в переменные окружения коллектора, не в тело правила - иначе он окажется в конфигурации MaxPatrol в открытом виде.

Правила корреляции: аномальная выгрузка

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

Мы написали несколько правил. Базовые:

• Всплеск объёма исходящих событий от одного пользователя - если за 15 минут пользователь сгенерировал в N раз больше DLP-событий, чем его средний уровень за предыдущие 7 дней, это сигнал. Порог подбирается под конкретную среду: на первой неделе было много ложных срабатываний от пакетных операций.
• DLP-событие + вход с нового устройства в тот же день - корреляция событий Solar Dozor с событиями AD: если пользователь сегодня первый раз залогинился с новой машины и тут же начал копировать данные на флешку - это другой риск-профиль, чем обычный понедельник.
• Исходящий трафик через нетипичный канал - если пользователь обычно работает через корпоративную почту, а тут вдруг появляется событие по веб-почте или облачному хранилищу, Solar Dozor это фиксирует, MaxPatrol коррелирует.

Что не получилось сделать с первого раза: baseline на объём данных. MaxPatrol SIEM умеет хранить исторические значения для правил, но настройка этого механизма заняла больше времени, чем мы рассчитывали, - документация в этом месте скудноватая.

Что в итоге

Интеграция работает. События DLP видны в SIEM в реальном времени, правила корреляции срабатывают, аналитик видит инцидент с контекстом - не два окна, а одна картина.

Несколько наблюдений для тех, кто пойдёт тем же путём:

• CEF - проще для старта, но без правильного нормализатора вы получите «ящик с данными», а не структурированные события.
• REST API - для обогащения, не для потока; использовать его как основной канал при высокой интенсивности событий не стоит.
• Время на маппинг и нормализацию - реалистично закладывать столько же, сколько на саму техническую настройку коннектора.
• Правила корреляции - живой процесс: первые две недели после включения потребовали подстройки порогов, иначе аналитик тонет в ложных срабатываниях.

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