Понедельник, 8:15 утра. В дашборде Splunk UBA - алерт: бухгалтер с десятилетним стажем за три часа выгрузила из 1С и корпоративного SharePoint 4.7 ГБ документов - в 12 раз больше дневной нормы. DLP молчит: файлы не выходят за периметр, антивирус чист, формат стандартный. Через два часа данные на личной флешке, через неделю - у конкурента. DLP-то зафиксировала копирование на USB, но алерт утонул в 300 аналогичных срабатываниях за день, из которых 295 - false positive. Разбор postmortem занял у SOC три дня, а ущерб компания считала полгода.
Эта история повторяется в каждом втором расследовании инсайдерского инцидента, в которых я участвовал за последние четыре года. По данным Vectra AI, средний ежегодный ущерб от инсайдерских инцидентов достиг $19.5 млн на организацию. Проблема не в отсутствии инструментов - DLP и SIEM работают изолированно, без поведенческого слоя, который связывает разрозненные события в цепочку.
Почему DLP система без поведенческой аналитики слепа к инсайдерам
DLP видит контент и канал передачи. Срабатывает, когда документ с грифом "конфиденциально" уходит на личную почту или копируется на USB. Но инсайдер, проработавший в компании три года, знает, какие файлы помечены грифом, - переименовывает документ, копирует данные в обычный Excel, выносит через корпоративный мессенджер. DLP-система защиты от инсайдеров в таком сценарии бессильна.User Entity Behavior Analytics решает другую задачу: не "что передаётся", а "кто ведёт себя нетипично". Система строит baseline поведения пользователя и каждой сущности - рабочей станции, сервисного аккаунта, VPN-соединения - и детектирует отклонения. Сотрудник маркетинга, впервые за год полезший в финансовые базы в 2 часа ночи, - аномалия, которую UEBA зафиксирует, даже если конкретный файл не содержит маркеров DLP.
С точки зрения MITRE ATT&CK типичная инсайдерская цепочка выглядит так: легитимные учётные данные - Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion). Дальше сбор: Data from Local System (T1005), Data from Network Shared Drive (T1039), Data from Information Repositories (T1213), Data from Removable Media (T1025) - всё Collection. Exfiltration - USB (T1052.001) или облачные сервисы (T1567). Грамотный инсайдер ещё и чистит следы - Indicator Removal (T1070).
DLP поймает T1052.001 или T1567, но только если канал и контент описаны в политике. Поведенческая аналитика пользователей выявит отклонение от baseline уже на этапе T1005/T1039 - когда сотрудник только начинает массовый сбор данных. За дни или недели до exfiltration.
Построение baseline: какие источники подключать первыми
Мониторинг аномалий пользователей работает ровно настолько хорошо, насколько полны данные на входе. Разворачивать UEBA без правильных источников - как запускать корреляцию в SIEM без логов. По рекомендациям Security Boulevard (на которые ссылается Vectra AI), baseline формируется за 60–90 дней наблюдения. Это не пассивное ожидание: за этот период система должна набрать достаточный объём событий для статистически значимых профилей каждого пользователя и сущности.
Минимальный набор источников для AD-среды
Первый и критический источник - события Active Directory. Без них поведенческая модель слепа:- Event ID 4624 (Successful Logon) - время, тип логина (interactive, network, remote interactive), исходная рабочая станция. Фундамент для baseline «когда и откуда работает пользователь»
- Event ID 4625 (Failed Logon) - брутфорс, попытки подбора, использование чужих учёток
- Event ID 4648 (Logon using explicit credentials) - маркер credential misuse: сотрудник явно использует не свои credentials
- Event ID 4672 (Special privileges assigned) - назначение привилегий, нехарактерное для роли
- Event ID 4663 (Object access attempt) - обращения к файлам и каталогам при включённом аудите объектов
Третий - VPN и прокси-логи. Гибридная работа размывает baseline, и без данных о VPN-сессиях UEBA будет генерировать false positive на каждое изменение IP. По данным Exabeam, гибридные среды - одна из главных причин blind spots при обнаружении инсайдерских угроз: сотрудник может выгрузить данные в личный OneDrive, не касаясь корпоративной сети.
Четвёртый - события облачных сервисов: Microsoft 365 Unified Audit Log, Google Workspace Activity Log. Без этого слоя UEBA не видит T1567 (Exfiltration Over Web Service). По моему опыту, этот канал инсайдеры выбирают чаще USB - не нужен физический носитель, и в логах это выглядит как обычная работа с облаком.
Peer group analysis вместо "средней по больнице"
Дефолтная настройка UEBA в большинстве продуктов сравнивает пользователя с общей популяцией. Результат - хаос: DBA, выполняющий 500 SQL-запросов в день, выглядит аномально на фоне всей компании, но абсолютно нормально среди коллег-администраторов. Peer group analysis решает эту проблему: система сравнивает сотрудника с группой, имеющей аналогичную роль, уровень доступа и паттерн работы.В Splunk UBA peer group настраивается через
peer_group_config с привязкой к атрибутам AD - department, title, manager. В Microsoft Sentinel UEBA peer group формируется автоматически из данных Entra ID (Azure AD), но требует ручной валидации. На одном проекте я обнаружил, что HR и финансовый отдел оказались в одной peer group из-за схожих паттернов логинов - обе группы работали с 9 до 18, использовали один набор корпоративных приложений. Baseline был искажён, и аномальные обращения финансистов к кадровым базам оставались незамеченными. Вот так одна ошибка в группировке убила весь detection pipeline.Практическое правило: если UEBA генерирует больше 50 алертов в день после настройки peer groups - группы сформированы криво.
Корреляционные правила для детектирования аномального поведения сотрудников
Настройка UEBA в SIEM строится через цепочку: raw events -> normalization -> correlation rules -> risk scoring -> alert. Ниже - конкретные корреляции, которые дают результат на реальной инфраструктуре.
Аномальный объём выгрузки данных
Splunk SPL - детектирование аномального количества обращений к файлам за скользящее окно:
Код:
index=wineventlog earliest=-30d EventCode=4663 object_category=file
| bucket _time span=1h
| stats count as file_access_count by user, department, _time
| eventstats avg(file_access_count) as avg_access,
stdev(file_access_count) as stdev_access by user, department
| where file_access_count > (avg_access + 3*stdev_access)
AND _time > relative_time(now(), "-24h")
| table _time, user, department, file_access_count, avg_access3*stdev - стартовая точка. Для peer group бухгалтерии стандартное отклонение будет одно, для разработчиков - другое. Без разделения по peer group это правило даёт до 80% false positive в первую неделю. Добавление by department в eventstats радикально снижает шум.Первое обращение к нехарактерному ресурсу
Microsoft Sentinel (KQL) - обнаружение новых паттернов доступа, которых не было в истории за 30 дней:
Код:
let lookback = 30d;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4663
| summarize AccessCount=count() by TargetAccount, ObjectName
| where AccessCount > 10
| join kind=leftanti (
SecurityEvent
| where TimeGenerated between(ago(lookback)..ago(24h))
and EventID == 4663
| distinct TargetAccount, ObjectName
) on TargetAccount, ObjectNameПересечение DLP-алерта и поведенческой аномалии
Самая ценная корреляция - intersection DLP-события и UEBA-аномалии:- DLP генерирует событие: попытка отправки файла на личную почту (severity: medium)
- UEBA фиксирует: тот же пользователь за последние 48 часов обращался к ресурсам, нехарактерным для его роли
- Корреляционное правило повышает приоритет инцидента до critical
Мониторинг привилегированных пользователей
Обнаружение инсайдерских угроз от привилегированных пользователей - отдельный detection pipeline. Администратор домена, обращающийся к контроллеру домена в 3 часа ночи, может выполнять плановое обслуживание, а может экспортировать NTDS.dit. Стандартная поведенческая аналитика тут буксует: baseline привилегированных аккаунтов слишком широкий.
Решение - интеграция UEBA с PAM. CyberArk, Indeed PAM или аналог фиксирует: сессия привилегированного доступа открыта через change request, запланирована с 02:00 до 04:00, объём работ - обновление GPO. Если UEBA видит в этом окне экспорт базы AD - это аномалия, даже если baseline формально допускает ночной доступ. PAM даёт контекст, без которого UEBA просто не отличит легитимную работу от выноса данных.
В Splunk UBA привилегированные аккаунты выделяются в отдельную watchlist с пониженными порогами: для обычного пользователя аномальным считается отклонение в 3 sigma, для привилегированного - в 2. В Microsoft Sentinel для мониторинга привилегированных пользователей работает связка Identity Protection (user risk / sign-in risk) + Sentinel UEBA (Investigation Priority Score), где сигналы Identity Protection поступают через коннектор и используются в analytics rules для повышения приоритета инцидента. В Securonix для этого есть prebuilt policy "Privileged Account Abuse" с детектированием lateral movement по Event ID 4648.
Detection-чеклист: настройка UEBA в SIEM для обнаружения инсайдеров
Готовый чеклист - можно передавать в SOC или включать в playbook по insider threat detection:Пункты 1–3 маппятся на NIST CSF v2.0 DE.AE-01 (baseline of network operations and expected data flows). Пункты 4–6 - на RS.AN-01 (notifications from detection systems are investigated). Пункт 7 - на PR.AA-01 (identity management and access control).
После первичной настройки соотношение true positive к false positive обычно 1:10–1:20, зависит от зрелости данных. После двух-трёх итераций тюнинга peer groups и порогов - 1:3 или лучше. По данным ISA Global Cybersecurity Alliance (на которые ссылается Vectra), ML-модели UEBA при корректной калибровке снижают false positive на 60% по сравнению с rule-based подходом.
Главная ошибка при внедрении UEBA для обнаружения инсайдеров - ждать результатов в первый месяц. Система без baseline - генератор мусора. На одном проекте я видел, как UEBA отключили через три недели из-за потока нерелевантных алертов, а через два месяца случился реальный инцидент с exfiltration через личный Google Drive. Никто не заметил.
Вторая ошибка - изоляция UEBA от остального стека. Поведенческая аналитика в отдельной консоли, куда аналитик заглядывает раз в день, - бесполезна. UEBA-скор пользователя должен быть виден в том же дашборде, где SIEM показывает алерты DLP и EDR. Если для проверки аномалии нужно открывать три разных интерфейса - инцидент расследуется постфактум, когда данные уже ушли.
Прогноз, за который готов отвечать: через полтора-два года standalone UEBA-продукты окончательно уйдут с рынка. Авива Литан из Gartner предсказывала это ещё для 2025 года, и тренд подтверждается: Splunk интегрировал Caspida ещё в 2015-м, а в 2024-м сам был поглощён Cisco; Exabeam вырос из UEBA-стартапа в полноценную SIEM-платформу; Microsoft встроил UEBA в Sentinel, российские вендоры - Security Vision, MaxPatrol SIEM, Solar Dozor - идут тем же курсом. UEBA как отдельная "коробка" - мёртвая концепция. Но UEBA как аналитический слой внутри SIEM - необходимость для любой команды, которая работает над обнаружением инсайдерских угроз. Если у вас другой стек детекции и вы адаптируете подобные корреляции под свою инфраструктуру - на codeby.net есть тред по insider threat detection, где обсуждаем конкретные Sigma-правила и делимся опытом тюнинга под разные SIEM.
Последнее редактирование:
