Как поймать то, чего нет в правилах: поведенческая аналитика (UEBA) поверх Security Data Lake

Введение и проблематика

В предыдущих частях мы построили Озеро данных информационной безопасности (Security Data Lake, SDL) и навели в нём порядок: объединили разрозненные источники ИБ в единую платформу на базе Kafka, Airflow и ClickHouse, а затем описали все объекты хранилища каталогом данных OpenMetadata. Данные стали доступными и понятными — известно, откуда взялась каждая таблица, кто её владелец и какой DAG её формирует.

Но доступные данные — это ещё не выявленные угрозы. Когда события собраны в одном месте, возникает следующий вопрос: как среди миллионов записей заметить те, что указывают на проблему?

В классическом подходе информационная безопасность строится вокруг правил. Если произошло событие, совпавшее с заранее описанным условием, система создаёт оповещение (alert). Это хорошо работает для известных сценариев: подозрительный вход, серия ошибок авторизации, запуск запрещённого процесса, обращение к критичной системе.

У этого подхода есть слабое место: не всё опасное поведение выглядит как очевидная атака. Иногда пользователь действует «легально» — у него есть доступ, он проходит авторизацию, работает с корпоративными ресурсами. Формально всё нормально. Но если посмотреть на поведение в динамике, видно: человек начал делать не то, что обычно. Не в то время, не из того места, не с теми системами, не в том объёме.

Именно здесь появляется UEBA (User and Entity Behavior Analytics) — поведенческая аналитика пользователей и сущностей. Это подход, при котором система анализирует не отдельное событие само по себе, а поведение пользователя, устройства или сервиса относительно привычной картины. Главная идея проста: если мы понимаем, как объект обычно ведёт себя в инфраструктуре, мы быстрее заметим момент, когда он начал вести себя странно.

Ключевой принцип

UEBA не заменяет SIEM (систему управления событиями безопасности, Security Information and Event Management) — она отвечает на другой вопрос. Если SIEM отвечает «сработало ли правило?», то UEBA спрашивает: «похоже ли это поведение на обычное для данного пользователя или объекта?». SIEM остаётся центральной точкой сбора, корреляции, хранения событий и расследования инцидентов. UEBA дополняет его поведенческим слоем: SOC-команда (центр мониторинга кибербезопасности, Security Operations Center) получает не просто поток событий, а приоритизированную картину — какие отклонения стоит посмотреть в первую очередь.

Проблематика

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

• сотрудник внезапно начал обращаться к системам, с которыми раньше не работал;
• учётная запись стала активна в нетипичное время;
• устройство начало вести себя не так, как остальные похожие устройства;
• сервисная учётная запись начала выполнять нехарактерные для неё операции;
• пользователь резко изменил объём активности.

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

Что сделали

Мы построили UEBA-процесс поверх событий безопасности, уже собранных в SDL. Важно: это отдельный слой поведенческой аналитики, который читает историю из ClickHouse и возвращает оценку риска — он не вмешивается в движение данных и не заменяет существующие компоненты.

Сначала система собирает исторические данные. Тип событий здесь не важен — это могут быть события авторизации, сетевой активности, доступа к ресурсам, действий с процессами или другие логи. Дальше данные приводятся к общему виду (нормализуются): кто совершил действие, когда, где, с каким объектом, насколько часто и насколько это похоже на прошлое поведение.

После этого формируются признаки (features) — сырые события превращаются в понятные характеристики поведения:

• как часто объект действует;
• в какое время обычно проявляет активность;
• насколько поведение отличается от своей истории;
• похож ли объект на свою группу;
• появились ли новые направления активности;
• вырос ли объём действий;
• есть ли резкое изменение привычного сценария.

Затем модель проходит этап обучения (fit) — учится на нормальной исторической картине. Модель не обязана заранее знать, где атака. Она учится понимать, что для объекта или группы объектов выглядит обычно, а что выбивается из общей картины. После обучения новые события сравниваются с поведенческой нормой, построенной за выбранный исторический период. Если поведение сильно отличается, оно получает высокий риск и может быть передано дальше: в интерфейс аналитика, в SIEM, в Kafka или другой контур обработки для более детального анализа.

Поиск аномалий

Для такой задачи хорошо подходит Isolation Forest (изолирующий лес), потому что он работает с аномалиями без необходимости заранее размечать каждое событие как «атака» или «не атака».

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

Isolation Forest решает задачу иначе: он ищет объекты, которые проще «отделить» от общей массы данных. Если поведение сильно отличается от привычного, модель считает его более подозрительным. Модель можно обучать на истории, добавлять новые признаки и настраивать пороги для повышения качества оценки, регулярно обновлять и использовать как слой поведенческого скоринга.

Почему это полезно бизнесу, ИТ и подразделениям безопасности

Главная ценность UEBA — не в том, что «мы добавили ML». Сам по себе машинный анализ никого не спасает. Польза появляется тогда, когда он помогает быстрее принимать решения. Что даёт такой подход:

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

То есть UEBA помогает перейти от реакции на заранее известные признаки к анализу поведения.

Что получилось в итоге

В результате получается не просто набор технических детектов, а отдельный слой поведенческой аналитики. Он смотрит на события шире: не «это плохое событие или хорошее?», а «насколько это поведение похоже на нормальное?».

Подход применим к разным сценариям, не привязываясь только к авторизации. Авторизация — лишь один из примеров. Та же логика подходит для активности пользователей, процессов, устройств, сервисных учётных записей, сетевых взаимодействий и доступа к ресурсам.

Сценарий 1. Скомпрометированная учётная запись

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

Сценарий 2. Внутренний пользователь начал действовать нестандартно

Сотрудник имеет легальный доступ к корпоративным системам. Формально он ничего не «взламывает». Но его поведение меняется: он чаще обращается к данным, с которыми раньше почти не работал, увеличивает объём действий и выходит за привычный рабочий контекст. Для обычного правила это сложный случай: доступ разрешён, ошибки нет. Для UEBA это понятный сигнал: объект стал вести себя не так, как раньше.

Сценарий 3. Странное поведение сервиса или устройства

Поведенческий анализ (UEBA) применим не только к людям. Сервисная учётная запись обычно выполняет однотипные операции по расписанию. Если она внезапно начинает обращаться к новым направлениям или менять частоту действий — это может быть важным сигналом. То же с устройствами: если рабочая станция, сервер или другой объект начинает вести себя не как похожие объекты в своей группе, это повод обратить внимание.

Выводы и результаты

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

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

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