Понедельник, 9:15. Ночная смена оставляет на дашборде 3 847 алертов за 12 часов - 12 помечены medium, остальные low или informational. В этой каше через двое суток постфактум обнаружат lateral movement по легитимной сервисной учётке: аутентификация на 14 хостах за 40 минут, ни одно правило корреляции не подняло приоритет выше medium. Scoring-модель на Isolation Forest, внедрённая через месяц после инцидента, поднимает аналогичный паттерн до risk score 94/100 за секунды. Разница между «нашли через 48 часов по жалобе пользователя» и «среагировали за 12 минут» - не магия нейросетей, а правильный feature engineering поверх тех же логов, которые уже лежали в SIEM.
Почему правила корреляции упираются в потолок
Корреляционные правила - фундамент детектирования в SIEM уже два десятилетия. Работают отлично, когда атакующий действует по известному сценарию: пять неудачных попыток входа за минуту - алерт на Brute Force (T1110, Credential Access). Проблема начинается, когда злоумышленник использует Valid Accounts (T1078, Initial Access / Persistence) - легитимные учётные данные, полученные через фишинг или утечку. Формально каждое событие аутентификации выглядит нормально: один успешный логин, потом ещё один, потом третий. Порога для срабатывания нет.По данным SANS 2024 SOC Survey, удовлетворённость SOC-команд инструментами на базе ML/AI получила оценку 2.17 из 5 - предпоследнее место среди всех категорий. Это не приговор технологии. Это индикатор: большинство внедрений machine learning в кибербезопасности сделаны «из коробки» без адаптации к конкретной среде. Включили - не заработало - выключили. Знакомый сценарий.
Правила корреляции линейны: условие, порог, действие. ML-модели работают в пространстве признаков - строят baseline нормального поведения и вычисляют отклонения. Принципиально другой подход к обнаружению аномалий, который закрывает три класса угроз, где правила бессильны:
- Скомпрометированные легитимные учётки - сигнатуры нет, есть поведенческое отклонение от baseline
- Low-and-slow атаки - действия растянуты во времени и не пробивают пороговые значения
- Insider threat - авторизованный пользователь действует в рамках своих прав, но с аномальным паттерном
ML для обнаружения угроз: какой алгоритм под какую задачу SOC
Выбор алгоритма определяется характером данных и типом угрозы. Три связки, проверенные на продакшн-трафике.Isolation Forest для anomaly detection в сетевых данных и аутентификации
Isolation Forest строит ансамбль деревьев, изолирующих каждое наблюдение. Аномалии изолируются быстрее - меньше разбиений нужно, чтобы отделить их от основной массы данных. Unsupervised подход: размеченный датасет не требуется, что критично в SOC, где чистых меток «атака / не атака» почти не бывает.Задачи: агрегированные метрики аутентификации (количество логинов, уникальных хостов, доля неудачных попыток за временное окно), объёмы сетевого трафика по направлениям, частота DNS-запросов с хоста. Алгоритм хорошо подходит для детектирования редких событий в высокоразмерных данных - внезапный всплеск соединений или резкое изменение профиля трафика.
Вендорная специфика: в Splunk MLTK реализуется через
| fit IsolationForest после подготовки фичей в summary index. В Elastic 8.x+ - outlier detection через data frame analytics. MaxPatrol SIEM включает аналогичную функциональность в модуль BAD.Ограничение (и оно существенное): алгоритм теряет точность при более чем 20-30 признаках и не объясняет причину аномалии. Аналитик видит высокий score, но не понимает, почему именно этот пользователь выделился. Для interpretability нужен дополнительный слой - тема Explainable AI (XAI) в SOC активно исследуется, но готовых решений пока мало.
Autoencoders и UEBA: поведенческий анализ угроз
Autoencoder - нейросеть, которая сжимает входные данные в компактное представление и восстанавливает обратно. Нормальное поведение восстанавливается с малой ошибкой (reconstruction error низкий), аномальное - с высокой. Это основа User and Entity Behavior Analytics (UEBA), одного из ключевых применений Data Science в ИБ.Задачи: профилирование рабочего дня пользователя (время входа, приложения, объём скачиваемых данных), паттерны доступа к ресурсам, характеристики процессов на endpoint. Подходит для сложных time-series данных - утилизация ресурсов облачных инстансов, метрики производительности приложений.
Вендорная специфика: Microsoft Sentinel использует autoencoders в UEBA-модуле - данные из таблицы BehaviorAnalytics агрегируются по сущностям (пользователь, хост, IP), модель обучается за 14-21 день и генерирует anomaly score. В MaxPatrol SIEM модуль BAD содержит 49 моделей, сгруппированных по типам активности: процессы (process activity), сетевая активность процессов (network process activity), доступы к ресурсам (access activity), связи между хостами.
Ограничение: autoencoders чувствительны к drift. Миграция сервисов, смена рабочего графика, перевод команды на удалёнку - и модель начинает сыпать ложными срабатываниями. Переобучение раз в 2-4 недели - не рекомендация, а обязательное условие работы UEBA в production. Из восьми внедрений, в которых я участвовал, три из пяти «отвалившихся» умерли именно из-за drift - никто не заложил процесс переобучения.
One-Class SVM для baseline конкретных сущностей
One-Class SVM строит границу вокруг «нормальных» данных в пространстве признаков. Всё, что оказывается за границей, маркируется как аномалия. Подходит для создания индивидуального baseline конкретного пользователя или сервера - в отличие от Isolation Forest, который работает по всей популяции.Задачи: мониторинг привилегированных учёток (доменные администраторы, сервисные аккаунты), контроль outbound-соединений критичных серверов, отслеживание паттернов обращения к файловым ресурсам. В Splunk MLTK доступен нативно через
| fit OneClassSVM.Ограничение: требует чистых данных для обучения. Если в обучающем окне уже есть compromise, модель примет его за норму. Ручная верификация окна обучения обязательна - нельзя взять последние 30 дней и надеяться, что там чисто. На практике это значит: перед обучением модели аналитик руками проверяет окно на известные инциденты и подозрительную активность.
Feature engineering: превращаем логи SIEM в признаки для модели
Ни один алгоритм не работает на сырых строках из Syslog. Feature engineering - превращение событий в числовые признаки - определяет 80% результата автоматизации SOC-аналитики через ML. Именно этот этап вендоры обычно прячут за словами «модель автоматически анализирует». Нет, не автоматически. Кто-то должен решить, что считать.Источники данных для обнаружения аномалий в сети и на endpoint
Для полноценного ML-детекта нужны данные минимум из четырёх потоков. Таблица показывает связку «источник - что собираем - какие TTPs ловим»:| Источник | Ключевые события | TTPs по MITRE ATT&CK |
|---|---|---|
| Логи аутентификации (AD, SSO, Cloud IAM) | EventID 4624/4625/4768/4769, auth.log | Valid Accounts (T1078), Brute Force (T1110) |
| EDR-телеметрия (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) | Создание процессов, сетевые соединения, реестр | Process Injection (T1055), Masquerading (T1036) |
| Сетевые потоки (NetFlow/IPFIX, DNS-логи) | Объёмы, направления, частоты, домены | Application Layer Protocol (T1071) - C2 |
| Cloud audit (AWS CloudTrail, Azure Activity Log) | API-вызовы, изменения конфигурации | Valid Accounts (T1078) в облаке |
Создание признаков
Из сырых событий формируются агрегированные признаки по сущности (пользователь, хост, IP) за временное окно - 1 час, 4 часа, сутки:login_count- число аутентификаций пользователя за окноfailed_ratio- доля неудачных попыток от общего числаunique_hosts- число уникальных хостов с аутентификацией (индикатор lateral movement)off_hours_flag- бинарный признак работы в нерабочее времяoutbound_bytes- объём исходящего трафика к внешним IPunique_domains- число уникальных DNS-запросов (индикатор DGA/C2)child_process_count- число дочерних процессов у cmd.exe/powershell.exe за окно
Практика: scoring-модель и AI SIEM интеграция для автоматизированного триажа инцидентов
Требования к окружению
- Python 3.9+, scikit-learn 1.3+, pandas 2.0+
- Данные: агрегированные фичи из SIEM (CSV/API-экспорт или scheduled search)
- История: 2-4 недели чистых данных для обучения baseline
- RAM: от 4 ГБ для датасетов до 500K строк, от 16 ГБ для enterprise-масштаба (миллионы строк)
- Production: MLflow для версионирования моделей, CI/CD для деплоя, мониторинг drift
- Режим: работает локально (Jupyter, cron-скрипт) или через интеграцию с SIEM API
Isolation Forest на данных аутентификации
Концептуальный пример scoring (адаптируется под конкретные данные):Insider threat и скомпрометированные учётки: detection-чеклист с ML-scoring
Insider threat - задача, где правила корреляции по определению бессильны. Авторизованный пользователь работает в рамках своих прав: открывает файлы, к которым имеет доступ, отправляет почту через корпоративный сервер. Разница между нормальной работой и сбором данных перед увольнением - статистическая, и видна только ML-модели с выстроенным baseline.Техника Valid Accounts (T1078) из MITRE ATT&CK описывает сценарий использования легитимных учётных данных - и внешним злоумышленником с украденным паролем, и инсайдером. В обоих случаях поведенческая аналитика безопасности ловит отклонение от baseline.
Detection-чеклист (ML-scoring + правила корреляции):
- Аномальный объём обращений к файлам - baseline per-user за 4 недели. Рост с 20-30 файлов/день до 300+ → risk score растёт. Правило-обвязка:
file_access_count > 5 * avg_30d AND user NOT IN admin_group - Географическая аномалия аутентификации - логин из нового региона при активной сессии из привычной локации. Детект:
geo_distance(current, previous) > 500km AND time_diff < 1h - Аномальное время активности - работа в 3 часа ночи при устоявшемся графике 9-18 за полгода. ML-score по
off_hours_flagв комбинации с другими признаками - Рост исходящего трафика к облачным хранилищам - Google Drive, Dropbox, Mega. Правило:
outbound_bytes_cloud > 3x baseline_weekly - Доступ к непривычным сетевым ресурсам - шары, к которым пользователь имеет доступ, но никогда ранее не обращался. UEBA-модель с autoencoder фиксирует deviation в паттерне доступа
Feedback loop и class imbalance. В продакшн-данных SOC аномалии составляют 0.01-0.1%. Модель «всё нормально» даёт accuracy 99.99% и пропускает атаку. Рабочие метрики - precision и recall по классу anomaly, а не accuracy. Для SOC важнее recall (не пропустить), но баланс определяется ёмкостью команды: если L1 разбирает 50 алертов в смену - порог risk_score настраивается так, чтобы false positive rate не создавал больше 50 эскалаций.
Безопасность самого ML-пайплайна. CVE-2025-32434 (CVSS 9.3, Critical) в PyTorch показала RCE при загрузке модели через
torch.load даже с weights_only=True - CWE-502 (Deserialization of Untrusted Data), затронуты все версии до 2.5.1, исправлено в 2.6.0. Сериализованные ML-модели в SOC - такие же артефакты инфраструктуры, как и любое ПО: контроль целостности, хеш-суммы, подпись, ограниченный доступ к хранилищу. По данным OWASP LLM Top 10 (2025), Data and Model Poisoning (LLM04:2025) входит в ключевые риски: если атакующий влияет на обучающие данные, модель перестаёт видеть его активность. Формула decay у scoring-модели на бумаге понятна, но по-настоящему ощущается, когда сам прогоняешь сабмишены и видишь, как деградирует baseline без переобучения - готовый стенд для экспериментов с аномалиями можно собрать на HackerLab.pro, где есть категории forensics и crypto с задачами на анализ данных.Большинство SOC-команд, которые «внедрили ML», на деле включили коробочный UEBA и через квартал его выключили. Из восьми внедрений поведенческой аналитики, в которых я участвовал за последние два года, пять закончились деактивацией модуля в первые три месяца - false positive rate не опустился ниже 40%, потому что никто не занимался feature engineering и калибровкой под конкретные данные. Продукт не виноват. Виноват подход «включил и забыл».
ML в SOC - это процесс, а не продукт. Он требует аналитика, который одновременно понимает TTPs атакующих и способен написать пайплайн на pandas. Таких людей мало, и это реальный bottleneck индустрии - не алгоритмы, не вычислительные мощности, а люди на стыке detection engineering и Data Science в ИБ. Пока SOC-команда не вырастит хотя бы одного такого специалиста, machine learning останется строчкой в маркетинговом буклете вендора.
Через два-три года SOC без ML-scoring будет таким же анахронизмом, как SOC без SIEM десять лет назад. Но выиграют не те, кто купит самый дорогой UEBA-модуль, а те, кто выстроит feedback loop между моделью и аналитиками и будет переобучать каждые две-три недели на реальных данных своей инфраструктуры. Если строите ML-детекты и хотите сверить подходы к baseline, scoring и калибровке с другими командами - на codeby.net обсуждают внедрение UEBA под разные SIEM-стеки с конкретными примерами feature engineering.
