SIEM-дашборд зелёный, корреляционные правила отрабатывают штатно. Ранним утром UEBA-модуль поднимает risk score до 87 для сервисной учётной записи svc_backup: в 02:38 она аутентифицировалась через VPN с IP-адреса, который ни разу не фигурировал в её профиле, после чего за 12 минут выполнила 340 LDAP-запросов к объектам Active Directory. Ни одно сигнатурное правило не сработало - учётка валидная, VPN-подключение легитимное, LDAP-запросы по отдельности безобидны. Без поведенческого baseline эта активность выглядит как штатная работа сервиса. С baseline - как Account Discovery (T1087) в начальной фазе lateral movement.
Разница между двумя интерпретациями - несколько часов или несколько недель незамеченного присутствия атакующего в инфраструктуре.
Почему сигнатурный подход слепнет: цифры и kill chain
По данным CrowdStrike Global Threat Report 2025, основная масса детектов были malware-free - атакующие использовали легитимные утилиты, украденные токены и штатные инструменты администрирования. Из того же отчёта: вредоносное использование GenAI для социальной инженерии и фишинга удвоилось за год. IBM X-Force подтверждает - AI-генерированные фишинговые письма создаются в 11,4 раза быстрее при сопоставимом качестве. Подробнее - в нашем подробном разборе обнаружение apt атак.Для сигнатурных правил это тупик. Нет вредоносного файла - нет хеша, нет IOC в классическом понимании. Атакующий входит с валидным паролем, использует
net.exe для разведки, WMI для перемещения, а cmd.exe для выполнения команд. Каждое действие по отдельности - штатная работа системного администратора.Бизнес-логика типичной атаки: начальный доступ через фишинг с украденными учётными данными -> разведка доменной инфраструктуры (Account Discovery) -> повышение привилегий -> горизонтальное перемещение -> вывод данных. На каждом этапе атакующий пользуется легитимными инструментами, и сигнатурные правила молчат. По данным IBM X-Force, 70% атак в 2024 году затронули критическую инфраструктуру. Облачные вторжения выросли на 26% год к году (CrowdStrike 2025) - поток первичных компрометаций растёт, а нагрузка на SOC вместе с ним.
Эту проблему и решает поведенческий анализ угроз UEBA: вместо поиска известных сигнатур система строит модель нормального поведения каждого пользователя и сущности, а затем детектит отклонения от неё.
UEBA система обнаружения угроз: архитектура и baseline
Источники данных и построение поведенческих профилей
User Entity Behavior Analytics агрегирует данные из нескольких классов источников. Полнота тут - критическое условие: UEBA с неполными данными строит кривой baseline и генерирует шум вместо алертов.| Класс данных | Примеры источников | Что даёт для baseline |
|---|---|---|
| Аутентификация | Active Directory (Event ID 4624, 4625, 4769), VPN, SSO | Паттерны входа: время, геолокация, устройство |
| Сетевая активность | NetFlow, DNS-логи, прокси | Типичные направления трафика, объёмы |
| Endpoint-телеметрия | CrowdStrike Falcon, Elastic Agent 8.x+, SentinelOne | Запускаемые процессы, parent-child chains |
| Приложения | Exchange / M365, файловые серверы, 1С, СУБД | Доступ к ресурсам, объёмы скачивания |
| HR-контекст | CMDB, кадровые системы | Роль, отдел, дата приёма/увольнения |
Период обучения baseline - один из самых недооценённых факторов. Трёх недель хватает для первичных профилей, но этого мало для учёта бизнес-циклов: квартальные отчёты, сезонные всплески, ротация сотрудников. NIST CSF 2.0 закрепляет этот принцип в контроле DE.AE-01: "baseline сетевых операций и ожидаемых потоков данных для пользователей и систем устанавливается и управляется".
Теперь конкретика по вендорам - потому что возможности UEBA принципиально различаются в зависимости от платформы:
Splunk UEBA использует peer group analysis: сравнивает поведение пользователя не только с его собственной историей, но и с паттернами группы аналогичных ролей. Интегрируется с Splunk Enterprise Security через CIM-модель данных. Можно создавать кастомные ML-модели поверх стандартных - и вот тут начинается реальная ценность, потому что дефолтные модели редко покрывают специфику конкретной инфраструктуры.
Microsoft Sentinel Entity Behavior Analytics - нативно интегрирован с Azure AD и M365. Предоставляет предустановленные ML-модели для шести категорий аномалий: необычный логин, необычный доступ к ресурсам, аномальный объём операций, нетипичное использование учётных данных, lateral movement, data exfiltration. Baseline обновляется автоматически. Удобно, если вы уже живёте в Azure-стеке; если нет - тянуть за собой зависимость от облака Microsoft ради одного UEBA модуля смысла мало.
Elastic Security ML Jobs (Elastic 8.x+) - unsupervised ML для аномалий в сетевом трафике и аутентификации. Требует настройки ML jobs через Kibana; из коробки даёт pre-built jobs для rare process execution, unusual network destinations и DNS anomalies. По моему опыту, Elastic требует больше ручной работы на старте, но зато даёт максимальную гибкость в кастомизации.
Из российских решений: MaxPatrol SIEM (Positive Technologies) содержит встроенный UEBA-модуль, анализирующий поведение пользователей и хостов на основе событий из коллекторов. R-Vision UEBA - отдельная платформа непрерывного мониторинга поведенческих аномалий. Оба решения активно развиваются на фоне перехода на отечественный стек.
Risk scoring: как не утонуть в false positives
Risk scoring - центральный механизм UEBA. Каждому событию присваивается балл на основе степени отклонения от baseline. Баллы аккумулируются по сущности (пользователь, хост, сервисная учётка) за временное окно.Принцип простой: одиночное аномальное событие - низкий балл (5-15 из 100). Аномальное время входа + нетипичный IP + обращение к ранее не используемым ресурсам = кумулятивный балл 75+, что пробивает порог алерта.
Проблема - ложные срабатывания. Без тюнинга UEBA быстро превращается в генератор игнорируемых алертов. Я видел это не раз: модуль включили, две недели смотрели, потом забили.
Практические рекомендации по тюнингу:
- Сервисные учётки - в отдельную peer group. Их поведение принципиально отличается от пользовательского: svc-аккаунт генерирует тысячи запросов в минуту, и это нормально. Но один интерактивный логин через RDP - аномалия максимального приоритета.
- Плановые события - в исключения. Патч-тьюсдей, бэкап-окна, миграции - все предсказуемые всплески размечаются как planned activity, иначе каждый вторник генерирует волну алертов.
- Decay-формула для старых аномалий. Если пользователь один раз залогинился из нового города - через 30 дней этот факт должен весить меньше свежего отклонения. Без decay формула score накапливает исторический шум.
Detection engineering без сигнатур: три практических сценария
Обнаружение компрометации учётных записей (T1087, Account Discovery)
Техника Account Discovery (T1087) - одна из первых, которую выполняет атакующий после получения начального доступа. Цель - понять, какие учётные записи существуют в домене, найти привилегированные аккаунты. На уровне SIEM это выглядит как серия LDAP-запросов или вызововnet user /domain, net group "Domain Admins" /domain.Для детектирования T1087 в SigmaHQ существует 46 правил. Из практически полезных:
zeek_dce_rpc_domain_user_enumeration.yml(https://github.com/SigmaHQ/sigma/bl...zeek/zeek_dce_rpc_domain_user_enumeration.yml) для Zeek - отслеживает DCE/RPC-вызовы перечисления доменных пользователей; cisco_cli_collect_data.yml - для сетевых устройств Cisco.SPL-запрос для Splunk, построенный по логике Sigma-правил для массового перечисления учётных записей:
Код:
index=wineventlog EventCode=4661 ObjectServer="SAM"
| stats count by SubjectUserName, IpAddress, _time span=5m
| where count > 50
| eval risk_score=case(count>200, 90, count>100, 70, count>50, 40)Insider threat: аномалии поведения пользователей через легитимный аккаунт
По данным опроса Exabeam (отчёт From Human to Hybrid, 2025; цифры требуют проверки по первоисточнику), заметная часть специалистов по кибербезопасности считают внутренние угрозы - malicious или compromised insiders - большей опасностью, чем внешние атакующие, отмечая рост инсайдерских инцидентов и несанкционированного использования GenAI-инструментов сотрудниками.Конкретный сценарий. Четверг, 16:45. Сотрудник финансового отдела, обычно работающий с 9:00 до 18:00 и обращающийся к 3-5 отчётам в день, подключается через VPN в 23:12 и за 40 минут скачивает 2,3 ГБ из каталога "Договоры" на файловом хранилище. Ни одно сигнатурное правило не сработает: учётка его, VPN его, к хранилищу у него есть доступ. UEBA-система фиксирует три отклонения от baseline одновременно: нетипичное время подключения, аномальный объём скачивания (baseline менее 100 МБ/день), нехарактерный каталог доступа. Кумулятивный risk score - 82, порог алерта - 70.
Детектирующая логика для Microsoft Sentinel (KQL):
Код:
BehaviorAnalytics
| where ActionType == "FileDownloaded"
| where ActivityInsights.IsFirstTimeUserAccessedResource == true
| where ActivityInsights.DownloadedBytesAnomaly > 2
| project TimeGenerated, UserName, SourceIPAddress, RiskScoreОбнаружение AI-генерированных атак: что видит Blue Team
GenAI создаёт новый класс головной боли. Каждое AI-сгенерированное фишинговое письмо уникально - нет повторяющихся шаблонов, нет фиксированных индикаторов. Для сигнатурного детектирования это катастрофа.Но поведенческий анализ продолжает работать, потому что смотрит не на содержимое атаки, а на действия после неё. Пользователь кликнул ссылку в письме - и его учётная запись начала обращаться к ресурсам, которые никогда не фигурировали в его baseline. С рабочей станции пошёл DNS-резолвинг к домену, зарегистрированному менее суток назад. Началось перечисление доменных объектов - техника, нетипичная для этой пользовательской роли.
AI может сгенерировать безупречное фишинговое письмо, но не может изменить поведенческий паттерн скомпрометированной учётной записи. Post-compromise actions остаются детектируемыми через baseline-отклонения - и это ключевое преимущество бессигнатурного обнаружения угроз перед сигнатурным подходом.
Чеклист внедрения поведенческой аналитики в SOC
Готовый чеклист для руководителя SOC или включения в план проекта:Отдельно - таблица ограничений. Знание границ инструмента не менее ценно, чем знание его возможностей:
| Ограничение | Контекст | Что делать |
|---|---|---|
| Cold start | Новый сотрудник - нет baseline | Peer group baseline: сравнивать с аналогичными ролями |
| Baseline drift | Легитимные изменения в поведении | Интеграция с HR для автоматического обновления профилей |
| Low-and-slow exfiltration | Данные выносятся малыми порциями, внутри baseline | Кумулятивный анализ за длительный период (30-90 дней) |
| LOLBins-техники | Атакующий использует те же инструменты, что и админ | Контекстная корреляция: admin запускает net.exe - нормально; бухгалтер - аномалия |
За три года работы с UEBA-модулями в разных SIEM у меня сложилось убеждение, которое многих раздражает: большинство организаций покупают UEBA, но никогда его не тюнят. Модуль включается в дефолтной конфигурации, первые две недели аналитики честно смотрят на алерты, потом false positive rate добивает до 40-60%, и UEBA превращается в дорогую строчку в лицензии, которую никто не читает. Результат предсказуем - когда реальный инцидент происходит, risk score тонет в шуме.
Проблема не в технологии. Проблема в том, что UEBA требует постоянного внимания: обновления peer groups при реструктуризации, перекалибровки порогов после каждого квартала, разметки плановых событий. Это не fire-and-forget продукт. Это процесс, который живёт ровно столько, сколько в него вкладывается SOC-команда.
Через год-два, когда AI-генерированные атаки станут нормой, а не исключением, организации без зрелого процесса поведенческого анализа окажутся в ситуации, где заметная доля атак для них невидима - потому что у этих атак нет сигнатуры, а baseline не построен. На форуме codeby.net коллеги ведут тред по тюнингу UEBA-моделей и калибровке риск-скоринга под конкретные SIEM-платформы - если выстраиваете поведенческую аналитику в SOC, стоит сверить пороги и peer group подходы.
Последнее редактирование модератором:
